Unique Table héritage et où les utiliser dans des Rails

Question

Je suis coincé dans un étrange problème de Conception,

Je suis en train de travailler sur deux types de profils de Modèles,

• Profil de l'utilisateur (appartient à l'Utilisateur)
• d'autres qui sont à maintenir en place, comme des "robots" (qui n'appartient pas à tout le monde)

Le typique OO comportement de ces deux types de Profils est le même, mais seulement l'important attributs/propriétés sont communes ( la très importante, 5-6), d'autres propriétés comme "intérêts etc"(presque 10-15 propriétés) ne sont pas là pour des profils de bot

Le codeur qui a travaillé sur ce déjà créé des modèles distincts/Contrôleurs pour des profils de bot / profils Utilisateur qui crée beaucoup de redondance partout et aussi comme prévu dur à maintenir, à écrire des tests, etc.J'ai voulu SÉCHER, au moins pour résoudre certains de ces problèmes de redondance.

Quelqu'un a suggéré Unique de l'Héritage de Table comme une solution

Quelqu'un a suggéré d'Utiliser Polymorphes Associations de la place.

quelle est la meilleure approche. Quand peut-on utiliser des IST?

Ma propre pensée était STI est utilisé meilleures lorsque les attributs sont les mêmes pour les Modèles et ils diffèrent dans leur comportement.

Réflexions sur ce que je peux faire?

Answer 1

La caractérisation de la STI surtout utile lorsque les attributs sont les mêmes mais le comportement diffère, c'est "sujet de droit", mais peut-être un peu limite. J'aime utiliser des IST quand il l'est, comme son nom l'indique, un clair OO-style de relation d'héritage, plutôt que de la base de données de style de relation entre les objets de différents types.

Si il y a du code commun entre les robots et les utilisateurs, je dirais STI sonne comme un gagnant. S'il y a des attributs communs, c'est probablement moins applicable, mais toujours utile d'avoir un aller à.

Je suis un assez expérimental personne, de sorte que ma recommandation est de lui donner un aller. De la succursale de votre code et refactoriser les modèles dans une IST relation. Voir si il fait vraiment des choses sèches, ou tout simplement swaps sur un ensemble de maux de tête pour un autre problème.

Une chose que je pense que vous ne verrez pas beaucoup de bénéfices de l'est de séchage de vos contrôleurs. Dans mon expérience, les IST modèles ne se traduisent souvent par de même d'automates. Mais ce serait quelque chose d'autre à expérimenter avec. Parfois, il y a une victoire, parfois il n'y en a pas.

Answer 2

J'ai écrit un article sur ce sujet, y compris quelques conseils pour travailler avec les STI:

Seul l'Héritage de Table dans les Rails

En bref: il faut une claire OO-style de relation d'héritage entre objets (comme l'a très bien expliqué traces womble), et pas seulement des données partagées. Si il n'est pas naturelle et évidente de la hiérarchie de classe, un des ITS de la conception peut devenir difficile à maintenir en tant que votre demande évolue.

Deuxièmement, vous devez vous demander s'il est important de disposer de toutes les données dans une table. Avec polymorphes associations, vos requêtes de base de données deviendra de plus en plus complexe, et probablement plus lent. Si vous êtes planification à faire la liste de tous les objets ainsi que sur le site (par exemple, dans une table) STI peut être le chemin à parcourir.

Troisièmement, assurez-vous que votre enfant des classes n'ont pas trop d'attributs uniques. Avec toutes les données dans une table, vous ne voulez pas beaucoup de non-global colonnes. Non seulement elles prennent de la place (pas une préoccupation majeure), mais ils font de la structure de données à confusion. Si vous avez des "spéciales" des colonnes, vous devez expliquer explicitement dans votre code.

Enfin, si vous ne l'utilisez STI, je recommande fortement d'utiliser un contrôleur unique pour l'ensemble de votre enfant les modèles. La fonction principale d'un contrôleur est de fournir un accès à des objets, et si les objets doivent être accessibles de manière très différente, alors la STI ne peut pas avoir été le bon choix pour commencer.

Découvrez mon article (lien ci-dessus) pour un peu plus de conseils utiles.

Answer 3

Je serais probablement utiliser des IST ou pas du tout. Vous pourriez être en mesure d'appeler tout un Profil et que vous souhaitez savoir si c'était un "bot" si son utilisateur a été nulle. Vous pouvez également stocker un champ "type", sans l'aide de la STI.

Certaines choses aurait une incidence sur ma décision pour l'utilisation de la STI:

• Si il y a bot logique spécifique
• Combien de bots il y a rapport de profils d'utilisateurs (petit nombre de bots signifie STI est OK - beaucoup de bots et je risque de les stocker quelque part d'autre)

La raison d'éviter les IST est parfois, il peut obtenir sur votre chemin. Par exemple, il peut être assez gênant pour modifier un objet d'un type à l'autre (un Bot pour un Profil dans ce cas). Parfois, un simple champ "type" est mieux.

Il est intéressant de noter que vous aurez probablement envie d'une classe de base commune si vous utilisez des IST. De sorte que vous pouvez Profile, BotProfile, et UserProfile. Les noms sont à vous. :)

Answer 4

Un seul accès à Rails STI - la plupart des plugins (et ainsi de suite) ne le supportent pas complètement. Vous vous retrouverez en train de patcher plusieurs des plus courantes.