Discussion :

[darkbob]

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

[bkill]

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]

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]

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]

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]

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?