Discussion :

[avairet]

Bonjour,

Je reviens vers vous au sujet de mes associations réflexives et des Primary keys composées.

En fait, je développe depuis quelques temps avec le framework CakePHP, qui offre notamment du maping relationnel-objet et "détecte" tout seul les relations entre tables... Cependant, il ne connaît pas, par défaut, les associations réflexives et surtout il ne supporte pas les Primary keys composées ou multiples.

Suite à de nombreux échanges avec la communauté pour essayer de comprendre et éventuellement de leur proposer des améliorations, la plupart des réponses qu'ils font, tournent autour de l'idée qu'il ne faut pas utiliser les associations réflexives, ni les PK composées et qu'il vaut mieux "tricher" en ajoutant un id auto-increment à une table d'association réflexive !

Exemples : "Wake up people, it's 2007, and multi-column primary keys are *still* a dumb idea."

"compound primary key constraints are *business* constraints not *application* keys"

"why multi-column primary keys are a dumb idea, but I think the most important one for 2007 is that it breaks REST architecture on the web, as there is no single point of reference to a piece of data, and that data may now change up on you without you knowing it,"

"But primary key and "unique index" is basically the same thing : the difference
is that a table can have only one primary key , while the unique indexes
can be more than one. "primary key" is just syntactic sugar for "unique and
not null"

Pourriez-vous me donner votre sentiment de vieux briscard du SQL ?

Bien cordialement,

Avairet

[hed62]

a table can have only one primary key

D'accord, mais rien n'empêche que cette clef soit composée de plusieurs champs...

[avairet]

Ben oui, c'est bien ce que nous dit la norme SQL... et ce que je pratique au quotidien, mais ce n'est pas facile pour moi de répondre en anglais aux afficionados de Cake PHP, ni de dire à mon boss que Cake est nul car il ne respecte pas la norme SQL !

Merci en tout cas de ton intérêt.

Avairet

[TheLeadingEdge]

Bonjour,
Je ne connait pas Cake PHP. Mais l'objet c'est un autre monde et ... une autre norme. Qui dit qu'un objet doit être identifié par un OID (object identifier). Ca n'est plus la même notion que l'identifiant des relations du monde relationnel.
Dire que c'est nul est un peu exagéré. De la même manière que l'attitude qui consiste à jeter les contraintes d'intégrités des modèles relationnels.
Avec un peu d'intelligence on comprend qu'il est important de les récuperer au niveau du mapping ( ds mon cas c'est .hbm.xml). Sinon il ne reste plus qu'à tt blinder au niveau du code... et prier pour ne rien avoir oublier ds les plans de tests

[avairet]

Désolé, mais la dernière partie de votre réponse n'est pas claire pour moi...

Je voulais surtout avoir votre sentiment sur les dénégations des PK multiples ou composées, sur le fait que pour beaucoup des utilisateurs de Cake, PK et Unique sont une même chose, sur le fait qu'ils n'hésitent pas à ajouter un champ ID auto-increment dans une table de liaison N:M et surtout, si le fait de modifier mon MLD (donc mon MPD ensuite) pour le faire "entrer" dans le modèle Cake était une aberration et/ou pouvait occasionner des erreurs...

A tout hasard, si cela vous intéresse et si vous avez un peu de temps pour lire, voici l'une des discussions dont je parlais :
http://groups.google.com/group/cake-...1ff611e628644c

Cordialement,

Avairet

[fsmrel]

"Wake up people, it's 2007, and multi-column primary keys are *still* a dumb idea."

Affirmation par ignorance (on dit encore : Ignoratio elenchi...)

"compound primary key constraints are *business* constraints not *application* keys"

Je ne saisis pas la différence que fait l’auteur à ce sujet...

"why multi-column primary keys are a dumb idea, but I think the most important one for 2007 is that it breaks REST architecture on the web"

Je ne connais pas l’architecture en question, mais il est évident que si, pour des raisons qui nous échappent, il est nécessaire de disposer d’une clé mono-attribut, il suffit d’ajouter un attribut ad-hoc à l’en-tête de la table concernée et de le déclarer comme seul composant d'une clé alternative (clause UNIQUE de l’instruction CREATE TABLE), sans toucher au reste.
Je suis prêt à parier une poignée de mains contre une poignée de porte que l’auteur ignore que l’on peut avoir plus d’une clé pour une table.

"But primary key and "unique index" is basically the same thing : the difference is that a table can have only one primary key, while the unique indexes can be more than one. "primary key" is just syntactic sugar for "unique and not null"

Du point de vue théorique, le Modèle Relationnel de Données met en œuvre seulement le concept de clé candidate. Une clé primaire est un cas particulier de la clé candidate, qui perdure avec les SGBD SQL, mais qui dans le contexte du pur Modèle relationnel appartient désormais au passé, car devenu sans emploi.

Une clé candidate est un ensemble d’attributs K d’une relvar R (ou table en SQL) garantissant les deux contraintes suivantes :

Unicité. Aucune valeur de R ne peut contenir deux tuples distincts ayant la même valeur pour K.
Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant l’unicité.

Et ces contraintes valent pour la clé primaire, qui est du niveau Modèle Relationnel (mathématique) tandis qu’un index est du niveau physique : pour démontrer qu’une table est en 3e forme normale, j’ai besoin du concept de clé candidate, mais pas de celui d’index. Les rapports entre clé candidate (ou primaire) et index sont ceux qui existent entre la Compagnie du Gaz et Léonard de Vinci : ils sont totalement indépendants l'un de l'autre.

ni de dire à mon boss que Cake est nul car il ne respecte pas la norme SQL !

Vous pourriez peut-être évoquer le fait que le concept de clé est vital et fait partie des piliers et que sans celui d’association réflexive, les entreprises de l’industrie et de la distribution fermeraient illico boutique...
En tout cas, vos interlocuteurs que j'ai cités, ont besoin d’étudier un minimum la modélisation et la théorie, pour éviter de proférer de telles âneries.

P.S. En écrivant ce qui précède, je n'avais vu les messages 4 et 5. Je suis donc allé faire un tour du côté du site que vous mentionnez et certaines choses sont dites qui ne sont pas sottes. Je regarderai de plus près. Il y a à trier...

[hed62]

primary key and "unique index" is basically the same thing

Primary key implique généralement les clauses "unique" et "index" en SQL.
Toutefois, l'inverse est nettement moins vrai. Il n'y a donc absolument pas équivalence.

[avairet]

il suffit d’ajouter un attribut ad-hoc à l’en-tête de la table concernée et de le déclarer comme seul composant d'une clé alternative (clause UNIQUE de l’instruction CREATE TABLE), sans toucher au reste.

Pour clarifier :

- soit la table Articles (id int auto-increment PK, label varchar).
- soit la relation : un article a un ou plusieurs articles en complément (et donc inversement)
- la table de liaison "correcte" est : Compléments (id_article1 int, id_article2 int) et la PK se fait sur les 2 colonnes.
- si j'ajoute à cette table de liaison, une colonne id Unique sans modifier le reste, je ne "dénature" pas ma modélisation SQL et je peux résoudre mon problème de framework ?

[hed62]

- la table de liaison "correcte" est : Compléments (id_article1 int, id_article2 int) et la PK se fait sur les 2 colonnes.

Oui.

je peux résoudre mon problème de framework

Oui.

je ne "dénature" pas ma modélisation SQL

J'en suis moins sur.

Autre hypothèse : je "dénormalise" ma modélisation

Assurément, car dans ta table, tu va te retrouver avec une clef primaire/candidate qui effectivement sera bien irréductible, et qui assurera l'unicité, mais tu va te retrouver avec un autre sous ensemble de tes champs de ta relation (dans ton exemple id_article1 et id_article2)
qui eux aussi assurent ces deux propriétés. Je ne sais plus, par manque de pratique, quelle forme normale cela enfreint ni au niveau de quelle règles, mais il suffit d'attendre TheLeadingEdge ou fsmrel pour le savoir

(euh... gros doute là tout de suite... Je ne dis pas d'ânerie au moins ?)

[fsmrel]

J’ai regardé le fil CAKE. Il y a à boire et à manger...

Considérons cet exemple :

Here, here! compound primary key constraints are *business* constraints not *application* keys. I for one am quite happy to add a single integer column in order to make good use of Cake. I frequently have this discussion with other Oracle devs who seem to think that invoice_id and line_num are a primary key on invoice lines. Their argument is that there are likely to be billions of invoice lines - but so what?

L'auteur de ces lignes part du principe que les attributs tels que NumeroFacture et NumeroLigneFacture sont sujets à être modifiés par l’utilisateur. Supposons donc que cela soit vrai. Dans ces conditions, il a raison de vouloir mettre en œuvre des clés qui soient invariantes, disqualifiant ainsi l’attribut NumeroFacture (pour NumeroLigneFacture, c’est plus difficilement défendable dans la mesure où il s’agit d’un séquenceur que l’utilisateur n’a aucune raison de modifier). Dans cette logique, on peut mettre en œuvre un attribut F invariant comme substitut de NumeroFacture. La clé primaire de la table Facture est représentée par le singleton {F} et la clé primaire de la table LigneDeFacture est représentée par le couple {F, LF}. L’attribut NumeroFacture fait alors l’objet d’une clé alternative pour la table Facture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Create Table Facture
(NumeroFacture      Integer    Not Null,
 DateFacture        Date       Not Null,
 TauxTVA            Taux       Not Null,
 F                  Integer    Not Null,
 Primary Key (F),
 Unique (NumeroFacture)
)  ;
Create Table LigneFacture
(F                  Integer    Not Null,
 LF                 Integer    Not Null,
 ProduitId          Integer    Not Null,
 Quantite           Integer    Not Null,
 Primary Key (F, LF),
 Foreign Key (F) References Facture (F)
)  ;

Concernant le "so what?", je dirais en tant que concepteur, que la représentation que j’ai utilisée a non seulement un sens sémantique —une ligne de facture est une propriété de la facture, au même titre que la date de facture, à la différence que dans le 1er cas, la propriété est multivaluée, alors que dans le 2e cas elle est monovaluée— mais aussi, en tant que DBA, qu'au niveau physique cela me permettra d'éviter des effets très pénalisants d’attente de fin d’entrées/sorties sur les disques, dans l’état de la technologie en 2008 (effet I/O bound que j’évoque de temps en temps sur ce forum).

Je ne veux surtout pas mélanger les niveaux, mais il faut bien évoquer au besoin les aspects physiques. Définir une clé primaire mono-colonne pour la table LigneFacture est le meilleur moyen de pédaler dans des entrées/sorties aussi inutiles que coûteuses en temps. Rien de tel qu'un bon prototypage des performances pour s'en convaincre.

Application Keys (single column Primary Key constraints - in practice, these are immutable) Business Constraints (Unique Keys, Compound Primary Keys etc - these frequently change on update)

C'est aller un peu vite en besogne, ça n’est pas parce qu’une clé est mono-colonne qu’elle devient invariante. A l’inverse, comme on vient de le voir, une clé multi-colonnes peut être rendue sans problème invariante.

[fsmrel]

- soit la table Articles (id int auto-increment PK, label varchar).
- soit la relation : un article a un ou plusieurs articles en complément (et donc inversement)
- la table de liaison "correcte" est : Compléments (id_article1 int, id_article2 int) et la PK se fait sur les 2 colonnes.
- si j'ajoute à cette table de liaison, une colonne id Unique sans modifier le reste, je ne "dénature" pas ma modélisation SQL et je peux résoudre mon problème de framework ?

Du strict point de vue tabulaire, si pour une valeur prise par {id_article1} on peut avoir plusieurs valeurs prises par {id_article2} et si pour une valeur prise par {id_article2} on peut avoir plusieurs valeurs prises par {id_article1}, alors le couple {id_article1, id_article2} est une clé candidate pour la table Compléments.
Ajouter une colonne Id (clé candidate) à la table Compléments est possible, mais cela risque de se traduire par une perte sensible de la performance lors des traitements (effet I/O bound).

Je ne sais plus, par manque de pratique, quelle forme normale cela enfreint ni au niveau de quelle règles, mais il suffit d'attendre TheLeadingEdge ou fsmrel pour le savoir

En l’occurrence, si le singleton {id} et le couple {id_article1, id_article2} sont bien des clés candidates pour la table Compléments, la 5e forme normale est respectée (sous réserve de la présence d'autres attributs). (Dommage ?)

[avairet]

Merci pour toutes ces précisions !

Je vais essayer de retraduire tout cela en anglais pour en référer à la communauté CakePHP et en attendant, même si les perfs seront peut-être en baisse, je vais donc ajouter un id auto-increment dans mes tables...

[hed62]

En l’occurrence, si le singleton {id} et le couple {id_article1, id_article2} sont bien des clés candidates pour la table Compléments, la 5e forme normale est respectée (sous réserve de la présence d'autres attributs). (Dommage ?)

Hum.. Rien ne dit que lorsque l'on a plusieurs clef candidates, dont une n'apportant significativement d'information (pas de sens en tant que tel, ni n'entre en relation ailleurs) alors on doit supprimer une des clef / splitter en deux tables ? Cela est ancien pour moi et très flou, donc... Une piqure de rappel me ferait du bien :p

[fsmrel]

Rien ne dit que lorsque l'on a plusieurs clef candidates, dont une n'apportant significativement d'information (pas de sens en tant que tel, ni n'entre en relation ailleurs) alors on doit supprimer une des clef / splitter en deux tables ?

Du point de vue de la théorie relationnelle, vous pouvez avoir autant de clés candidates que vous voulez pour une table, qu'elles soient porteuses d'information ou non. Maintenant, du point de vue du bon sens et du rasoir d’Ockham ("si un concept est inutile, virez-le", "si une hypothèse s’avère inutile pour la démonstration d’une théorie, ne la faites pas", "Ne multipliez pas les entités au-delà du nécessaire", etc.) il est évident que l'attribut id ajouté dans l’en-tête de la table Compléments non seulement n’a pas d’existence légitime mais s’avère en outre nuisible pour la performance.

CAKE ça n'a pas l'air d'être de la tarte...

[hed62]

CAKE ça n'a pas l'air d'être de la tarte...

au contraire, s'enservir, c'est du gateau !

Blague à part, merci pour l'explication : j'ai tendance à mélanger règles et bonnes pratiques parfois.

[avairet]

Je dirais même plus : avec Cake, le PHP c'est du tout cuit

Mais le framework est en cours de maturation et malheureusement pour les puristes, certains éléments ne sont pas encore parfaits...

Dans son mapping relationnel, Cake veut toujours une PK, donc quand il n'en trouve pas d'explicite (à savoir une champ id auto-increment), il n'est pas content. On peut lui spécifier une autre colonne comme PK, mais pas deux colonnes... voilà pourquoi la grande majorité des "bakers" ajoute "au forceps", un champ ID !

Pour les performances, est-ce vraiment pénalisant ? Avec un système de cache, peut-on résoudre en partie cette perte de perfs ?

Merci pour vos avis...

[fsmrel]

Pour les performances, est-ce vraiment pénalisant ? Avec un système de cache, peut-on résoudre en partie cette perte de perfs ?

Il est possible qu’avec un système de cache vous résolviez la perte de performance. Mais pour s’en assurer, il est nécessaire de mettre sur pied un système de prototypage ad-hoc, ce qui n’est généralement pas trivial.
Cela dit, considérez que vous accédiez à un article donné et à tous ses compléments directement dépendants. Si ces compléments sont dans la même page physique sur disque, en une I/O vous les récupérerez pratiquement tous. Si ces compléments sont éparpillés sur le disque, au pire vous provoquerez une I/O par complément. Et les temps s’expriment en millisecondes par I/O. Les choses peuvent s’améliorer si les lectures (et écritures) sont parallélisées. Maintenant, avec un SGBD comme DB2 (ou SQL Server, pour les autres consultez les forums...), on a la possibilité de forcer le regroupement des compléments dans la même page physique (le clustering comme ils disent) : pour cela on déclare un index dit cluster, dont la clé induit ce regroupement. Par exemple, si je considère à nouveau la clé {id_article1, id_article2}, je peux définir avec DB2 (ou SQL Server) un index cluster sur cette clé, c'est-à-dire que tous les compléments rattachés à l’article de clé {id_article1} seront dans la même page (sous réserve de la place disponible, dont je peux du reste geler une partie à l’occasion des chargements et réorganisations des tables, afin que les inserts ultérieurs trouvent de la place pour les nouveaux compléments {id_article1, id_article2}). Il est important de noter que s’il est d’usage de définir comme cluster l’index utilisé pour la clé primaire, ça n’est pas une obligation, ce qui dans votre cas est une bonne chose (si votre SGBD met en oeuvre le concept d’index cluster tel que je l’ai brièvement décrit).
Dans le cas d’une nomenclature, ce qui vaut pour l’accès aux compléments directement dépendants d’un article vaut pour les dépendants de chaque dépendant, etc. Si éparpillement initial il y a dans les pages du disque, ça sera évidemment amplifié pour les niveaux successifs...

Bonne soirée à vous.

[TheLeadingEdge]

Dans son mapping relationnel, Cake veut toujours une PK, donc quand il n'en trouve pas d'explicite (à savoir une champ id auto-increment), il n'est pas content. On peut lui spécifier une autre colonne comme PK, mais pas deux colonnes... voilà pourquoi la grande majorité des "bakers" ajoute "au forceps", un champ ID !

Comme je l'ai déjà dit autre monde autre norme...
Mais bon c'est Cake qui a besoin d'un OID. Idéalement c'est lui qui devrait le gérer. Pour les paraphraser ...
"Wake up people, it's 2008, intrusive framework is *still* a dumb idea."
La couche de mapping est là pour réconcilier les 2 couches (persistence et métier) pas pour imposer 1 des 2 modèles ds l'autre.

[avairet]

"Wake up people, it's 2008, intrusive framework is *still* a dumb idea."

Est-ce vraiment le fond de ta pensée ? Tu sembles connaître Cake, donc tu refuserais de l'utiliser pour cette raison ?

Je suis OK avec toi, ce devrait être à Cake de gérer ce problème, pas au développeur de "casser" son modèle de données. Mais bon, vu les réponses de la core team, ce n'est pas prêt de se faire...

La couche de mapping est là pour réconcilier les 2 couches (persistence et métier) pas pour imposer 1 des 2 modèles ds l'autre.

Euh... pourrais-tu expliciter un peu mieux cette phrase qui m'apparaît sybiline ?

[hed62]

La couche de mapping est une couche qu'on ajoute afin de faire coller les couches de persistence et de métier. Un genre d'adapteteur (au sens pattern du terme)

Si cette couche a pour but non plus d'adapter l'un à l'autre, mais de forcer l'une a rentrer dans l'autre, l'objectif est manqué.