多个数据库，更少的表？一个数据库，很多表？

Question

我最近找到了一份IT工作，虽然我的专长是应用程序设计，但我的任务是修复和更新他们当前的数据库结构和应用程序。

他们当前的数据库包含20个互连的数据库，有数百个不同的视图（没有存储过程）。一切都与一系列访问前端联系在一起。

现在服务器架构非常奇怪，数据库中有大量重复的表包含相同或几乎相同的数据，因此显然可以合并其中的大部分。但是，前一个开发人员布置应用程序的方式是为每个应用程序创建一个单独的数据库，另一个数据库名为＆＃34; Shared_Tables＆＃34;包含需要在表之间传递的信息的 SOME 。

现在我的主要问题是，由于我基本上从头开始为公司创建新的系统结构，使用分离的数据库是否有任何真正的优势，或者将它们全部合并到1个数据库中就像高效，假设他们在同一个实例上运行全部？

另外，值得注意的是，没有一个数据库具有主键，唯一键，外键等。许多字段的数据类型应该相同。

Answer 1

我同意@ dean的帖子。建议开始直接破解数据库结构的帖子也是一个坏主意。如果数据库很多并且你提到了大量的表，那么你将会遇到比解决它们更多的问题（性能和回归错误是一个很大的问题）。

我建议如下：

1. 对公司数据库的当前状态进行分析（看起来您已经这样做了）。确切地指出问题的确切位置，并以他们理解的术语将其传达给您的经理。也就是说，这些是问题列表，需要很多年才能修复当前系统等。
2. 确定当前和未来的要求。这家公司在哪里使用他们的IT系统，在每种情况下他们的数据要求是什么。然后确定当前结构是否可以处理/支持其当前/未来的要求。如果没有，再次提出支持证据，说明为什么不能这样做。再次以他们能理解的行话向经理传达。

上述（1）和（2）的重点是什么？关键在于，在IT系统的历史背景下没有任何背景，并且开始充满信心地开始攻击，特别是如你所提到的那样合并表格，因此很难进入项目。您需要说服您的经理最好的选择是重新开始，为此您需要具体的证据来支持您的建议（我假设您宁愿从头开始设计而不是破解当前的数据库结构）。

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

Answer 2

我担心你会从错误的一端接近问题。

如果您有从头开始重新设计的奢侈品，请从逻辑数据设计开始。将数据库视为正确性的单位（所有约束都包含数据库，所有约束都应该为真）。为您的实体和它们之间的关系加以说明。识别钥匙。重复和正常化。只有在那之后你才应该关注自己的表现和效率。并不是说你最终没有改变一些漂亮的设计以获得更好的性能，只是应该总是从可靠的数据模型开始。

答案是＆＃34;有多少数据库＆＃34;问题将自然而然地从那里开始。