Une table associative normalisé d'environ 30000 lignes serait t'elle trop lourde pour un site ou la vitesse serait raisonable?
Version imprimable
Une table associative normalisé d'environ 30000 lignes serait t'elle trop lourde pour un site ou la vitesse serait raisonable?
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 ...
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 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 :P)
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
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.
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?
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.
Ok ok merci, je vais allez me renseigner plus amplement dans les tutos, c'était juste pour avoir une réponse succinte.