Question

Une réponse à une question sur la conception de la base de données a suggéré un élément appelé héritage à table unique. J'ai fait quelques recherches à ce sujet, mais je n'arrive pas à trouver autant d'informations claires à ce sujet.

En gros, ce que je semble comprendre, c’est que vous avez une grande table avec tous les champs qu’elle contient ainsi qu’un champ type. Votre couche ORM utilise ensuite le champ type pour vous donner différentes vues d’objet. Est-ce correct?

Plus important encore, l'héritage d'une table est-il une technique de conception de base de données "approuvée"? J'entends par là qu'il est "raisonnable" de l'utiliser. Est-il également sûr de l'utiliser ou pose-t-il des problèmes?

L’autre problème est de savoir comment cela fonctionne dans les rails? J'ai trouvé quelques références à ce sujet dans les rails - mais cela pose-t-il problème en procédant de manière non conventionnelle?

Toute aide très appréciée.

Était-ce utile?

La solution

Est-ce une bonne idée? Ça dépend. Cela casse la normalisation en ce sens qu'une table n'a pas un seul but. Que se passe-t-il lorsque vous étendez la classe de base pour la nième fois? Vous devrez ajouter des colonnes à la table. La plupart des bases de données modernes ne posent pas de problème car vous pouvez modifier le tableau, mais qu’en est-il du refactoring et de la suppression d’une classe? Maintenant, vous avez des colonnes qui n'ont pas de but.

Une règle de base - si la plupart du design a été élaboré, son utilisation est probablement sûre. Si la conception change fréquemment, vous avez d'autres problèmes et vous devez verrouiller vos cas d'utilisation / besoins de l'utilisateur. (oui, pas vraiment compatible XP)

Je ne connais pas les effets Rails.

Autres conseils

STI est un moyen de remédier à un décalage entre la pensée orientée objet et celle orientée base de données. Cela permet une représentation raisonnable des informations dans la base de données et une représentation différente dans le modèle objet.

Par exemple, j'ai une application dans laquelle chacun de mes produits contient un ou plusieurs frais, chacun calculé de manière légèrement différente. Dans mon modèle objet, je souhaite avoir des sous-classes d'une classe de frais, chacune d'entre elles sachant se calculer elle-même. Cependant, je ne souhaite pas vraiment avoir de table par type de taxe: je crée donc Fee comme classe de base et fees comme table, qui contient l'union de tous les champs nécessaires pour tous les sous-types, plus un "type". ; colonne dont la valeur correspond au nom de la sous-classe correspondante. ActiveRecord gère la plomberie par la suite.

En bref, l'héritage à table unique (STI) est un modèle de conception qui permet de mapper les relations d'héritage de la programmation orientée objet vers la base de données. Si vous définissez des sous-classes à partir de vos objets de modèle ActiveRecord, vous devez considérer STI.

STI est (à l'origine?) documenté dans le livre «Patterns of Enterprise Application Architecture» de Martin Fowler. Il est également décrit dans le livre canonique de DHL intitulé «Développement Web agile avec des rails» (section 18.4, je pense.). ces livres, car ils fournissent une explication bien meilleure que ce que je pouvais espérer faire dans cet espace.

Je suis tout à fait en désaccord avec le sentiment exprimé sur www.matthewpaulmoore.com (lié par robintw dans ce fil), selon lequel les IST sont intrinsèquement une mauvaise chose. Cela semble être un point de vue quelque peu naïf qui réduit l'utilisation de l'héritage OOP. J'ai utilisé STI pour créer des solutions élégantes dans Rails, mais je suppose que vous pouvez abuser de tout modèle de conception.

Definitive référence . Il permet à une seule table de stocker plusieurs objets ayant une classe de base commune.

Ruby on Rails utilise une bibliothèque appelée Enregistrement actif . Il s’agit d’un framework Ruby commun qui prend en charge les IST.

Je ne peux parler que de la (nouvelle) perspective ADO Entity Framework, qui inclut une fonctionnalité table-par-type (TPT).

Ici est un bonne série de billets de blog présentant les concepts de base (utilisant Entity Framework) et contenant un article MSDN également ici .

Il semble également y avoir quelques conseils sur l'utilisation de nHibernate pour TPT, il se trouve ici .

Ce lien explique l'héritage table par type dans SQL Server . Cela semble avoir un assez bon résumé et une introduction au concept.

Je ne sais pas quel impact cela aurait sur Rails.

En général, je trouve cela utile, mais j'ai rencontré quelques bugs

L'exemple de ce lien peut fournir une image utile de son utilisation.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top