C'est sans doute mieux. Je détermine le besoin de faire plusieurs tables par la taille de la future table. A moins de 500 ko, je ne me casse pas la tete à faire plusieurs tables.

oui bien entendu, ben en fait c'est très simple, le nombre d'entrées qu'il y a dans TABLE1 est identique au nombre d'entrées présentes dans TABLE2 :wink:

bon ben merci en tous cas, j'ai décidé de fusionner les deux tables :)

Table2 peut enregistrer plusieurs commentaires pour Table1, c'est selon.

C'est ça qu'on entendait par là.

Avec le belongTo, que je viens de comprendre, tout s'explique ^^

Merci pour vos réponse :)

[quote="narcisse"]D'après le schéma que tu proposes, table1.id = table2.id, c'est un héritage en sql. Pose toi la question de cette nécessité ...[/quote]Non table1.id = table2.belongTo mais c'est le même principe oui. "belong to" en anglais signifie "appartient à".

sinon le fait de sélectionner les champs dans le requête c'est effectivement comme ça que je l'entendais, on ne prend que les informations nécessaires, MAIS est-ce que MySQL lui-même ne serait-il pas alourdi par la présence de champs "superflus" (pour une requête précise) dans la table ? (même si pas appelés par la requête)

je pense qu'il faudra réaliser des tests de performance avec une très grosse table et voir ce que ça donne. mais bon je pense que t'as raison, si gain il y a, il serait perdu d'un autre coté à cause de la jointure obligatoire dans la deuxième requête.


sinon j'ai pas compris ce que vous entendez par "tous les commentaires dans un seul champ" ?
vouliez-vous dire "tous les commentaires dans une seule entrée/ligne" ? :? je suis pas sûr de saisir. si c'est ça alors VOUS ÊTES DES MONSTRES. nan mais ho! :mrgreen:

J'ai plutôt compris ça dans le sens un seul commentaire.

Si c'est pour un seul commentaire, alors ne conserve qu'une seule table. Et dans ton select :

SELECT commentaire FROM table;

Sinon, tu seras obligé d'utiliser une jointure (même si pas méchante), et c'est ce qui prend le plus de performances.

D'après le schéma que tu proposes, table1.id = table2.id, c'est un héritage en sql. Pose toi la question de cette nécessité ...

J'ai peur de comprendre que tu comptes mettre tout les commentaires dans un seul champs, vrai ?

Si c'est ça, il est évident qu'il faut privilégier la seconde solution, avec 2 tables, dans laquelle chaque commentaire est représenté par un enregistrement unique.

Sinon, si ce champ "commentaire" ne contient qu'un seul commentaire, sans composition, je suis de l'avis d'[b]enneite[/b].

EN général, il vaux mieux faire le moins de jointure possible, si tu utilises les informations des deux tables dans les mêmes script, vaut mieux en faire qu'une à mon avis.
Par contre si les infos de ces deux tables ne sont quasiment jamais employés dans les mêmes scripts tu peux en faire deux.

Pour ton exemple, je n'en ferais qu'une.
Après rien ne t'oblige à faire un [i]"select *" [/i]lors de tes requètes, tu peux selectionné les champs que tu veux, donc dans ton cas, je neferais qu'une table.

Salut les gens,

À la recherche de meilleurs performances au niveau des requêtes SQL, pensez-vous qu'il soit utile de séparer en plusieurs tables des informations pouvant êtres contenues dans une seule ?

Pour imager mon questionnement voici un petit exemple :

Imaginons un simple système de posts (par exemple pour un forum très basique), dont voici les informations que l'on cherche à stocker concernant chaque post :
[list]- id (INT)
- user (INT)
- status (INT)
- title (VARCHAR)
- comment (TEXT)[/list]

Alors que les quatre premiers champs sont relativement petits, le dernier peut potentiellement stocker beaucoup d'information (vraiment beaucoup !). C'est alors que se pose la question de savoir si la séparation en deux tables peut apporter une hausse de performance :
TABLE 1
[list]- id (INT)
- user (INT)
- status (INT)
- title (VARCHAR)[/list]

TABLE 2
[list]- id (INT)
- belongTo (INT)
- message (TEXT)[/list]

L'avantage se retrouverait lors du [b]listage des posts[/b], la requête serait moins lourde, et l'on appellerait la deuxième table uniquement lorsque l'ont rentre dans une discussion où le contenu des messages apparait.

Au delà de l'aspect SQL, un soulagement du coté de PHP sur les pages de listage (où seul le titre des posts apparait) pourrait éventuellement se faire ressentir. Mais alors, est-ce des ralentissements pourraient se faire ressentir à cause des deux tables lors des accès aux discussion où le contenu des messages apparait ?

Merci de partager vos connaissance :wink: