我正在设计一个贷款发放系统，它允许用户创建贷款，根据贷款产品参数绘制贷款的还款计划。我也应该能够增加罚款，费用等，重新安排贷款应该是可能的。我还需要一个贷款时间表来做快速报告。
我有一个贷款表，贷款产品表，付款计划表和贷款历史表等。我无法理解我如何能提前设计这个模式，以防止它改变太多。
我用ruby、rails3和datamapper来实现这一点。
最佳答案
除了在最严格指定的应用程序中，我不确定您是否可以设计一个不会有太大变化的模式。您可以做的是使模式不脆弱，允许更改发生的模式。在很大程度上，这意味着。
只包括你知道你需要满足今天要求的数据
归一化。
编写自动化测试。
第一条规则类似于“做最简单的事情”，或者“你不需要它”，程序员用来避免代码膨胀的规则。较小的模式，如较小的代码基，需要较少的更改工作。第二个（normalize）是对“不重复自己（dry）”原则的分析，也称为“一次且仅一次”，另一个用于降低代码更改成本的规则。第三条规则（测试）是程序员如何使重构成为可能而不必担心破坏一切。通过测试，我的意思是测试使用模式的代码，同时也测试模式本身：触发器、规则、级联删除和c。可以测试，并且在测试时，更容易根据更改的需求更改它们。
在数据库世界里，违反这些规则是有借口的。打破规则1（做最简单的事情/yagni）的原因是，一些数据从一开始就更容易收集，如果您决定以后确实需要，则很难甚至不可能收集。不过，在屈服于这个借口之前要三思。对于以后添加列或表所导致的数据间隙，您几乎总是可以不必太操心，但如果包含今天的数据，那么您可能只需要明天的数据，那么每次更改架构时，您都将为此付出代价。你所包含的每一个你最终不需要的数据都只是成本而没有收益。也许更重要的是，额外的数据会对性能产生可怕的影响，因为它会减少内存中可容纳的记录数。尽管数据库在从磁盘读取数据时需要付出很大的努力才能提供良好的性能，但它们的最佳性能来自于有足够的内存（或足够少的数据），以便所有或大部分工作集都能装入RAM。
打破规则2（规范化）的理由是性能：“数据仓库”应用程序有时需要非规范化，因为许多表连接会使数据库变得缓慢和古怪。我想在去规范化之前确定它是必需的，因为它不是免费的：存在于不止一个地方的数据会使模式更难更改，并且在插入和更新时会牺牲查询的速度以获得更多的工作。
我不知道违反规则3（测试）的理由，或者至少是不好的理由，但这并不意味着没有。
马丁·福勒写的是"Evolutionary Database Design"。scott amber和pramod sadalage有一本关于Refactoring Databases的书。另请参见a summary/cheat sheet of the book's refactorings。
关于ruby - 贷款发起系统的良好模式设计是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4680670/