Geek Answers Handbook

The modular structure of the application database

I am creating a modular application. Through the configuration, you can turn these application modules on and off. I am trying to determine which database structure (mssql2005) I should use for tables containing data for each of the modules. Two options I was thinking about:

  • Put all the tables in one large database and the table prefix according to the module.
  • Separate the tables for each module into different databases.

I have data common to all modules, so if I use solution 2, I'm not sure how to manage this shared data (such as users).

-

To clarify one thing, these modules will potentially be sold separately, and configuration settings are something that are not controlled by the client. That is why I even plan to split them into separate tables.

+4
source share
4 answers

My alternative recommendation to the ones you suggested would be the Schema functionality available in SQL Server 2005.

Please read this link for more information ...

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

+3
source

If it were me, I would completely normalize the application in the first place. I would develop a structure that puts all the common data in common tables and leaves only unique data for each module in specific module tables.

If the data in the common tables are truly common for all modules, and there are no edges that you are trying to combine into these "common" tables, then turning one module on or off should not affect the operation of any other module, and now you are a little (if is) duplication of data.

+1
source

I will have one database. This simplifies solution management.

Then I would normalize my data. This simplifies data integrity issues.

Then I would add tables for each module, as required, to the base database. I would distribute this base database, but I will not distribute data for unused modules. Each module will distribute its own data when it is installed (perhaps by its installer, and not built into the module itself).

Table prefixes don't matter much, anyway, and the nice part of database sharing is that you can access each table from any module and have a common configuration file, etc.

+1
source

If you need a query on tables, I suggest placing them in one database, otherwise this will not change the situation. However, having one database would be much easier to maintain.

If you do not have a requirement for multiple databases, I suggest using only one.

0
source

More articles:


All Articles