跨数据库是否可以接受?

是否有理由为每种类型的对象设置单独的数据库?你最好使用多个表,并将它们连接起来。例如,您可能有一张桌子 GENERIC_OBJECT 它包含所有类型中通用的东西,然后是一个名为 BOOK_OBJECT 哪里 BOOK_OBJECT.ID = GENERIC_OBJECT.ID 对于一本给定的书。另一张桌子是 CD_OBJECT 哪里 CD_OBJECT.ID = GENERIC_OBJECT.ID 对于给定的CD。然后,所有对象中通用的关键字等内容将存储在 通用对象 表,并且特定于该项的内容将放在该项的相应表中。

通过将它们分离到不同的数据库中,您将失去:

• 执行ACID事务的能力(假设您没有使用两阶段提交解决方案)。
• 具有指称完整性的能力。
• 在桌子上来回走动。

Thomas,在您对我们关于引用完整性的担忧的评论回复中,您缺少的是,您不能在两个数据库之间执行foriegn键。如果这两个表在一个数据库中,那么您可以使用foriegn键约束来确保在删除对象时,依赖于其对象id的任何内容也会被删除,以及其他类似的内容。

虽然可以跨数据库进行连接,但我通常不会 分裂 数据库之间的数据只是因为它们属于略有不同的类别。其他人也提到了无法在数据库之间使用引用完整性。

另一方面,如果每种类型的产品都有完全不同的前端应用程序,或者如果你希望每个数据库都变得非常大,这些可能是 考虑 将它们留在单独的数据库中。(尽管对于大多数现代数据库来说,扩展不是问题)。

跨数据库联接的语法示例:

SELECT *
FROM books b
INNER JOIN KeywordDB.dbo.Keywords k
ON b.keywordID = k.keywordID

在这个例子中,您正在从执行查询 地方的 包含books表的数据库,您正在连接到另一个数据库。(这是一个MS SQL语法示例)

不,这是个坏主意。通过将它们分离到不同的数据库中,您会大大削弱执行JOIN查询的能力。

它看起来确实有点过于独立,但如果有一些设计良好的视图,它可以工作,特别是如果视图只是查找。

为什么一开始就有这种分离?

正如每个人都提到的,总的来说,这不是一个好主意。 然而, 为了扮演魔鬼代言人,我见过其他开发人员这样做。我确信,如果绝对需要(不确定你是否在寻求解决方案,但)你可能想使用某种同步来保持数据同步,那么人们可能会想要实现这一点。在两个数据库中都有所有(或所需的)数据。

这也不是一个理想的解决方案,但如果你必须使用两种不同的数据库类型,这可能是更好的方法。

它至少可以解决每个人都在概述的问题,但请记住,它确实提出了一个新问题 一切都同步了吗?

祝你好运,
坦率的

如果决定是使用一个还是两个数据库是你的,我建议只使用一个数据库。从你的问题来看,这两个表中的数据似乎密切相关。规模和复杂性似乎不值得拆分为两个数据库。

你的DBMS是什么?如果是Oracle、DB2、SQL Server,甚至是MS Access,那么管理一个包含关键字数据和对象数据的逻辑相关表中的单个数据库应该不会有任何问题。