Sauf que son argument sur les locks est plutôt contre la séparation 
Cas "tout dans une table" :
Écriture : table lockée.
Lecture : pas de jointure, bien faire gaffe aux champs dans le select.
Cas "3 tables" :
Écriture : la table concernée est lockée, mais pas les 2 autres (ça semble cool).
Lecture : il faut faire deux jointures pour lier les 3 tables, donc de toute manière si une des trois tables est lockée c'est bloqué.
Avec 3 tables en myIsam tu as plutôt 3 fois plus de chances d'être locké pendant tes requêtes, donc ça me semble plutôt être un argument contre la séparation en plusieurs tables.
Perso, je pense que toute la question est de savoir s'il y a un intérêt réel à séparer les données. Cette question peut se résumer à « ma relation 1-1 sera-t-elle à tout jamais une relation 1-1 ou risque-t-elle d'évoluer en 0-1 ou 1-n ? ». Si tu n'est pas sûr à 100% de la stabilité de ta structure, la séparation en plusieurs tables peut sembler la bonne solution car le jour ou tu veux changer ta relation tu n'auras quasiment pas à toucher à ta base.
Mon avis est cependant différent : de toute manière si tes relations changent, il faudra recoder une bonne partie de l'applicatif, donc déplacer quelques champs ne pèsera pas bien lourd dans cette évolution. Donc autant partir de l'idée que ça ne changera pas.
Dans ce cas, je serais partisan d'aplatir les données pour t'éviter des jointures qui, si elles sont simples au départ, risquent de devenir pénibles quand tu auras des requêtes plus lourdes.
Enfin une question : comment tu concrétises une relation 1-1 dans une base de données ?
Cas "tout dans une table" :
Écriture : table lockée.
Lecture : pas de jointure, bien faire gaffe aux champs dans le select.
Cas "3 tables" :
Écriture : la table concernée est lockée, mais pas les 2 autres (ça semble cool).
Lecture : il faut faire deux jointures pour lier les 3 tables, donc de toute manière si une des trois tables est lockée c'est bloqué.
Avec 3 tables en myIsam tu as plutôt 3 fois plus de chances d'être locké pendant tes requêtes, donc ça me semble plutôt être un argument contre la séparation en plusieurs tables.
Perso, je pense que toute la question est de savoir s'il y a un intérêt réel à séparer les données. Cette question peut se résumer à « ma relation 1-1 sera-t-elle à tout jamais une relation 1-1 ou risque-t-elle d'évoluer en 0-1 ou 1-n ? ». Si tu n'est pas sûr à 100% de la stabilité de ta structure, la séparation en plusieurs tables peut sembler la bonne solution car le jour ou tu veux changer ta relation tu n'auras quasiment pas à toucher à ta base.
Mon avis est cependant différent : de toute manière si tes relations changent, il faudra recoder une bonne partie de l'applicatif, donc déplacer quelques champs ne pèsera pas bien lourd dans cette évolution. Donc autant partir de l'idée que ça ne changera pas.
Dans ce cas, je serais partisan d'aplatir les données pour t'éviter des jointures qui, si elles sont simples au départ, risquent de devenir pénibles quand tu auras des requêtes plus lourdes.
Enfin une question : comment tu concrétises une relation 1-1 dans une base de données ?
Ressources [PHP][MySQL][![[Image: fav.png]](http://prototypejs.org/images/fav.png)
prototype.js]
prototype.js]