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 ?)