对于贷款发放系统，什么是好的模式设计？

Question

我正在设计一个贷款发放系统，允许它的用户创建贷款，根据贷款产品参数绘制贷款还款计划。我也应该能够添加罚款，费用等。重新安排贷款应该是可能的。我还需要一个贷款时间表来做快速报告。

我有一个贷款表，贷款产品表，付款日程表和贷款历史表等。我不能理解我如何提前设计这个模式，以防止它改变太多。

我正在用ruby，rails3和datamapper做这件事。

Answer 1

除非是在最严格指定的应用程序中，否则我不确定您是否可以设计一个不会有太大变化的模式。您可以做的是使模式不是脆弱的，允许发生更改的模式。在大多数情况下，这意味着。

仅包含您知道满足当前requirements

• Normalize.

• Write自动化测试所需的数据。

第一条规则类似于“尽可能做最简单的事情”，或者“你不需要它”，这是程序员用来避免代码膨胀的规则。较小的模式，如较小的代码库，需要更改的工作较少。第二个规则(标准化)类似于不要重复自己(DRY)原则，也被称为“一次且只有一次”，这是另一个用于降低代码更改成本的规则。第三条规则(测试)是程序员如何在不担心破坏一切的情况下使重构成为可能。通过测试，我指的是测试使用模式的代码，但也测试模式本身:触发器、规则、级联删除等。可以测试，并且在测试时，更容易更改它们以响应不断变化的需求。

在数据库世界中，有违反这些规则的借口。打破规则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。