Ang*_*ge1 4 database-design sql-server database-recommendation
我正在使用的 Web 应用程序有一个巨大的数据库，它真的一团糟，没有外键，没有约束，没有索引，没有优化，没有规范化，什么都没有。到目前为止，逻辑一直是：如果您需要一个字段，则添加它，如果您需要一个表，则尽可能快地创建它。一开始，我无法理解这些错误的严重性，但不得不一直处理由坏数据库造成的障碍，这让我决定重新设计整个数据库。我需要知道的是：
一般来说，当你想修复一个大泥球时架构时，最好专注于一个小方面，你可以相对快速地修复并获得最大的回报。那东西是什么会因系统而异。一旦你确定了那件事，然后实施它并寻找机会解决其他问题。随着时间的推移，你的大泥球会越来越受到控制。这是假设团队的其他成员都参与解决您陷入的困境。如果他们不致力于摆脱现状，那么您将打一场无法获胜的战斗。
添加一些索引似乎是一个快速而轻松的胜利，所以这可能是一个很好的起点，但是YMMV .
在离别时，请记住Warren P在评论中提到的内容：
几年来造成的混乱很少少于几年才能清理干净。
如果有任何成功的希望，您和团队的其他成员需要长期致力于这项清理工作。
从数据库规范化开始不是更好吗？我的意思是在开发环境中，为了最终得到一个完全结构化的数据库？有 6 个表必须分开，以便为将来的请求更具“弹性”。
规范化可能会涉及整个系统的许多查询/语句。这是一个非常侵入性的变化，需要花费大量的时间和精力才能显示出好处。采取小的渐进步骤会更容易、更快、更稳定地改善你的生活。在考虑规范化之前，我会将所有数据访问转移到存储过程中。这将快速为您带来实实在在的好处，让您可以分散工作，并使规范化步骤更容易。
[T]整个团队都准备好了，我们正在谈论一个6-9个月的重组项目，但大老板们还没有决定。
在提倡停止一切并追求重新设计之前，请阅读 Joel Spolsky 的这篇文章。在接下来的 6 到 9 个月内重组旧系统时阻止对现有系统的更新会使业务难以成功。支持当前产品的同时改进相同的代码库是 IMO 最聪明的玩法（在我看来）。通过这种方式，代码库改进将只是支持当前产品的共生扩展。
注意：我不是建议您让一个团队进行重写（2.0 版），而另一个团队支持当前系统（1.x 版）。