Discussion :

[LeNeutrino]

salut à tous,
j'ai deux préoccupation
je developpe une appli qui traite de gros fichiers avec des milliers de lignes (au moins 100 000 ) pour une entreprise de telecommunication. je dois charger 14 fichiers comme ça par jour.
Ma BD est sous SQL Server 2000 et elle comporte 54 tables independantes, sans jointures aucune.
les clés primaires de mes tables sont auto-incrémentées et de type int.
mes préoccupations sont les suivantes :
1/ la clé primaire croit tres vite vu le nombre important de lignes et je m'inquiete parce que la limite sera tres vite atteinte (au bout d'une semaine je pense).je me demande s'il est interressant de creer mes tables sans clé primaire.

2/je dois faire des requetes en fonction des dates et de certains autres parametres et j'exporte par la suite le resultat sous Excel.Mais ma requete est tres lente vu le nombre tres grd de lignes à trier.
dois je creer des index sur les colonnes de tri vu que les valeurs se repetent sans cesse dans ces colonnes ? comment m'arranger pour que mes requetes soient plus rapide ?

Merci de m'aider!!

[rudib]

Bonjour,

Oui, tu dois créer une clé primaire pour garantir l'unicité des lignes. Selon les volumes dont tu parles l'identity ne sera pas mangé au bout d'une semaine. La valeur max d'un int est de plus de 2 mia. Mais tu peux changer ton type en bigint.

Il faut créer des index sur les colonnes de filtrage, sinon tes performances vont être catastrophiques. Regarde les articles de developpez sur les index, notamment ceux de SQLPro et mon article : http://rudi.developpez.com/sqlserver.../optimisation/

[usf70]

Vu le nombre de lignes important que tu insères, il faudrait aussi, en plus des conseils de rudib, faire un rebuild de tes indexs assez fréquemment, ainsi qu'un recalcul des statistiques. Car à mon avis tu vas avoir des indexs fragmentés assez vite ....

[HULK]

pour reindexer ta base c'est ici :

http://sqlserver.developpez.com/faq/...formance#Perf1

[LeNeutrino]

Salut à tous et merci de m'aider !
mais j'ai lu dans MICROSOFT OFFICIAL COURSE 2327 A Programmation d'une BD SQL Server 2000 que les index sont avantageux que lorsque la BD a des tables avec des jointures entre elles (c'est pas le cas chez moi mes tables sont autonomes ) et lorsqueles colonnes indexées ne presentent pas de redondance d'information(C'est egalement pas le cas chez moi). je me demande si ça me sera plus utile que je n'aurai des pb !

Vu le nombre de lignes important que tu insères, il faudrait aussi, en plus des conseils de rudib, faire un rebuild de tes indexs assez fréquemment, ainsi qu'un recalcul des statistiques. Car à mon avis tu vas avoir des indexs fragmentés assez vite ....

je ne comprends pas trop ! je ne suis pas trop callé en Administration

[ZERS]

Salut à tous et merci de m'aider !
mais j'ai lu dans MICROSOFT OFFICIAL COURSE 2327 A Programmation d'une BD SQL Server 2000 que les index sont avantageux que lorsque la BD a des tables avec des jointures entre elles (c'est pas le cas chez moi mes tables sont autonomes ) et lorsqueles colonnes indexées ne presentent pas de redondance d'information(C'est egalement pas le cas chez moi). je me demande si ça me sera plus utile que je n'aurai des pb !


je ne comprends pas trop ! je ne suis pas trop callé en Administration

Salut petit retour d'expérience d'un non DBA, non spécialiste es-sql serveur :

1- Un index c'est pas uniquement sur des jointures, mais aussi sur les colonnes de clause "WHERE"..
Par exemple WHERE toto = 1, c'est pas une jointure, mais tu filtres sur toto. Si il trouve les 1 plus vite grace à l'index, il n'a pas besoin de parcourir toute la table.

2- J'ai appris ici (grace à rudi ) que plus les valeurs de la colonne sont disparates, plus tu as interet à mettre un index.

3- Quant à la remarque de USF70, je vais la reformuler en français non techos . Plus tu insères ou supprimes de lignes indexées, plus les indexs se "désordonnent", donc tu perds de la performance. Il est donc bon, de temps en temps, de "recomplier" l'index.
Perso, j'opte pour la "veille methode" : je supprime l'index, puis le recréé dans la foulée. Mais c'est un peu hasbeen comme pratique