Discussion :

[shadeoner]

Bonjour,

je suis en train d'élaborer le schéma de la base de données d'un gros site.

Dans mon analyse j'ai deux solutions :

- soit je fais une table pour les résultats des recherches puis une autre pour les détails de résultats (complèterait alors les infos de la table recherche), j'aurais alors deux tables de 25 champs chacune

- soit je mets toutes les informations dans une seule et même table (uniquement du select) j'aurais alors une table avec environs 50 champs

J'opterais pour la première soluce à première vue....

Merci pour votre aide.

[berceker united]

Alors, si la relation entre les deux tables c'est du 1-1 alors il n'est pas utile de faire deux tables. Même si 50 champs parait gros parce que c'est peut habituel, il y a pas de contre indication.
La lecture liniaire d'une table est plus rapide qu'une lecture sur plusieurs tables. Optimise sur le type de champs.
Si tu ne fais que de l'INSERT et SELECT utilise le moteur de table ARCHIVE.
Bientôt, il y aura un article traitant des différents moteurs de table.

[shadeoner]

Alors, si la relation entre les deux tables c'est du 1-1 alors il n'est pas utile de faire deux tables. Même si 50 champs parait gros parce que c'est peut habituel, il y a pas de contre indication.
La lecture liniaire d'une table est plus rapide qu'une lecture sur plusieurs tables. Optimise sur le type de champs.
Si tu ne fais que de l'INSERT et SELECT utilise le moteur de table ARCHIVE.
Bientôt, il y aura un article traitant des différents moteurs de table.

Super, merci pour ta réponse, c'est un peu ce que je pensais aussi...
En fait il n'y aura même pas d'INSERT que du select ! je ne connais pas le moteur Archive, je vais voir ça ! J'ai aussi vu le partitionning qui m'a l'air aussi très efficace ? Peut-être même allier Archive et partitionning ?

Petit édit : apparemment il n'est pas possible d'indexer des colonnes sur la table, ça va être chaud alors... j'ai besoin d'indexer toutes les colonnes qui sont utilisées par le moteur de recherche

[berceker united]

Effectivement, si tu as besoin d'utiliser des index tu pourras pas utiliser l'INDEX.
Il y a me moteur MERGE qui pourra peut être t'aider. En faite, tu découpes tes données dans plusieurs tables. Le moteur MERGE va faire l'équivalent d'un UNION entre les tables.
Voici un ébauche sur l'article concernant les moteurs de table Mysql.
C'est pas officiel et pas corrigé concernant les faute. Donc prudence
http://www.php-girl.fr/Articles/arti.../sommaire.html

[shadeoner]

C'est encore moi

J'ai une question triviale !
Sur une table de 40 go environs, avec 3 millions d'enregistrements, est-ce qu'une table avec 300 colonnes aurait toujours des très bons temps ?

[berceker united]

A froid je ne serait dire. En fait, tout dépend du type de champs. ça dépend de ce qui est demandé. Il est vrai que 40G pour seulement 3 000 0000 d'enregistrements. C'est énorme le coût d'une ligne si je devais faire 40g/3 millions. Si j'ai biens fait mon calcule ça fait du 14ko/lignes. J'aurais proposé d'utiliser un autre moteur que celle habituel. Dans la mesure ou c'est possible.
Sur 300 champs ça depend mais ça reste énorme mais peut être pas insurmontable. Il faut faire des tests de comparaison.