Discussion :

[[DreaMs]]

Bonjour,

Je dois concevoir une base et de données et je me pose quelques questions sur l'optimisation de mes tables ... par exemple

(je développe surtout avec SQL Server mais MySQL Oracle m'interesse aussi)
- Vaut-il mieux avoir une table 100 par 100 ou une table 1000 par 10 (j'imagine qu'en terme de place c'est pareil mais qu'en est-il en terme de performance ? en terme de recherche dedans par exemple ?)

- A partir de combien d'enregistrement une table SQL Server peut-être considéré comme grosse et faire baisser de manière significatives les performances ?

- Est-ce que un champ varchar qui est à <NULL> occupe qd même de la place mémoire dans la base de données ?

Voila si vous avez des sites qui parle de ces sujets je suis preneur aussi.

D'avance merci

DreaMs

[Alexandre T]

- Vaut-il mieux avoir une table 100 par 100 ou une table 1000 par 10 (j'imagine qu'en terme de place c'est pareil mais qu'en est-il en terme de performance ? en terme de recherche dedans par exemple ?)

Je n'ai pas compris...

- A partir de combien d'enregistrement une table SQL Server peut-être considéré comme grosse et faire baisser de manière significatives les performances ?

Cela dépend de l'usage de la table et du serveur et des clefs et des index.
Une table qui subit plus d'insertions que de lecture pleine d'index sera lente... Une table qui subit bien plus de lectures que d'écritures sans index sera de plus en plus lente...

- Est-ce que un champ varchar qui est à <NULL> occupe qd même de la place mémoire dans la base de données ?

Oui il prend un octet présent pour indiquer que la valeur "est NULL".

Voila si vous avez des sites qui parle de ces sujets je suis preneur aussi.

http://sql.developpez.com

[Médiat]

- Est-ce que un champ varchar qui est à <NULL> occupe qd même de la place mémoire dans la base de données ?

Oui il prend un octet présent pour indiquer que la valeur "est NULL".

Je ne connais pas la réponse pour SQLServer, mais comme la question de DreaMs semble générale, j'ajoute que je connais au moins un moteur (SQLBase) pour lequel un champ NULL (quelque soit le type) ne prend pas de place (chaque zone mémoire contenant la valeur d'une colonne est précédée d'un octet identifiant la colonne, pour une colonne NULL, son identifiant n'apparaît même pas). Enorme avantage : pour ajouter une colonne (nullable) à une table de 1 000 000 000 de lignes cela prend quelques ms, puisque la seule modification est faite dans le dictionnaire.