Forum: Rails France =?iso-8859-1?q?Probl=E8me_d=27h=E9ritage?=

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Zambra (Guest)
on 2006-04-21 18:42
(Received via mailing list)
Bonjour,

Rails a fait le choix du "Single Table Inheritance" ce qui oblige à
utiliser une seule table pour tous les objets. Comment faites vous
lorsque vous avez beaucoup de propriétés différentes ? Cela semble aller
à l'encontre des formes normales d'une base de données (nombreux champs
non remplis car pas concernés)
Eric D. (Guest)
on 2006-04-21 19:00
(Received via mailing list)
> Bonjour,
>
> Rails a fait le choix du "Single Table Inheritance" ce qui oblige à
> utiliser une seule table pour tous les objets. Comment faites vous
> lorsque vous avez beaucoup de propriétés différentes ? Cela semble aller
> à l'encontre des formes normales d'une base de données (nombreux champs
> non remplis car pas concernés)

Oui c'est contre la forme normale, mais c'est un compromis souvent
acceptable. Si tu as beaucoup de propriétés diférentes ça fait juste un
peu plus de place disque prise inutilement, ce qui est de moins en moins
souvent le problème principal d'une appli.

Tu as deux autres solutions (non testées) :

(imaginons des objets A et B qui héritent tous deux de Z)

* Faire comme prévu par rails mais
 - implémenter deux tables différentes pour A et B
 - implémenter une vue pour Z qui est l'aggrégation de A et B (certains
SGBD doivent savoir faire ça) ou mieux réellement de l'héritage de table
(à confirmer mais je crois que postgress sait faire ça)
 - aller modifier à la main les méthodes AR qui permettent de connaitre le
nom de la table pour forcer A et B a avoir leur propre nom de table

* Considérer que tu n'agiras que sur A ou que sur B mais que jamais tu ne
chercheras à lister/filtrer tous les objets Z. Là tu as une option à
mettre dans le modele Z pour lui dire que ce n'est pas un héritage au
niveau bdd mais seulement une mutualisation coté code. Je crois qu'il y a
un mot clé pour ça mais sinon tu peux toujours fournir nil à
set_inheritance_column. Normalement (non testé), il devrait faire un
héritage de code normal et "oublier" que ça peut être aussi un héritage en
base.


Ceci dit, sauf si tu as une bonne raison, autant faire le même compromis
que rails et tout laisser dans la même table.
--
Eric D.
This topic is locked and can not be replied to.