Bonjour,
j'ai besoin pour mon taf de charger 30 GO de données dans une BDD.
Access ne supportant pas une telle volumétrie, je me tourne vers SQL Server 2005 mais je n'arrive pas à trouver de réponses aux questions suivantes :
 
1 - SQL Server peut-il gérer une BDD de 30 GO (environ 200 tables, dont certaines atteignant 5 GO) ?
 
2 - Les tables que je charge vont contenir de nombreux enregistrements dont je n'aurais pas besoin en exploitation pour la suite. Comment puis-je avoir une estimation du temps que prendra une requète (créant une 2nd BDD avec uniquement les enregistrements nécessaires) lancée sur ces 30 Go de données?
 
Merci d'avance

1- oui  
 
2- ce paramètre dépend de la structure des table, du nombre d'enregistrement,des requêtes effectuées, des performances de ton serveur et de sa charge . C'est difficilement estimable a priori
 
juste une question, comment tu stockes quoi dans tes tables pour avoir tant de données ?

Des données clients, contrats...

a moins de stocker directement des documents scanner dans les bases,  le volume me semble important  
 
ca corespond a des tables de plusieurs milliards d'enregistrements

certaines tables oui!

fais des index avec conditions, comme ça la taille de ta table aura moins d'impact si tu ne travailles que sur un sous-ensemble de données.

cad des index avec conditions?

Et puis ça dépend aussi de tes index déjà en place. Si t'as une table avec une colonne date, et que toi ce qui t'intéresses, c'est uniquement l'année courante, le fait d'indexer cette colonne date ça va suffir pour sélectionner d'un coup tous les 2008.

 
pas forcément vrai si on y accède n'importe comment

en plus des index "avec conditition" (je connais pas, faudra que je jette un oeil), tu peux créer des "partitions".
 
les partition sont un moyen efficace pour découper de façon transparente des tables volumineuses. ça se base sur des ruptures de champ.
 
par exemple, dans une table de contrat, j'imagine que les contrats résiliés sont peu utilisés. idem pour les contrats sans mouvement depuis 1 an par exemple.
 
du coup tu peux créer un partitionnement sur ces deux critères, et ainsi bénéficier de 4 partitions. ainsi les enregistrements actifs de moins d'un an seront regroupés dans une sorte de "mini table" qui sera très rapide à utiliser, sans pour autant remettre en question la structure de la base.

 
J'ai travaillé sur des base entre 30 et 50 Go avec certaines tables à 10 Go.
Et j'avais "seulement" 30 millions d'enregistrements de chaines de caracteres, certainement pas milliards !!
Tout depend du nombre de champs et de leur taille.

Oui j'ai vérifié mes tables avec le plus d'enregistrements en ont 35 millions.
Mais après j'ai énormément de champs texte c pour ca.
 
Je devrais faire mes essais lundi voir si les tps de traitement sont pas trop long

il y apeut etre moyen de segmenter l'information :
une table avec les données auxquelles tu accède souvent , et des tables secondaire qui contiennt les grosses données moins courantes

Des partitions dans ce cas
 
Couper en mini-tables c'est la plaie pour utiliser la base ensuite...