[Conception] Performance de BDD [Résolu]

darkbob · 14/07/2006, 04h08

Une table associative normalisé d'environ 30000 lignes serait t'elle trop lourde pour un site ou la vitesse serait raisonable?

bkill · 14/07/2006, 08h23

Salut à toi aussi,

30.000 lignes? mais c'est rien du tout... Et puis ca dépend des capacités du hosting, fréquentations sur ce site, volume de requêtes à faire sur ces tables, indexation...

Merci? Mais de rien ...

Yogui · 14/07/2006, 13h18

Salut

Cela dépend également de la structure de cette table : la clef primaire ne contient-elle que des champs de type numérique, y a-t-il un index sur les champs de type texte qui sont très souvent utilisés, etc.

Normalement, le nombre d'enregistrements n'est pas trop un problème. Cela dépend également des opérations que tu fais : plutôt écriture, modification, recherche ou lecture ?

darkbob · 14/07/2006, 14h24

Mes 2 premières colonnes sont des foriegns keys et non j'ai pas d'index pour mon champ de texte mais je vais en mettre un. Pour les requetes elles sont assez variées mais puisque c'est un site interne il y aurait max 90 personnes en meme temps(je doute que ça arriverais un jours de toute facon

)
La table est normalisé donc personne n'accède à un même champ en meme temps.
Petite question , je sais que 2 requêtes UPDATE venant de 2 endroits différentes peut causer un deadlock ,ca peut tu faire la mme chose avec un SELECT?

merci

Yogui · 14/07/2006, 15h03

Houlà, la solution au deadlock a été trouvée depuis des années !
Le fait que tes champs soient des FK n'empêche pas que tu puisses (doives) avoir une PK.
Ne mets pas d'index à un champ si ce n'est pas absolument nécessaire : la quantité de recherches doit être largement supérieure à la quantité de mises à jour.

johnkro · 18/07/2006, 14h15

Je me permets de m'imiter dans cette conversation, car j'ai plusieurs questions concernant celle-ci :

C'est quoi la solution au deadlock?
C'est quoi la différences entre une FK et une PK?
"Ne mets pas d'index à un champ si ce n'est pas absolument nécessaire"
Il ne vaut pas mieux toujours mettre un index?

Yogui · 18/07/2006, 15h07

Tout ceci est, j'en suis certain, abordé dans divers tutoriels à doirte et à gauche...

Pour le deadlock, il suffit (en gros) d'utiliser correctement les sémaphores et/ou mutexes.

Pour les FK et PK, je ne répondrai pas ici car c'est trop vaste. Cherche un tutoriel de modélisation de bases de données, ce sera bien plus adapté qu'une réponse rapide de ma part.
Voici l'idée : une FK est un champ qui correspond à un champ faisant partie de la PK d'une table (la même ou bien une autre).

Mettre un champ à l'index oblige le SGBD à mettre à jour l'index à chaque fois qu'une modification est apportée à ce champ (INSERT, UPDATE ou DELETE). Si les requêtes sur ce champ ne sont pas au moins à 70% des SELECT pour 30% de modifications, évite l'index car tu predrais plus de temps à le mettre à jour que tu en gagnerais par sa présence.

Je te recommande vivement d'aller consulter nos cours.

johnkro · 18/07/2006, 15h10

Ok ok merci, je vais allez me renseigner plus amplement dans les tutos, c'était juste pour avoir une réponse succinte.

14/07/2006, 04h08	#1
darkbob Candidat au titre de Membre du Club Inscription : décembre 2005 Messages : 86 Détails du profil Informations forums : Inscription : décembre 2005 Messages : 86 Points : 13 Points : 13	[Conception] Performance de BDD Une table associative normalisé d'environ 30000 lignes serait t'elle trop lourde pour un site ou la vitesse serait raisonable?
	00

14/07/2006, 08h23	#2
bkill Membre expérimenté Développeur Web Inscription : avril 2006 Messages : 430 Détails du profil Informations personnelles : Localisation : Belgique Informations professionnelles : Activité : Développeur Web Informations forums : Inscription : avril 2006 Messages : 430 Points : 538 Points : 538	Salut à toi aussi, 30.000 lignes? mais c'est rien du tout... Et puis ca dépend des capacités du hosting, fréquentations sur ce site, volume de requêtes à faire sur ces tables, indexation... Merci? Mais de rien ... __________________ Merci à Microsoft pour avoir transformé un métier relativement terne et basé sur une approche bêtement technique et rigoureuse des faits, en challenge quotidien, nécessitant une remise en question permanente à l'échelle du quart d'heure
	00

14/07/2006, 13h18	#3
Yogui Rédacteur Guillaume Rossolini Directeur technique Inscription : février 2004 Messages : 13 720 Détails du profil Informations personnelles : Nom : Guillaume Rossolini Localisation : France Informations professionnelles : Activité : Directeur technique Informations forums : Inscription : février 2004 Messages : 13 720 Points : 17 355 Points : 17 355	Salut Cela dépend également de la structure de cette table : la clef primaire ne contient-elle que des champs de type numérique, y a-t-il un index sur les champs de type texte qui sont très souvent utilisés, etc. Normalement, le nombre d'enregistrements n'est pas trop un problème. Cela dépend également des opérations que tu fais : plutôt écriture, modification, recherche ou lecture ? __________________ Mes articles - Zend Certified Engineer (PHP + Zend Framework) Ressources PHP - Ressources Zend Framework
	00

14/07/2006, 15h03	#5
Yogui Rédacteur Guillaume Rossolini Directeur technique Inscription : février 2004 Messages : 13 720 Détails du profil Informations personnelles : Nom : Guillaume Rossolini Localisation : France Informations professionnelles : Activité : Directeur technique Informations forums : Inscription : février 2004 Messages : 13 720 Points : 17 355 Points : 17 355	Houlà, la solution au deadlock a été trouvée depuis des années ! Le fait que tes champs soient des FK n'empêche pas que tu puisses (doives) avoir une PK. Ne mets pas d'index à un champ si ce n'est pas absolument nécessaire : la quantité de recherches doit être largement supérieure à la quantité de mises à jour. __________________ Mes articles - Zend Certified Engineer (PHP + Zend Framework) Ressources PHP - Ressources Zend Framework
	00

18/07/2006, 14h15	#6
johnkro Membre habitué Étudiant Inscription : juin 2006 Messages : 276 Détails du profil Informations personnelles : Âge : 27 Informations professionnelles : Activité : Étudiant Informations forums : Inscription : juin 2006 Messages : 276 Points : 146 Points : 146	Je me permets de m'imiter dans cette conversation, car j'ai plusieurs questions concernant celle-ci : C'est quoi la solution au deadlock? C'est quoi la différences entre une FK et une PK? "Ne mets pas d'index à un champ si ce n'est pas absolument nécessaire" Il ne vaut pas mieux toujours mettre un index? __________________ L'eau est un liquide si corrosif, qu'une seule goutte suffit pour troubler le pastis.
	00

14/07/2006, 14h24	#4
darkbob Candidat au titre de Membre du Club Inscription : décembre 2005 Messages : 86 Détails du profil Informations forums : Inscription : décembre 2005 Messages : 86 Points : 13 Points : 13	Mes 2 premières colonnes sont des foriegns keys et non j'ai pas d'index pour mon champ de texte mais je vais en mettre un. Pour les requetes elles sont assez variées mais puisque c'est un site interne il y aurait max 90 personnes en meme temps(je doute que ça arriverais un jours de toute facon ) La table est normalisé donc personne n'accède à un même champ en meme temps. Petite question , je sais que 2 requêtes UPDATE venant de 2 endroits différentes peut causer un deadlock ,ca peut tu faire la mme chose avec un SELECT? merci
	00

18/07/2006, 15h07	#7
Yogui Rédacteur Guillaume Rossolini Directeur technique Inscription : février 2004 Messages : 13 720 Détails du profil Informations personnelles : Nom : Guillaume Rossolini Localisation : France Informations professionnelles : Activité : Directeur technique Informations forums : Inscription : février 2004 Messages : 13 720 Points : 17 355 Points : 17 355	Tout ceci est, j'en suis certain, abordé dans divers tutoriels à doirte et à gauche... Pour le deadlock, il suffit (en gros) d'utiliser correctement les sémaphores et/ou mutexes. Pour les FK et PK, je ne répondrai pas ici car c'est trop vaste. Cherche un tutoriel de modélisation de bases de données, ce sera bien plus adapté qu'une réponse rapide de ma part. Voici l'idée : une FK est un champ qui correspond à un champ faisant partie de la PK d'une table (la même ou bien une autre). Mettre un champ à l'index oblige le SGBD à mettre à jour l'index à chaque fois qu'une modification est apportée à ce champ (INSERT, UPDATE ou DELETE). Si les requêtes sur ce champ ne sont pas au moins à 70% des SELECT pour 30% de modifications, évite l'index car tu predrais plus de temps à le mettre à jour que tu en gagnerais par sa présence. Je te recommande vivement d'aller consulter nos cours. __________________ Mes articles - Zend Certified Engineer (PHP + Zend Framework) Ressources PHP - Ressources Zend Framework
	00

18/07/2006, 15h10	#8
johnkro Membre habitué Étudiant Inscription : juin 2006 Messages : 276 Détails du profil Informations personnelles : Âge : 27 Informations professionnelles : Activité : Étudiant Informations forums : Inscription : juin 2006 Messages : 276 Points : 146 Points : 146	Ok ok merci, je vais allez me renseigner plus amplement dans les tutos, c'était juste pour avoir une réponse succinte. __________________ L'eau est un liquide si corrosif, qu'une seule goutte suffit pour troubler le pastis.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email