我正在构建一个模块化应用程序。通过配置,您可以打开和关闭这些应用程序模块。我正在尝试确定应该为包含每个模块的数据的表使用什么数据库结构 (mssql2005)。我想到的两个选项是:
- 将所有表放入一个大数据库中,并根据模块为表添加前缀。
- 将每个模块的表分离到不同的数据库中。
我确实有所有模块共有的数据,所以如果我使用解决方案 2,我不确定如何管理这些公共数据(例如用户)。
--
为了澄清一件事,这些模块可能会单独出售,并且配置设置不受客户端控制。这就是为什么我什至考虑将它们分成单独的表格。
我正在构建一个模块化应用程序。通过配置,您可以打开和关闭这些应用程序模块。我正在尝试确定应该为包含每个模块的数据的表使用什么数据库结构 (mssql2005)。我想到的两个选项是:
我确实有所有模块共有的数据,所以如果我使用解决方案 2,我不确定如何管理这些公共数据(例如用户)。
--
为了澄清一件事,这些模块可能会单独出售,并且配置设置不受客户端控制。这就是为什么我什至考虑将它们分成单独的表格。
对于您提出的建议,我的替代建议是 SQL Server 2005 中可用的架构功能。
请阅读此链接以获取更多信息...
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1184503,00.html
如果是我,我会先完全规范化应用程序。我将开发一种结构,将所有公共数据放在共享表中,并且只将每个模块唯一的数据保留在特定模块表中。
如果共享表中的数据对所有模块确实是通用的,并且没有您试图集中到这些“通用”表中的极端情况,那么打开或关闭一个模块应该不会影响任何其他模块的功能,并且你现在很少(如果有的话)重复数据。
我会有一个数据库。这极大地简化了解决方案的管理。
然后我会标准化我的数据。这简化了数据完整性问题。
然后我会根据需要将每个模块的表添加到基础数据库中。我会分发这个基础数据库,但我不会分发未使用模块的数据。每个模块在安装时都会分发它自己的数据(可能由其安装程序而不是内置到模块本身中)。
表前缀并不重要,共享数据库的好处是您可以从任何模块访问每个表并拥有共享的配置文件等...
如果您需要跨表查询,我建议将它们放入一个数据库中,否则不会有任何区别。但是,拥有一个数据库会更容易维护。
除非您需要多个数据库,否则我建议您只使用一个。