Dois-je créer plusieurs petites bases de données d'applications ou une grande base de données?

Question

Nous migrons plusieurs anciennes applications mainframe pour un client vers des applications ASP.NET + SQL Server 2005 plus récentes. Chaque application est généralement considérée comme autonome, sans données partagées entre eux, et gérer des besoins spécifiques d'inventaire ou de vacances. Les données sont petites et ne devraient pas dépasser un seul SQL Server. Est-il préférable de créer une grande base de données pour toutes ces applications à partager, ou plusieurs bases de données plus petites, une pour chaque application?

En général, nous préférons une petite base de données par application, mais on pourrait faire valoir qu'une base de données plus grande est plus facile à gérer pour les sauvegardes et la sécurité. Quels facteurs devraient être pris en compte pour prendre cette décision?

Answer 1

Je recommande fortement la petite approche par application. Si une application plante et corrompt ses tables, vous ne voulez pas avoir à effectuer une restauration sélective de certaines tables. Être capable de déposer et charger est bien meilleur pour la maintenance et les mises à jour imprévues que vous aurez à faire dans le futur.

Answer 2

Vous devez utiliser des bases de données distinctes. Ils peuvent tous être exécutés à partir de la même instance de SQL Server.

Answer 3

Cela dépend si ces applications doivent partager les données ou non. Si c'est le cas, il est préférable d'avoir une base de données derrière eux. Si ce n'est pas le cas, il est préférable de les séparer de sorte qu'à l'avenir vous ayez la liberté de déplacer (isoler) les applications encore plus.

Pensez à la façon dont vos applications vont être utilisées. Parce que lorsque vous avez une base de données et par exemple une table pour les clients, vous pouvez rencontrer des problèmes de verrouillage lorsque plusieurs applications accèdent à la même table.

Answer 4

J'utiliserais l'approche d'une base de données par application si le magasin de données ne se chevauchait pas entre les applications. De cette façon, si l'un d'entre eux dépasse le serveur de base de données actuel, vous pouvez le déplacer vers son propre serveur avec une relative facilité. En outre, d'un point de vue de sauvegarde/restauration, il est probablement plus facile de restaurer la base de données pour une seule application pour la faire fonctionner au lieu de devoir restaurer l'ensemble (car ils sont dans une base de données unique) puis ramasser les bits dont vous avez réellement besoin pour restaurer le service.

Answer 5

Je vous suggère de créer une solution DataBase avec plusieurs catalogues à l'intérieur. Chaque catalogue est indépendant et compris comme une base de données distincte, bien qu'étant sous la même solution vous offre les avantages que vous avez mentionnés auparavant, comme la sauvegarde et la gestion. Après cela, chaque catalogue contiendrait ses propres tables de données, etc ... Les catalogues ne mettent pas en relation les données entre elles comme table à table.