Discussion :

[Delphi-ne]

J'ai une base de données qui comptait un peu plus de 25 millions de lignes.
Nous en avons expurgé un peu moins de la moitié (tout ce qui concernant l'exercice 2007)

Je suis étonné que le volume du MDF reste identique.
J'ai essayé de sauvegarder et de restaurer mais je reste toujours à une taille de 14 GO soit à peu près la même chose qu'avant.
Cela n'est pas bloquant mais j'aimerais savoir s'il existe un moyen de pallier cela.

[Jinroh77]

Lorsque le moteur prend de la place, il la garde.
Il n'a en effet pas de raison de restituer celle-ci car il risque d'en avoir besoin plus tard.
Si le moteur restitue l'espace disque, au moment ou la base va nécessiter de la place, le moteur va devoir recommencer toutes les opération, très couteuses, d'allocation de cet espace.

Si vous venez de faire un nettoyage vraiment très important et que la base ne récupérera pas cette taille avant 3 ou 4 ans, dans ce cas, jetez un oeil à la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC SHRINKFILE

[SQLpro]

Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro?ti..._fichiers_et_t
Si vous voulez pourrir les performances de votre BD, n'hésitez pas à diminuer la taille des fichiers de votre base !

a +

[Delphi-ne]

Merci à tous les deux.

J'ai lu l'article cité en lien.
Je ne conteste pas le bien fondé des principes qui y sont détaillés mais je pense qu'il faut aussi tenir compte des spécificités des applications et de leur domaine fonctionnel.
J'en avais d'ailleurs lu un autre expliquant qu'un table de plus de 30 champs était une aberration.
Dans le cas présent je ne dispose d'aucun moyen d'anticiper le volume. Je ne peux aujourd'hui connaître ni le nombre de clients que j'aurai à gérer, ni le nombre de lignes de détail qu'ils me transmettront et que peuvent varier entre quelques centaines de millers et plusieurs millions.

J'ai donc appris à conjuguer le conditionnel...

[c6teen]

Merci à tous les deux.

J'ai lu l'article cité en lien.
Je ne conteste pas le bien fondé des principes qui y sont détaillés mais je pense qu'il faut aussi tenir compte des spécificités des applications et de leur domaine fonctionnel.
J'en avais d'ailleurs lu un autre expliquant qu'un table de plus de 30 champs était une aberration.
Dans le cas présent je ne dispose d'aucun moyen d'anticiper le volume. Je ne peux aujourd'hui connaître ni le nombre de clients que j'aurai à gérer, ni le nombre de lignes de détail qu'ils me transmettront et que peuvent varier entre quelques centaines de millers et plusieurs millions.

J'ai donc appris à conjuguer le conditionnel...

+1
Un simple exemple ne suffit pas à démontrer.
Si certaines règles peuvent s'appliquer à une majorité de bases de données, il est nécessaire d'étudier l'application dans son ensemble avant d'effectuer des choix techniques.
De plus, il faut reconnaitre que le passif d'une application peut avoir énormément d'implications sur le travail du DBA (qu'il soit amateur ou non).
C'est pour cela qu'un DBA doit sans cesse se remettre en cause et remettre en cause le système mis en place pour atteindre les objectifs désignés (par la direction).
Vous verrez que après le conditionnel, vient le futur et le futur antérieur.