在可怕的数据库上编写好的代码是否有希望？

这是我的困境。我最近继承的几个程序之一是在后端使用可怕的数据库构建的。尊敬的创作者显然不喜欢关系概念。每个客户的表，称为唯一客户ID。八十三个隐式命名的字段。该代码都是带有数十个串联的内联SQL语句的程序性代码。

由于没有为我们提供可在同一数据库上运行的重要辅助应用程序，因此我不得不从头开始重新创建它。我是唯一的开发人员，这甚至都不是我的主要职责，因为我至少有一半的时间被操作员占用。从现在开始，不可避免的期限是30天。

尽管我没有经验，但是我敢肯定我可以设计出比以前更好的数据库和现有应用程序，但是我真的认为改变数据库，调整现有应用程序并确保我没有这样做是不现实的。在需要快速创建附加应用程序的同时不要破坏任何内容。

因此，假设我陷入了可怕的数据库。需要使用这样一个糟糕的结构，我写的任何符合它的东西，是否只会增加堆积如山的技术债务，直到一些事情完全崩溃或需要新功能时才被搁置？除了可以运行的应用程序之外，我该如何处理这种情况并从中获得好处？

编辑：如果有人感兴趣，我们最终将这个可怕的数据库及其上运行的应用程序报废了。我们将辅助应用程序的创建（我没有参与设置）外包给了最终两个不同的承包商，他们最终都落在了我们头上，却一无所获。我最终不得不在三天之内赶出一个恐怖的，具有部分功能的修补程序，而该修补程序至今仍在使用。

有希望，但这是一场艰苦的战斗，尤其是如果没有人意识到数据库设计是可怕的。您可以尝试通过抽象层将复杂性抽象化，但是可能不值得一战。

我的建议是在数据库上创建足够的抽象，以使应用程序本身是干净的且经过适当设计。这样，即使您可以修复数据库，该应用程序也不会受到影响，因为它不在乎数据库的设计方式。

这是我在处理现有数据库时通常使用的方法，并且经常以零思想进行设计。存储库或网关模式的一些选择应用程序，以及与网关/存储库进行通信的某些服务层，应有助于隔离不良的设计。

构建一个处理所有数据库内容的接口层，然后编写您的应用程序以与之交互。如果数据库曾经被“修复”，则只需替换/更新“接口”即可。这种方法为我处理了一个错误的数据库或正在为其他应用程序提供服务且无法处理的数据库时，为我节省了大量时间。

哎呀……您继承了一场噩梦，您有30天的时间可供组织使用，而您有一半的时间都花在了运营任务上？

我相信您可以重构，但肯定不能在那段时间内完成。

要回答您的问题，我认为您实际上无法在这种设计上编写好的代码。技术债务已经太多了。如果我是您，那么我将尽我所能，并在以后有更多时间和团队中的人员更好地解决这个问题时，要求进行完整的重构。

请小心推动重构。有时，高层人士会决定购买产品的源代码和所有权，而他们又不想认为自己完全浪费了钱。对我来说，在一份工作中就是这种情况。不幸的是，管理人员在购买此类软件时会做出决定，他们从未获得技术参与来评估他们所购买的产品并查看其是否可维护并承担大量技术债务。在这种情况下，错误的决定是一项政治决定，推动重构可能会危及您的工作。

可以像其他代码一样重构数据库。修复受编写和编写测试所需的代码影响的部分，以确保没有其他中断。像其他任何重构一样，一次执行一小部分。关于数据库重构的一本好书可能会帮助您开始清理混乱。 http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

也有其他的，但是我个人已经阅读并使用了其中的技术。

并且不要忘记，您可以通过创建视图来重组查询数据库的方式，从而为您完成讨厌的转换工作，使其成为易于查询的结构。

为了最大程度地发挥作用，请创建可更新的视图以还原某些“关系”并提供更有意义的列名。

一种可能是建立第二个数据库，该数据库的结构（至少与您的需求相近），并在两个数据库之间建立复制。然后，您可以针对新数据库编写代码，并且仍然保留现有数据库（和应用程序）完整，以便在您有更多时间处理时。

坦白地说，您是否可以在大约15天的时间内做到这一点仍然存在很多问题。特别是，它可能取决于您是否需要双向复制（即，您的新应用程序实际上将更新数据）还是仅一种方式（您的新应用程序仅允许人们查看数据）。后一种情况（当然）非常容易处理。

如果您需要双向复制，则很可能没有足够的时间来完成这项工作。特别是，涉及大量转换结构的双向复制从来都不是一件容易的事，并且可用的工具通常对它的支持非常差（例如，必须为两个方向上的所有数据转换手动编写所有SQL）。

如果您只需要单程，那么它可能会成为现实。这也将取决于是否你被允许花钱不少与否-也有相当多的数据仓库应用程序被用于正是这种任务的，可能会使它颇有几分更快，更容易来管理-但大多数都不便宜。