Comment diviser une BD en deux dans SQL Server 2008 ?

Robin :

Si vous souhaitez séparer physiquement les données volatiles et statiques, je vous suggère de vous pencher sur l'option groupes de fichiers caractéristique. (Faites défiler la page jusqu'au milieu de cette page web pour accéder aux informations pertinentes).

Les groupes de fichiers vous permettent de regrouper des tableaux. Cela vous permet de contrôler plus facilement leur emplacement physique (les données souvent utilisées peuvent être placées sur un SSD rapide et les autres données sur des disques durs plus lents, par exemple), de contrôler l'accès en lecture/écriture (un groupe de fichiers peut être marqué en lecture seule) et d'améliorer les schémas de sauvegarde/restauration (un groupe de fichiers peut être sauvegardé ou restauré). Étant donné que toutes les tables se trouvent dans la même base de données, indépendamment du groupe de fichiers, l'intégrité référentielle déclarative (DRI, également connue sous le nom de "clés étrangères") fonctionne toujours.

Si vous insistez pour utiliser des bases de données différentes, vous ne pourrez pas utiliser les clés étrangères et devrez utiliser une autre méthode. Cela signifie que vous devrez écrire vos propres déclencheurs (ou peut-être vos propres procédures). Écrire votre propre code signifie un travail supplémentaire, il y a toujours la possibilité de bogues dans ce code et les déclencheurs sont généralement moins performants que les DRI. L'utilisation de bases de données différentes présente d'autres aspects négatifs, dont les plus évidents sont la sécurité (vous aurez deux fois plus de choses à gérer) et la récupération à un moment donné (il est plus difficile d'obtenir une cohérence entre deux bases de données qu'entre une seule). Ces aspects peuvent ne pas sembler importants aujourd'hui, mais :

1. Il est plus facile de faire les choses correctement aujourd'hui que de les réparer. plus tard.
2. Il est préférable d'acquérir de bonnes habitudes.

Laissez-moi vous dire que vous êtes désemparé et que vous n'avez aucune idée de ce que vous voulez.

Vous voyez, la taille du serveur sql est un problème - soit en express lorsque vous atteignez la limite stricte de 10gb, soit sur un "vrai" serveur lorsque vous atteignez - aucune idée, peut-être 10000gb ou plus.

Vous ne pouvez rien faire et seulement ajouter de la complexité (les clés étrangères ne fonctionnent pas, il faut les remplacer par des triggers). Si c'est deux bases de données, alors vous ne pouvez rien faire, si c'est deux serveurs, vous ajoutez la latence et une tonne d'autres problèmes.

Je commencerais par supposer que l'exigence que vous présentez ici n'est pas valable. Pourquoi pensez-vous qu'il y a un besoin pour cela ?

J'ai une base de données de près de 1000 Go à la maison et aucun problème de taille.