我对您加入来自不同数据库的两个或多个表的陷阱感兴趣。我试着举个例子。
假设表Table1位于DatabaseA数据库中，Table2位于DatabaseB。
假设我有一个视图，在DatabaseA中提取了Table1中的一些数据，以及DatabaseA'中的其他一些数据。
此视图用于将数据推送到另一个数据库，让我们称之为“{1}}。{/ p>
如果我需要DatabaseC中的某些数据，我的直觉是在此视图中直接加入Table2，有点像Table2
这样做非常简单快捷，但我脑子里有一种唠叨的声音，一直告诉我不要这样做。我担心的是无法根据table1 inner join DatabaseB..table2 on [some columns]追踪所有对象，所以如果我在那里改变了一些东西，我必须非常小心并记住我使用这个表的所有地方。所以，有点像打破此视图（和两个数据库）的SRP，因为此视图可以从两个不同的操作（在两个不同的数据库上执行：更改Table2或更改Table1）
我对你的意见感兴趣。这是一个好主意还是坏主意？这种方法会出现什么问题（性能明智，维护明智等等），如果你有真实的世界经验，这种方法要么是一个大错误，要么是为你节省生命。
P.S：我在google和SO上搜索了这个主题，但找不到与此相关的任何内容。我很乐意接受来自SO用户的减号，重复问题和其他“谴责”，只是对这个问题有不同看法。P.P.S：我正在使用SQL Server 2005。
谢谢你，希望我明确表示：）
答案 0 :(得分：27)
如果它们位于同一台服务器上，那么从单独的数据库中提取就没有问题。事实上，你可能想要将它们分开是有充分理由的。例如，如果您具有从文件导入的事务表和查找表的组合。事务性数据需要完全恢复，并且频繁的事务日志备份才能正常恢复，查找数据不会因简单恢复模式下的数据库而受益。
我们的应用程序使用了许多不同的数据库，并且我们一直在查询中交叉数据库。只要索引正确完成，就没有明显的性能差异。最大的潜在问题是数据完整性，因为您无法跨数据库设置外键。如果需要，可以在触发器中处理。
现在，当数据库位于不同的服务器上时，可能会出现性能问题并且数据更复杂。
答案 1 :(得分：11)
与SQL中的其他内容一样，它取决于。
在我的工作中，我们做了很多。我们有非常大的数据集，用于标题和详细级别记录的单独数据库，然后是我们根据其他数据构建的报表或表格的其他数据库等。
加入数据库并没有真正的性能问题，在某些情况下，根据您的硬件设置，它可能会更快。如果DatabaseA和DatabaseB位于具有不同控制器的单独物理驱动器上，则运行加入这些控制器的查询可能会比同一卷上的同一数据库更快。
维护可能是一个问题，但不会超过任何其他数据库/表。它不像你有相同表的不同版本，你只需要在不同的数据库中使用这些表。
唯一的主要缺点是SQL Server在显示数据库内部依赖关系方面表现不佳，因此您需要自己跟踪这些依赖关系。有一些脚本用于此以及第三方实用程序，我听说SQL Server Denali将为此添加额外支持，但我不确定这是否准确。
答案 2 :(得分：5)
你的唠叨声音可能是正确的。
由于无法在数据库之间创建外键，因此问题将是如何强制执行声明性引用完整性，因此迟早您将不得不应对不一致或不匹配或不完整的数据。
但如果你不关心这个，我没有看到问题： - ）
答案 3 :(得分：2)
你的问题的答案是......这取决于。
我注意到，当您保持查询简洁（加入更少等）时，性能不会严重下降。
查询越复杂，优化程序产生次优执行计划的可能性就越大。
优化器最终决定如何执行查询。查询越复杂，优化器就越有机会获得操作顺序＆＃34;错误＆＃34;。
我最近试验过这个问题......
我在一个数据库上运行了大约8个连接的查询。然后，我在同一台服务器上以不同的名称放置了该数据库的副本，然后我修改了查询，以便它将连接到数据库的第二个副本中的几个表。
作为单个数据库查询，它在3秒内运行;预计给定的数据量。
跨数据库加入查询在不到3分钟的时间内运行。
enter code here
答案 4 :(得分：2)
一些通用主题是跨数据库连接：
外键
正如其他人所指出的那样，在没有外键的情况下，你需要推出自己的参照完整性。本身不是问题，但是当您无法控制一个或多个数据库中的数据时，问题就会出现。
相关问题是使用CASE工具。对模式进行逆向工程时，它们会忽略不存在FK-> PK关系的表之间的链接。
<强>性能
如果数据库位于不同的服务器上，那么您将暴露于这些服务器上运行的任何其他内容的变幻莫测以及运行连接操作本身的成本。同样，如果服务器都在您的控制之内，那么您可以监控这些情况，但情况可能并非如此。
<强>联轴器
如果您的解决方案依赖于其他数据库，则会出现多个故障点。如果数据库出现故障，则可以级联到一个或多个系统。
数据修改
您的解决方案可能与您认为是另一个数据库中的表中的静态数据相关联。但是，如果意外地（或有目的地）修改，复制或删除了该怎么办。同样，如果有问题的数据库不在您的职权范围内，其他团队/部门可能也不了解您的系统如何运作。
所有这些，确实，在许多情况下，跨数据库连接是常态。我见过的一些例子：
<强> MART-存储库
当主数据存储保存在存储库中时，在市场上执行高性能操作。 CRUD操作在两者之间频繁或不经常进行（每晚更新，实时等）。
传统数据库
您可能会公开旧数据库以进行数据迁移和/或报告/审核。
<强>查找
您的一个或多个数据库可能包含可以重复使用的静态查找信息。
所以回答你的问题 - 这取决于你究竟在做什么以及风险是否可以接受。存在其他解决方案，例如复制，但同样可行，这取决于您所在部门/公司的结构。