Question

我正在设计一些共享2或3个数据库表的应用程序，所有其他表将独立于每个应用程序。共享数据库主要包含用户信息，可能会出现需要共享其他表的情况，但这是我的本能。

我倾向于所有应用程序解决方案的一个数据库，因为我希望具有参照完整性，并且我不必在每个数据库中保持最新的相同信息，但我可能会以100多个表的数据库结束，其中只有10个表的组将具有相关信息。

每种应用程序方法的数据库可以帮助我保持一切更有条理，但我不知道如何使所有数据库中的相关表保持最新。

所以，基本问题是：你推荐哪两种方法？

谢谢，

Jorge Vargas。

编辑1：

当我谈到不能具有参照完整性时，这是因为当这些表位于不同的数据库中时，没有办法在表中使用外键，并且每个应用程序中至少有一个表需要一个外键到一个共享表。

编辑2：

相关问题的链接：

只有第二个人有一个接受的答案。还没有决定做什么。

答案：

我决定使用每个应用程序的数据库，对共享数据库进行跨数据库引用，为每个数据库添加视图，模仿共享数据库中的表，并使用NHibernate作为我的ORM。作为会员系统，我将使用asp.net。

我还会使用触发器和逻辑删除来尝试将没有父母的livin'la vida loca周围的ID数量保持在最低限度。保持数据库同步所需的开发工作太多而且收益太少（正如你们所指出的那样）。所以，我宁愿通过孤立的记录来打击我的方式。

由于使用ORM和视图最初由svinto建议，他得到了正确的答案。

感谢所有人帮助我做出这个艰难的决定。

Answer 1

这两种方式看起来都不理想

我认为您应该考虑不在数据库层中为跨应用程序关系进行引用，并在应用程序层中进行引用。这将允许您将每个应用程序拆分为一个数据库。

我正在开发一个包含100多个表格的应用程序。我将它们放在一个数据库中，并用前缀分隔 - 每个表都有它所属模块的前缀。然后我在数据库函数之上构建了一个层来使用这个自定义组。我也在构建数据管理员，它利用了这个表组，使编辑数据非常容易。

Answer 2

取决于您使用的数据库和框架，它取决于您的选项会有所不同。我建议使用某种ORM，这样你就不必费心了。无论如何，您可以将每个应用程序放在数据库中自己的架构中，然后通过schemaname.tablename引用共享表，或者在每个仅为SELECT * FROM schemaname.tablename的应用程序架构中创建视图，然后针对该视图进行编码。

Answer 3

没有严格的规则来选择其中一个。

多个数据库提供模块化。就跨多个数据库的同步而言，可以使用链接服务器及其视图的概念，并且也可以获得集成数据库（统一访问）的优势。

此外，保留多个数据库有助于更好地管理安全性，数据，备份和安全性。恢复，复制，扩展等！

我的2点。

Answer 4

这听起来根本不像“很多应用程序”，而是像“具有不同可执行文件的一个应用程序系统”。当然，他们可以共享一个数据库。巧妙地使用Schemata来隔离一个数据库中的不同功能区域。

Answer 5

在我看来，所有应用程序都有一个数据库。数据将在没有复制的情况下存储。

使用另一种方法，你最终会复制，在我看来，当你开始复制它会带来自己的头痛，数据也会不同步

Answer 6

从可伸缩性和维护性角度来看，最合适的方法是使“共享/公共”表子集自给自足并将其放入“公共”数据库，因为所有其他表每个逻辑范围每个应用程序有1个db （业务逻辑确定）并始终保持此结构

这将简化您的软件的规划和执行调试/退役/重新安置/维护程序（如果您知道要触摸哪个应用程序，您将确切知道涉及哪两个受影响的数据库（commons + app_specific），反之亦然

Answer 7

在我们的业务中，我们为每个应用程序提供了一个单独的数据库，其中包含针对少量共享信息的交叉数据库引用以及偶尔的链接服务器。这在开发，登台，构建和生产环境中非常有效。

对于用户，我们的整个用户群都在Windows上。我们使用Active Directory通过对组的应用程序引用来管理用户，这样应用程序就不必管理用户，这很好。我们没有集中管理组，即每个应用程序都有用于组和安全性的表，这些表不是那么好但是有效。

我建议，如果您的应用程序确实不同，那么每个应用程序都有一个数据库。回顾过去，用户的中央共享数据库听起来也可行。

您可以使用触发器来实现跨数据库参照完整性：

为包含要引用的数据库的服务器创建链接服务器。然后使用4部分命名来引用包含引用数据的远程数据库中的表。然后将其放在表格中的插入和更新触发器中。

示例（假设单行插入和更新）：

DECLARE @ref (datatype appropriate to your field)

SELECT @ref = refField FROM inserted

IF NOT EXISTS (SELECT *
FROM referenceserver.refDB.dbo.refTable
WHERE refField = @ref)
BEGIN
RAISERROR(...)
ROLLBACK TRAN
END

要进行多行插入和更新，您可以在参考字段上加入表格，但速度非常慢。

Answer 8

我认为这个问题的答案完全取决于您的非功能性要求。如果您正在设计一个需要在100个节点上部署的应用程序，那么您需要设计数据库，以便在需要时可以进行水平扩展。另一方面，如果这个应用程序是由一个充满用户的手使用，并且可能有一个短的保质期，那么你的方法将是不同的。我最近收听了关于如何设置EBAY架构的播客http://www.se-radio.net/podcast/2008-09/episode-109-ebay039s-architecture-principles-randy-shoup，他们每个应用程序流都有一个数据库，他们使用分片来跨物理节点分割表。现在他们的非功能性要求是系统全天候可用，速度快，可以支持数千个用户，并且不会丢失任何重要数据。 EBAY赚了数百万英镑，因此可以支持开发和维护所需的工作量。

无论如何这不能回答你的问题:)我的人员意见是确保你的非功能性要求已被记录并由某人签字。这样你就可以决定最好的架构。我很想让每个应用程序使用自己的数据库和共享数据的中央数据库。我会尽量减少它们之间的依赖关系，我肯定这并不容易，或者你会做到这一点:)，但我也会尝试避免必须生成某种中间件软件以保持表格同步，因为这可能会给你带来麻烦。

在一天结束时，你需要让你的系统运行起来，而那些尖头发的家伙不会给你一个关于你的设计有多酷的猴子。

Answer 9

我们开始拆分数据库，并为所有共享表创建一个公共数据库。由于它们都在保存SQL Server实例上，因此不会影响跨多个数据库运行查询的成本。

我们复制的关键是整个服务器都在虚拟机（VM）上，因此对于创建开发/测试环境的复制，IT支持人员只需创建该映像的副本并在需要时还原其他副本。 / p>

每个应用程序的数据库VS所有应用程序的大数据库

9 个答案: