14

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

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

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

因此，基本问题是：您推荐两种方法中的哪一种？

谢谢，

豪尔赫·巴尔加斯。

编辑1：

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

编辑2：

相关问题的链接：

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

回答：

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

我还将使用触发器和逻辑删除来尝试将我在没有父母的情况下飞来飞去的 ID 数量保持在最低限度。保持数据库同步所需的开发工作太多而回报太少（正如你们都指出的那样）。所以，我宁愿在孤儿唱片中奋力拼搏。

由于 svinto 首次建议使用 ORM 和视图，因此他得到了正确答案。

感谢大家帮助我做出这个艰难的决定。

4

9 回答 9

6

两种方式看起来都不理想

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

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

于 2010-05-10T16:44:59.360 回答
4

这取决于您的选择，具体取决于您使用的数据库和框架。我建议使用某种 ORM，这样你就不需要那么麻烦了。无论如何，您可以将每个应用程序放在数据库中它自己的架构中，然后通过 schemaname.tablename 引用共享表，或者在每个应用程序架构中创建视图，SELECT * FROM schemaname.tablename然后针对该视图编写代码。

于 2010-05-10T16:41:15.343 回答
2

选择一个而不是另一个没有硬性规则。

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

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

我的 2 美分。

于 2010-05-10T16:51:39.080 回答
2

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

于 2010-05-10T17:50:17.240 回答
1

At our business, we went with a separate database per application, with cross database references for the small amount of shared information and an occasional linked server. This has worked pretty well with a development, staging, build and production environments.

For users, our entire user base is on windows. We use Active Directory to manage the users with application references to groups, so that the apps don't have to manage users, which is nice. We did not centralize the group management, that is each application has tables for groups and security which is not so nice but works.

I would recommend, that if your applications are really different, to have a database per application. Looking back, the central shared database for users sounds workable as well.

You can use triggers for cross database referential integrity:

Create a linked server to the server that holds the database that you want to reference. Then use 4-part naming to reference the table in the remote database that holds the reference data. Then put this in the insert and update triggers on the table.

EXAMPLE(assumes single row inserts and updates):

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

To do multi row inserts and updates you can join the tables on the reference field but it can be very slow.

于 2010-05-10T23:32:30.123 回答
1

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

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

于 2010-05-10T16:52:54.290 回答
1

在我看来，所有应用程序的一个数据库。一旦没有重复，数据将被存储。

使用另一种方法，您最终会进行复制，并且在我看来，当您开始复制时，它会带来自己的麻烦，并且数据也会不同步

于 2010-05-10T16:44:03.810 回答
1

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

无论如何，这并不能回答您的问题：) 我的人事意见是确保您的非功能性需求已记录并由某人签署。这样你就可以决定最好的架构。我很想让每个应用程序都使用自己的数据库和用于共享数据的中央数据库。我会尽量减少它们之间的依赖关系，我敢肯定这并不容易，否则你会做到的:)，但我也会尽量避免必须生产某种中间件软件来保存表格同步，因为这可能会让您头疼。

归根结底，您需要启动并运行您的系统，而那些留着尖头发的家伙不会因为您的设计有多酷而对猴子嗤之以鼻。

于 2010-05-12T07:34:02.573 回答
1

我们尝试将数据库拆分，并为所有共享表提供一个通用数据库。由于它们都在保存 SQL Server 实例上，因此不会影响跨多个数据库运行查询的成本。

对我们来说，复制的关键是整个服务器都在虚拟机 (VM) 上，因此为了创建开发/测试环境的复制，IT 支持人员只需创建该映像的副本并在需要时恢复其他副本。

于 2010-05-12T07:44:39.587 回答