Bdd
6 messages
• Page 1 sur 1
- chris81
- WRInaute discret

- Messages: 184
- Inscription: 8 Mar 2005
Bdd
Bonjour
voila, je me pose une petite question ! Que vaut'il mieu ?
- Une table qui contient 10 000 entrée
ou
- Les 10 000 entrées réparties sur plusieurs tables
est ce que sa joue beaucoup sur la vitesse d'exécution ?
Il sagirai d'une Bdd sur des hébergrements, gites, campings,hotels...
j'ais pensez répartir les hébergements sur plusieurs Tables, celon le type.
Merci d'avence pour les réponces
voila, je me pose une petite question ! Que vaut'il mieu ?
- Une table qui contient 10 000 entrée
ou
- Les 10 000 entrées réparties sur plusieurs tables
est ce que sa joue beaucoup sur la vitesse d'exécution ?
Il sagirai d'une Bdd sur des hébergrements, gites, campings,hotels...
j'ais pensez répartir les hébergements sur plusieurs Tables, celon le type.
Merci d'avence pour les réponces
-

Leonick - WRInaute accro

- Messages: 18786
- Inscription: 8 Aoû 2004
la répartition d'informations dans plusieurs tables ne se fait pas de cette manière.
il faut essayer de voir d'abord tout ce qui peut être factorisé : si on veut ajouter le nom de la ville, longitude, latitude, nb habitants, etc... on ne va pas le répéter sur chaque ligne de la base et donc on va créer une table supplémentaire qui sera reliée aux hébergements
et non pas essayer de couper la base en informations plus petites. Le nombre de lignes d'une table ne veut absolument rien dire en terme de rapidité, cela dépend de la longueur de l'enregistrement du type d'informations dans chaque champs, des index, etc...
il faut essayer de voir d'abord tout ce qui peut être factorisé : si on veut ajouter le nom de la ville, longitude, latitude, nb habitants, etc... on ne va pas le répéter sur chaque ligne de la base et donc on va créer une table supplémentaire qui sera reliée aux hébergements
et non pas essayer de couper la base en informations plus petites. Le nombre de lignes d'une table ne veut absolument rien dire en terme de rapidité, cela dépend de la longueur de l'enregistrement du type d'informations dans chaque champs, des index, etc...
- chris81
- WRInaute discret

- Messages: 184
- Inscription: 8 Mar 2005
pour chaques tables il y a environ 10 champs liés à l'hébergement
il y a egalement une table pour le lieux, le cantons et de nombreuses informations sur les villes.
et une table qui contient les informations des utilisateurs qui proposes leur hébergements
Je penssait que de séparer les hébergement par types serai plus rapide pour le traitement des infos, ainsi si un internotes demandes de voire tous les gites, de séparer les hébergments, sa évites d'avoires plus de 10milles informations, multiplié par le nombres de schamps !
est ce que mon résonement est faux ?
il y a egalement une table pour le lieux, le cantons et de nombreuses informations sur les villes.
et une table qui contient les informations des utilisateurs qui proposes leur hébergements
Je penssait que de séparer les hébergement par types serai plus rapide pour le traitement des infos, ainsi si un internotes demandes de voire tous les gites, de séparer les hébergments, sa évites d'avoires plus de 10milles informations, multiplié par le nombres de schamps !
est ce que mon résonement est faux ?
-

Leonick - WRInaute accro

- Messages: 18786
- Inscription: 8 Aoû 2004
et si je veux une information sur tous les hébergements d'une ville, triés par prix/personne ou par nb de place.
il faudrait interroger plusieurs tables, mettre dans un tableau temporaire multidimentionnel le trier puis l'afficher.
Un beau bazard
il faudrait interroger plusieurs tables, mettre dans un tableau temporaire multidimentionnel le trier puis l'afficher.
Un beau bazard
- chris81
- WRInaute discret

- Messages: 184
- Inscription: 8 Mar 2005
il suffirai de faire une requette SQL englobant toutes les tables avec un UNION ?
finalement je me demande si j'ai pris la bonne dessision !
j'était perssuadé que de faire un type d'hébergment par table renderai l'exécution de la commande plus rapide. par contre je me doutait que ce serrai un peut plus compliqué de le traiter derrière, mais pas impossible
finalement je me demande si j'ai pris la bonne dessision !
j'était perssuadé que de faire un type d'hébergment par table renderai l'exécution de la commande plus rapide. par contre je me doutait que ce serrai un peut plus compliqué de le traiter derrière, mais pas impossible
6 messages
• Page 1 sur 1
Lectures recommandées sur ce thème :
- Script de mise en cache des pages (PHP MySQL) - 09-08-2010
Qui est en ligne
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 0 invités
