Discussion :

[Bakura]

Bonjour à tous ,

J'essaye d'apporter le plus grand soin possible à l'architecture de ma base de données (je sais que je ne le regretterai pas quand je ferai évoluer mon architecture, et que c'est la clé pour quelque chose de robuste). Toutefois je me pose une petite question.

J'utilise l'ORM Doctrine 2, pour lequel je spécifie mes relations via des annotations, et qui me génère le code SQL correspond. Dans une de mes tables, je dispose de deux relations ManyToOne, et Doctrine me génère deux index ces deux clés étrangères. Or, ce couple (fk_1, fk_2) est garantit comme unique dans mon schéma, et j'ai donc ajouté une annotation au niveau de l'ORM pour qu'il génère une contrainte unique au niveau de ces deux clés étrangères.

Je dispose donc de quatre clés :

- la clé primaire.
- une contrainte unique composée de fk_1 et fk_2
- un index sur fk_1
- un index sur fk_2

Ma question est justement de savoir si ajouter la contrainte unique est utile sachant que je dispose déjà de ces index sur les deux clés étrangères (sachant qu'il est impossible de supprimer ces index au niveau de l'ORM, pour ne garder que la contrainte d'unicité).

Merci

[skuatamad]

Une contrainte d'unicité c'est différent d'un index, si le couple (fk1, fk2) doit être unique il faut le valider via une contrainte.
Techniquement les SGBDs s'appuient sur des indexs (déjà existant ou créés automatiquement lors de la création de la contrainte) pour gérer les contraintes.

Dans l'état actuel l'index sur fk1 (la 1ere colonne de la contrainte d'unicité) n'est pas obligatoire, le SGBD devant être capable d'utiliser l'index généré pour assurer la contrainte. Il est également préférable de ne pas avoir une PK autoincrémenté qui ne sert à rien (si effectivement elle ne sert à rien), et de créer la PK sur le couple (fk1, fk2).

Après si doctrine impose une PK autoincrémenté et la création des index la situation actuelle est bonne.
Dans tous les cas la contrainte d'unicité DOIT être implémentée au niveau SGBD.

[Bakura]

Merci de ta réponse, je vais donc créer cette contrainte d'unicité.

Après si doctrine impose une PK autoincrémenté et la création des index la situation actuelle est bonne.

C'est ça. Doctrine recommande d'éviter les clés primaires composées.

[CinePhil]

Ça commence bien...

J'essaye d'apporter le plus grand soin possible à l'architecture de ma base de données (je sais que je ne le regretterai pas quand je ferai évoluer mon architecture, et que c'est la clé pour quelque chose de robuste).

Mais ça continue mal !

J'utilise l'ORM Doctrine 2, pour lequel je spécifie mes relations via des annotations, et qui me génère le code SQL correspond.

Ce n'est pas au programme de décider comment doit être le modèle de données.
On modélise d'abord les données puis on crée des vues nécessaires au programme et ce sont ces vues qui sont requêtées par le programme, éventuellement..., si tu y tiens vraiment... mais faut pas te sentir obligé d'utiliser ce genre de machin... ou alors si on te l'impose... à l'aide d'une saloperie d'ORM.

Dans une de mes tables, je dispose de deux relations ManyToOne, et Doctrine me génère deux index ces deux clés étrangères. Or, ce couple (fk_1, fk_2) est garantit comme unique dans mon schéma, et j'ai donc ajouté une annotation au niveau de l'ORM pour qu'il génère une contrainte unique au niveau de ces deux clés étrangères.

Et voilà ! Ce n'est pas au programme de spécifier une contrainte unique à la BDD. C'est la BDD qui doit imposer son modèle au programme ! L'unicité d'une colonne ou d'un ensemble de colonnes tient du modèle de données, lequel est issu de règles de gestion qui spécifient cette contrainte d'unicité, ou bien cette contrainte est déterminée par le processus de modélisation des données, comme dans le cas qui semble te concerner des tables associatives.

Je dispose donc de quatre clés :

- la clé primaire.
- une contrainte unique composée de fk_1 et fk_2
- un index sur fk_1
- un index sur fk_2

S'il s'agit bien d'une table associative, la clé primaire doit être composée des colonnes portant les deux clés étrangères. Si c'est le couple {fk_1, fk_2} qui est clé primaire, alors ce couple est indexé et, par voie de conséquence, la colonne portant fk_1 est aussi indexée individuellement mais pas la colonne portant fk_2 et il faut donc l'indexer individuellement. Si l'ordre des colonnes est inversé dans la déclaration de la clé primaire, c'est le contraire.

(sachant qu'il est impossible de supprimer ces index au niveau de l'ORM, pour ne garder que la contrainte d'unicité).

Jette l'ORM !

C'est ça. Doctrine recommande d'éviter les clés primaires composées.

Jette l'ORM !

[SQLpro]

Ma rigolade de la journée : MySQL qui est le moins performant des SGBDR plus un ORM qui enflera encore les temps de réponse entre 5 et 25 fois au bas mot !!!
A lire sur cet ersatz de SGBDR q'est MySQL : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/
A lire sur les performances comparatives de MySQl, PostGreSQL et MS SQL Server : http://blog.developpez.com/sqlpro/p9...lles-en-sql-1/
A lire sur les méfaits des ORM : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
A lire sur les performances de Doctrine, qui semble bien être le plus pourrit des ORM : http://ljouanneau.com/blog/post/2007...es-des-orm-php
http://www.incapable.fr/conseil-mysql-19
http://sourceforge.net/apps/trac/php...ne%20benchmark

A +

[Bakura]

Ma rigolade de la journée : MySQL qui est le moins performant des SGBDR plus un ORM qui enflera encore les temps de réponse entre 5 et 25 fois au bas mot !!!

On se calme SQLPro ;-).

A lire sur les performances de Doctrine, qui semble bien être le plus pourrit des ORM :

Doctrine a connu une version majeure depuis la date de l'article que tu mets en lien (la version 2), qui améliore pas mal les choses.

S'il s'agit bien d'une table associative, la clé primaire doit être composée des colonnes portant les deux clés étrangères. Si c'est le couple {fk_1, fk_2} qui est clé primaire, alors ce couple est indexé et, par voie de conséquence, la colonne portant fk_1 est aussi indexée individuellement mais pas la colonne portant fk_2 et il faut donc l'indexer individuellement. Si l'ordre des colonnes est inversé dans la déclaration de la clé primaire, c'est le contraire.

Merci de la précision, je ne savais pas pour le fait que la deuxième clé étrangère n'est pas indexée par défaut... Mais apparemment Doctrine indexe les deux de lui même.


SQLPro, je ne cherche pas à lancer un débat sur l'utilité des ORM puisque visiblement beaucoup ne les portent pas dans leur coeur ici (^_^). Comme je l'ai dit sur un autre fil de discussion, Doctrine me rend bien des services lors d'une conception orientée objet et me facilite bien la vie. En étant seul et unique développeur, c'est le genre de choses qui me permettent de gagner un temps précieux et qui me laissent du temps pour bosser sur d'autres aspects du projet (communication, juridique...).

EDIT : Je lis ton papier (très intéressant au demeurant), je sens que je vais me faire allumer après avoir lu le : "et pour les développeurs de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leur ignorance."

Si un jour je m'aperçois dès que le site commencera à marcher que l'ORM est effectivement le goulot d'étranglement, je n'hésiterai pas à revoir ma position et à le lâcher. Je pense qu'un ORM relativement bien utilisé (l'ORM ne créé pas le schéma magique tout seul, ça reste de ma responsabilité) ne me pénalisera pas TANT QUE CA. Reste à voir en pratique.

Pour MySQL, je note et je vais réfléchir à passer sur PostgreSQL.

[CinePhil]

Merci de la précision, je ne savais pas pour le fait que la deuxième clé étrangère n'est pas indexée par défaut... Mais apparemment Doctrine indexe les deux de lui même.

Ce n'est pas exactement ce que j'ai voulu dire.
Il semble désormais commun que le SGBD, notamment MySQL, indexe automatiquement les colonnes lors de la déclaration de la clé étrangère. En tout cas, quand on réalise un schéma E/R sur MySQL Workbench et qu'on génère le code SQL ou directement la BDD en se connectant Workbench au serveur MySQL, Workbench prévoit automatiquement l'indexations des colonnes figurant dans les contraintes de clé étrangère.

Ce que je voulais dire, c'est qu'avec un index multi-colonnes, seule la première est indexée individuellement. Démonstration...

Soit un index placé sur le couple de colonnes {A / B}, il sera trié ainsi :
A / B
1 / 1
1 / 2
1 / 5
1 / 10
2 / 1
2 / 3
2 / 6
2 / 8
3 / 4
3 / 5

=> On voit très bien que la colonne B n'est pas triée, il n'y a pas d'index individuel sur la colonne B alors qu'elle fait partie de l'index sur {A / B}.

Si on doit interroger souvent B et si B comporte un grand nombre de valeurs, alors il faut indexer B en plus du couple {A / B}. Par contre, inutile d'indexer individuellement A qui est déjà indexé par l'index sur le couple {A / B}.

Par ailleurs, je maintiens que les ORM sont une perte de temps !
Il est largement plus rapide d'écrire une requête en SQL pur qu'avec le pseudo-SQL ddes ORM. J'ai souffert avec Hibernate, ça m'a ôté toute envie d'en essayer un autre !

Voir cette discussion et celle-ci

[Bakura]

J'ai bien compris la subtilité des index composées. Merci de cette précision :jap:.

Par ailleurs, je maintiens que les ORM sont une perte de temps !
Il est largement plus rapide d'écrire une requête en SQL pur qu'avec le pseudo-SQL ddes ORM. J'ai souffert avec Hibernate, ça m'a ôté toute envie d'en essayer un autre !

Je veux bien te croire, je ne dis pas le contraire et c'est en lisant les tutoriaux de SQLPro (et les tiens, ta page sur quand utiliser une table associative est dans mes favoris et je m'y réfère chaque fois pour voir si l'ORM m'a pas généré un truc foireux ) que je me rends compte qu'effectivement, l'ORM reste vachement haut niveau et "empêche" l'utilisation des spécificités de chaque SGBDR (même si on peut écrire du code SQL natif sous Doctrine, en fait). N'empêche que mon application n'a pas des besoins énormes en terme de base de données (je n'ai aucune requête faisant intervenir 6 ou 7 tables par exemple), et encore une fois, la propreté qu'offre l'ORM dans un contexte 100% objet est quand même appréciable. Par contre, je me rends finalement compte que la fonctionnalité de lazy-loading m'est finalement assez peu utile puisque je fais les jointures dès que je réalise la requête, du coup c'est un des avantages de l'ORM que j'avais noté qui n'en est finalement pas vraiment un.

Maintenant, comme je l'ai dit plus haut, si j'ai une application plus exigeante du côté base de données, je penserai à vous.

Sinon par pure curiosité, tu gères ça comment dans une conception orientée objet avec du simple SQL ?

PS : pour utiliser NHibernate en stage (Hibernate adapté au C#) et pour avoir pas mal utilisé Entity Framework dans le cadre d'une application Windows Phone, Doctrine 2 est DE LOIN l'ORM le plus agréable avec lequel j'ai travaillé ;-).