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

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

他们当前的数据库包含20个相互连接的数据库，有成百上千种不同的视图（没有存储过程）。所有东西都与一系列访问前端相连

现在，服务器体系结构非常奇怪，数据库中有大量重复的表，其中包含相同或几乎相同的数据，因此很明显，其中大部分可以合并。然而，以前的开发人员部署应用程序的方式是为每个应用程序都有一个单独的数据库，另一个数据库称为“共享_表”，其中包含需要在表之间传递的部分信息

现在我的主要问题是，既然我基本上是从零开始为公司创建一个新的系统结构，那么使用分离的数据库有什么真正的优势，或者假设它们都在同一个实例上运行，那么将它们合并到一个数据库中是否也同样有效

---

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

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

如果你想从头开始重新设计，那就从逻辑数据设计开始。将数据库视为正确性的一个单元（所有约束都包含在数据库中，并且所有约束都应该为真）。使你的实体和它们之间的关系变得更加科学化。识别钥匙。重复数据消除和标准化。只有在这之后，你才应该关注自己的表现和效率。并不是说你不会为了更好的性能而改变一些漂亮的设计，只是说你应该总是从坚实的数据模型开始

---

“有多少数据库”问题的答案自然会从这里开始。

我同意@dean的帖子。此外，那些建议立即开始破解数据库结构的帖子也是一个坏主意。如果数据库有那么多，并且有你提到的那么多的表，那么你将导致更多的问题，而不是解决它们（性能和回归错误是一个大问题）

我建议如下：

对公司数据库的当前状态进行分析（看起来您已经这样做了）。准确指出问题所在，并用他们理解的术语将其传达给经理。也就是说，这些都是问题清单，需要这么多年的时间来修复当前的系统等等

确定当前和未来的需求是什么。这家公司的IT系统将走向何方？在每种情况下，他们的数据需求是什么。然后确定当前结构是否能够处理/支持其当前/未来需求。如果没有，再次用支持证据指出为什么不能这样做。再次用他们能理解的行话向经理传达

上面（1）和（2）的要点是什么？关键是，要开始一个项目是极其困难的，因为您在该it系统的历史上没有任何背景，并且开始满怀信心地进行黑客攻击，尤其是您提到的表的合并。你需要说服你的经理，最好的办法是重新开始，为此你需要具体的证据来支持你的建议（我假设你宁愿从头开始设计，也不愿破坏当前的数据库结构）

---

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

首先修复无主键、外键的问题—一旦这些问题解决并开始工作—然后再考虑其他问题。。。。无论是谁“设计”了这样一个数据库，都应该被禁止再触摸键盘……数据库中包含了将近5年的数据，在某些情况下，我试图开始发出主键和外键的吱吱声，但这已经导致出现了一些其他问题。当我说这个数据库是一场噩梦时，这是一个大大的轻描淡写。修复PK/FK问题是另一个主要问题，因为许多PK/FK跨越多个数据库……一旦系统变得稳定并具有适当的PK+FK，我将尝试通过合并这些数据库来消除多少表。我倾向于认为，一般来说，数据库越少越好——不要将表拆分为太多的数据库。例如，不能跨数据库边界执行声明性引用完整性。如果你有太多的表-尝试使用SQL Server的模式功能-基于功能的“区域”处理权限也很好。顺便说一句-我对你有感觉-在那里，尝试过-最终放弃了：-（在我的情况下，这是一些十足的白痴10多年的“设计”…他们中的一些人也有不同风格的错误…）@marc_s-一旦pk、fk就位，我们可以简单地执行此操作吗-执行“表差异”并将差异存储在审计表中，并合并两个表的数据？