多个数据库，少量表格？一个数据库，多个表格？

Question

多个数据库，少量表格？一个数据库，多个表格？

3

我最近在IT领域找到了一份工作，虽然我的专业是应用设计，但我被指派负责修复和改进他们当前的数据库结构和应用程序。他们目前的数据库包含20个相互连接的数据库，有数百个不同的视图（没有存储过程），所有内容都与一系列访问前端相关联。现在服务器架构非常奇怪，在跨数据库中存在大量重复的表，这些表包含相同或几乎相同的数据，因此很多内容可以合并。然而，以前的开发人员布置应用程序的方式是为每个单独的应用程序使用一个单独的数据库，并创建另一个名为“Shared_Tables”的数据库，其中包含需要在表格之间传递的部分信息。现在我的主要问题是，既然我基本上是从头开始为公司创建新的系统结构，那么使用分离的数据库是否有任何真正的优势，或者将它们全部合并到一个数据库中是否同样有效，假设它们都在同一实例上运行？另外值得注意的是，没有任何数据库具有主键、唯一键、外键等。许多字段之间的数据类型不同，即使应该相同也是如此。

- JD Davis

1

首先，解决没有主键或外键的问题 - 一旦这些问题得到解决并且运作正常 - 然后再考虑其他事情...那个设计这样数据库的人应该被禁止再次触碰键盘... - marc_s

数据库中包含近5年的数据，有些情况下我尝试过开始破解主键和外键，但这导致了其他问题的出现。当我说这个数据库是一场噩梦时，这只是一个巨大的低估。而修复PK/FK问题是另一个主要问题，因为许多PK/FK跨越多个数据库... - JD Davis

1

一旦系统比较稳定并且具有适当的PK+FK，我会尝试看看通过合并这些数据库可以消除多少表。通常情况下，我倾向于认为较少的数据库更好 - 不要将表分成太多个数据库。例如，你不能在数据库边界上进行声明性参照完整性。如果你有太多的表 - 尝试使用SQL Server的模式功能 - 这对基于“功能区域”的权限处理非常有用。 - marc_s

1

顺便说一句 - 我为你感到难过 - 我也曾经历过这种情况，尝试并做了很多努力 - 最终放弃了 :-( （在我的情况下，是由一些彻头彻尾的白痴“设计”了10多年...其中有几个人，而他们也有不同风格的搞砸....） - marc_s

@marc_s - 一旦主键和外键就位，我们可以简单地执行“表差异”操作，并将差异存储在审计表中，然后合并两个表的数据吗？ - Erran Morad

这是很棒的一部分，每个数据库都有其自己的定制模式，因此组织部分实际上已经完成了，但是绝对没有参照完整性，并且权限随意分布。此外，公司不使用域用户，而是本地管理的工作站。 - JD Davis

2个回答

0

恐怕您是从错误的角度来解决问题。

如果您有重新设计的奢侈，那么请从逻辑数据设计开始。将数据库视为正确性的单元（所有约束都包含在数据库中，所有约束都应该是真实的）。确定实体及其之间的关系。确定键。去重和规范化。只有在完成这些后，您才应该关注性能和效率。并不是说您不会最终为了更好的性能而改变一些美丽的设计，只是说您始终应该从坚实的数据模型开始。

"有多少个数据库"的答案将自然而然地从这里得出。

- dean

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user3248346 · Accepted Answer

我同意@dean的观点。同时，建议直接开始入侵数据库结构的帖子是一个坏主意。如果数据库很多，并且表的数量如你所述，那么你会引起更多的问题，而不是解决它们（性能和回归错误是其中之一）。

我建议以下措施：

1.对公司数据库的当前状态进行分析（看起来你已经做到了这一点）。准确地确定问题所在，并用管理人员可以理解的术语传达。也就是说，这些是问题列表，需要花费这么多人年来修复当前系统等等。 2.确定当前和未来的要求。该公司的IT系统将走向何方，每种情况下都有哪些数据需求。然后确定当前结构是否可以处理/支持其当前/未来的要求。如果不能，请再次确定为什么不能，并提供支持证据。再次用管理人员可以理解的术语传达。

以上的目的是什么？目的是，如果没有了解IT系统的历史背景，就像你所做的那样加入项目并充满信心地开始入侵是非常困难的，特别是像你提到的合并表格之类的操作。您需要说服您的管理人员，最好的选择是从头开始设计，而这需要具体的证据来支持您的建议（我假设您宁愿从头设计而不是入侵当前的数据库结构）。

最好从一张空白的纸开始，根据当前和未来的要求设计适合您的系统。您仍然需要分析现有结构，但只需为新数据库设计采用所需内容。祝你好运，希望对你有所帮助！