Structure de base de données d'application modulaire

Question

Je construis une application modulaire. Grâce à la configuration, vous pouvez activer et désactiver ces modules d’application. J'essaie de déterminer quelle structure de base de données (mssql2005) je devrais utiliser pour les tables qui contiennent des données pour chacun des modules. Les deux options auxquelles j'ai pensé sont les suivantes:

1. Mettez toutes les tables dans une grande base de données et préfixez-les en fonction du module.
2. Séparez les tables de chaque module dans différentes bases de données.

J'ai des données communes à tous les modules. Par conséquent, si j'utilise la solution 2, je ne sais pas comment gérer ces données communes (telles que les utilisateurs).

-

Pour clarifier une chose, ces modules pourraient éventuellement être vendus séparément et les paramètres de configuration ne sont pas contrôlés par le client. C’est pourquoi j’envisage même de les décomposer en tableaux distincts.

Answer 1

Ma recommandation alternative à celles que vous avez proposées serait la fonctionnalité de schéma disponible dans SQL Server 2005.

Veuillez lire ce lien pour plus d'informations ...

http://searchsqlserver.techtarget.com/tip/0 , 289483, sid87_gci1184503,00.html

Answer 2

Si c’était moi, je normaliserais tout d’abord l’application. Je développerais une structure qui place toutes les données communes dans des tables partagées et ne laisse que les données uniques à chaque module dans des tables de modules spécifiques.

Si les données contenues dans les tables partagées sont vraiment communes à tous les modules et si vous essayez de ne pas regrouper les cas marginaux dans ces tables "communes", l'activation ou la désactivation d'un module ne devrait pas affecter le fonctionnement de l'un des modules. autre module et vous avez maintenant peu (le cas échéant) de duplication de données.

Answer 3

J'aurais une base de données. Cela simplifie énormément la gestion de la solution.

Ensuite, je normaliserais mes données. Cela simplifie les problèmes d’intégrité des données.

Ensuite, j’ajouterais des tables pour chaque module, selon les besoins, dans la base de données de base. Je distribuerais cette base de données de base mais je ne distribuerais pas les données pour les modules inutilisés. Chaque module distribue ses propres données lorsqu’il est installé (de manière appropriée par son installateur plutôt que intégré au module lui-même).

Les préfixes de table ne vont pas importent beaucoup dans un sens ou dans l'autre et le bon côté du partage de la base de données est que vous pouvez accéder à chaque table à partir de n'importe quel module et avoir un fichier de configuration partagé, etc. ...

Answer 4

Si vous avez besoin d'une requête sur les tables, je suggère de les placer dans une base de données, sinon cela ne fait aucune différence. Cependant, il serait beaucoup plus facile de gérer une seule base de données.

Sauf si vous avez besoin de plusieurs bases de données, je suggère d'en utiliser une seule.