我正在设计一个贷款发放系统，允许其用户创建贷款，根据贷款产品参数绘制贷款的还款计划。我也应该能够增加罚款，费用等。重新安排贷款应该是可能的。我还需要一个贷款计划来快速报告。
我有贷款表，贷款产品表，付款计划表和贷款历史表等。我无法理解如何设计这个架构以防止它变化太多。
我在ruby，rails3和datamapper中这样做。
答案 0 :(得分：7)
除了在最严格指定的应用程序中，我不确定您是否可以设计一个不会发生太大变化的架构。您可以做的是制作不易碎的模式，允许更改发生的模式。在大多数情况下，这意味着。
第一条规则类似于“尽可能做最简单的事情”或“你不会需要它”，这是程序员用来避免代码膨胀的规则。较小的模式，如较小的代码库，需要更少的努力来改变。第二个（标准化）与“不重复自己”（DRY）原则类似，也称为“一次且仅一次”，另一个规则用于使代码更便宜地改变。第三条规则（测试）是程序员如何在不担心破坏一切的情况下进行重构。通过测试，我的意思是测试使用模式的代码，还测试模式本身：触发器，规则，级联删除和＆amp; c。可以进行测试，并且在测试时，更容易根据不断变化的要求进行更改。
在数据库世界中，有一些理由违反这些规则。打破规则1（做最简单的事情/ YAGNI）的原因是，一些数据从一开始就更容易收集，如果你决定以后需要它，那么很难或甚至不可能收集。在给出这个借口之前，请三思而后行。您几乎总是可以毫不费力地处理由于稍后添加列或表而导致的数据缺口，但如果您今天可能只需要包含明天的数据，则每次更改架构时都会为此付费。您最不需要的每一项数据都只是成本而没有任何好处。也许更重要的是，额外的数据会对性能产生可怕的影响，因为它减少了可以适应内存的记录数量。尽管数据库在从磁盘读取时经历了很大的努力以提供良好的性能，但它们的最佳性能来自于拥有足够的内存（或足够少的数据），因此所有或大部分工作集都适合RAM。
打破规则2（规范化）的借口是性能：“数据仓库”应用程序有时需要在多表连接使数据库变得缓慢且不稳定的情况下进行非规范化。我希望确定在非规范化之前需要它，因为它不是免费的：存在于多个地方的数据使得模式更难以改变，并且在插入和放置时更换查询的速度以获得更多工作。更新
我不知道打破规则3（测试）的借口，或者至少不是一个好的理由，但这并不意味着没有规则。
Martin Fowler写道"Evolutionary Database Design"。 Scott Amber和Pramod Sadalage有一本关于Refactoring Databases的书。另请参阅a summary/cheat sheet of the book's refactorings。