Discussion :

[fatbob]

Bonjour,

Voici une petite question d'ordre théorique.
En essayant de prendre en main Symfony, je constate que c'est un outil très souple qui permet souvent de modifier le comportement par défaut tout en gardant la puissance du framework (en surchargeant les bonnes classes d'objet, par exemple).
Sauf dans un cas (du moins n'ai-je trouvé aucun moyen pour le faire) :

Si les clés primaires ne sont pas définies comme des entiers auto incrémentés, il est nécessaire de faire appel à tout un tas de bidouilles peu élégantes pour utiliser l'admin generator.
Vu les problèmes posés, j'en déduis qu'il s'agit là d'un point important de la philosophie de symfony.

Ma question est donc la suivante :
Comment se justifie le fait que les clés primaires DOIVENT être des entiers auto-incrémentés.

Dans le cas d'une base que j'ai développé (avant d'essayer d'utiliser symfony), j'ai choisi (après réflexion) de définir mes PK avec des identifiants sémantiques. J'ai choisi cette option parce qu'il s'agit réellement d'identifiants et que je devrais de toute façon définir des indexes uniques sur ces champs.

Comme ce sont des identifiants partout ailleurs dans le Système d'information, ils ne risquent pas de changer trop souvent (et, de toute façon, cela reste faisable sans trop s'arracher les cheveux).
Par contre, pour interpréter le résultat de nombreuses requêtes, cela impose un niveau de jointure supplémentaire bien inutile pour récupérer le code qui n'est plus dans les FK. J'ai fréquemment des requêtes sur 3-4 tables et je trouve inutile d'en ajouter 3 ou 4 de plus pour accéder aux codes qui définissent les PK.

Comme en plus j'interroge beaucoup cette base en dehors de toute interface, j'apprécie d'avoir des requêtes assez rapides à taper.
Je trouve que dans ce cas, les inconvénients d'une PK sans sémantique sont nettement plus importants que ses avantages et il me semble étrange qu'un outil tel que symfony ne l'ait pas pris en compte.
J'ai du mal à imaginer que mettre un paramètre là-dessus soit d'un niveau de complexité tel que l'équipe de Symfony ne réussisse pas à le faire.

Merci d'avance à ceux qui pourront m'éclairer.

[Michel Rotta]

Je suppose que tu entends, par clef primaire sémantique, une clef composée.

Effectivement, c'est une des faiblesses, non pas de symfony, mais de doctrine, qui est un des deux ORM embarqué dans symfony.

Il ne sais pas gérer les clef multiple.

C'est en grande partie lié au modèle objet qu'il utilise.

Imaginons un modèle de facturation, on va avoir, un client qui génère des factures, qui génères des lignes de factures, qui sont liées à un article (par ligne). Simple cas et simple à comprendre.

Si le Schéma est conçu 'à la doctrine', on va avoir une clef par table.

Et récupérer le nom d'un client qui aura commandé une ligne précise va nous donner en SQL : "select client.nom from client, facture, ligne where client.id = facture.client_id and facture.id = ligne.facture_id and ligne.id = XXX;" Avec une clef sémantique sur la facture Numéro de client et Numéro de facture pour le client, et numéro de client, numéro de facture et numéro de ligne pour la ligne, on pourrait avoir une requête simplifiée dans le genre : "select client.nom from client, ligne where client.code = ligne.client_code and ligne.client_code = XXX and ligne.client_facture = XXX and ligne.numero = XXX" (on remarque que localiser une ligne par un identifiant unique, n'est pas nécessairement simple, et nous ne sommes qu'au troisième étage de notre construction...

Le problème est qu'un modèle objet, il n'y a pas de possibilités de raccourcis, donc, si on a un objet ligne ($ligne), on va récupéré le nom du client par $ligne->getFacture()->getClient()->getNom(). Bon, si les données n'ont pas été correctement récupérée avec ligne, on va se payer trois requêtes, une pour récupérer la ligne voulue et deux pour récupérer la facture et le client, ce qui est loin d'être optimisé.

Mais si les données sont récupérée dans la requête initial, cela marche bien.

Dans tous les cas, il ne sera pas possible de passer, dans le modèle objet, directement de la ligne au client.

Je pense que c'est principalement cette limitation qui contraint symfony 1.x à ne pas gérer les liaisons multi champs. Je ne dis pas que c'est bien, ni rapide, non, au contraire, mais c'est la seul manière de conserver la validité du modèle objet qui permet d'accéder aux données. Il est possible qu'il en soit fait différemment dans la version 2.0 de doctrine, qui devrait être l'ORM de la 2.0 de symfony. Mais j'ai des doutes. Où alors cela serait au prix d'une lourdeur terrible dans le schéma et dans le code générer pour enregistrer tous les raccourcis...

Maintenant, il reste possible, malgré le numéro unique, de créer les champs sémantique et de créer des relations entre ces champs et leurs "frangins" des autres messages, ce qui, pour notre exemple, donnerait à l'objet $ligne une possibilité de récupérer le nom par $ligne->getClient()->getNom(). et la requête en DQL donnerait :

Code :

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

1
2
3
4
5
 
$q=doctrine_querry::create()->
          from('ligne l')->
          inerjoint('l.client c')->
          where('l.id = ?', XXX);

zappant ainsi la table facture. Par contre, il va falloire gérer "à la mano", les mise à jour des camps dans les tables factures et lignes, ce qui, avec le modèle objet, n'est pas une catastrophe à mettre en œuvre.

[fatbob]

Merci pour cette réponse.
Mais ce que j'appelle une clé sémantique, c'est une clé significative.
Par exemple une référence d'article en varchar.
Pour une clé à plusieurs champs, j'aurais tendance à dire clé composée.

Néanmoins, cette réponse est très intéressante sur les raisons de l'absence de clés primaires composées.
Cela dit, il y a d'autres cas où les clés multiples peuvent être intéressantes, notamment dans le cas de clés plus significatives.
Si je reprends l'exemple des factures et lignes de factures.
J'ai un numéro de facture et des lignes de factures.
Intégrer le numéro de facture dans la PK des lignes me permet d'avoir comme identifiant de la ligne son numéro dans la facture (on commence à 1 pour chaque facture). Et conceptuellement, je trouve ça plus clair.

Pour ce qui est de l'aspect sémantique, le problème vient plutôt du fait que, dans l'admin generator, il n'y a pas de moyen simple pour faire apparaître la clé dans les écrans de création et de modification (en affichage), or, dans ce cas, la clé est souvent saisie.

Merci encore pour cette réponse claire et complète (même si j'aurais préféré apprendre que c'était possible facilement)

[Michel Rotta]

Que la clef soit composée ou que la clef soit dans un seul champ, les problèmes sont identique (en fait, il sont plus important, dans tous les cas, s'il s'agit d'un seul champ).

Les opérations pour récupérer une partie de la clef dans la liaison sont chronophage... D'où mon utilisation "naturel" de clef composée et sémantique...

Reste qu'une seul grande clef peut être envisagé, dans un champ slug par exemple, et reste relativement simple à gérer (déjà fait). Je dis bien relativement, les mises à jours en cascades sont parfois acrobatique, d'où la notion de cascade.

[fatbob]

Mais quid du fait que l'admin generator ne permet pas de saisir la clé dans les modules de création... Partant de l'hypothèse que ce sera un integer auto-incrémenté.
Ma question est plutôt à ce niveau : y a-t-il une raison pour laquelle il n'est pas possible sans faire des contorsions, d'avoir une clé primaire non générée mais saisie par l'opérateur au moment de la création de l'enregistrement.

[Michel Rotta]

Cela ne vient pas de l'admin generator.

Lors de la création des form, les clef primaires ne sont pas accessible si elle sont en autoincrementé. Je crois (j'ai lu un truc la dessus, mais il y a un longtemps et plusieurs version de symfony sont passées sous les ponts, il est possible que cela ne soit plus vrai).

Si non, il suffit de mettre, dans le form, le champ de la clef en champs modifiable non masqué. Il deviendra éditable.