我正在设计一个贷款发起系统，它允许它的用户创建贷款，根据贷款产品参数绘制贷款的还款计划。我还应该能够增加罚款、费用等。重新安排贷款应该是可能的。我还需要一个贷款时间表来进行快速报告。
我有一个贷款表、贷款产品表、付款时间表表和贷款历史表等。我无法理解如何提前设计这个模式以防止它发生太大变化。
我在 ruby、rails3 和 datamapper 中这样做。
问问题
1543 次
1 回答
7
除了在最严格指定的应用程序中，我不确定您是否可以设计一个不会有太大变化的模式。您可以做的是制作不脆弱的架构，允许更改发生的架构。在大多数情况下，这意味着。
- 仅包含您知道满足当今要求所需的数据
- 标准化。
- 编写自动化测试。
第一条规则类似于“尽可能做最简单的事情”或“你不需要它”，程序员用来避免代码膨胀的规则。较小的模式，如较小的代码库，需要较少的更改工作。第二个（规范化）类似于 Don't Repeat Yourself (DRY) 原则，也称为“一次且仅一次”，这是另一条用于降低代码更改成本的规则。第三条规则（测试）是程序员如何在不担心破坏一切的情况下使重构成为可能。通过测试，我的意思是测试使用模式的代码，同时也测试模式本身：触发器、规则、级联删除等。可以测试，并且在测试时，更容易更改它们以响应不断变化的需求。
在数据库世界中，违反这些规则是有借口的。打破规则 1（做最简单的事情/YAGNI）的原因是，一些数据从一开始就更容易收集，如果您以后决定确实需要它，则很难甚至可能无法收集。不过，在屈服于这个借口之前，请三思而后行。您几乎总是可以不用大惊小怪地处理由于稍后添加列或表而导致的数据间隙，但是如果您包含今天可能只需要明天的数据，那么您每次更改架构时都会为此付出代价。您最终不需要的每一点数据都只是成本，没有任何好处。也许更重要的是，额外的数据会对性能产生可怕的影响，因为它会减少内存中可以容纳的记录数量。
违反规则 2（规范化）的借口是性能：“数据仓库”应用程序有时需要非规范化，以防多表连接使数据库变得缓慢和胡思乱想。我想确定在非规范化之前需要它，因为它不是免费的：存在不止一次的数据使模式更难以更改，并且在插入和更新时牺牲查询速度以获得更多工作。
我不知道违反规则 3（测试）的借口，或者至少不是一个好的借口，但这并不意味着没有。
Martin Fowler 撰写了“进化数据库设计”。Scott Amber 和 Pramod Sadalage 有一本关于重构数据库的书。另请参阅本书重构的摘要/备忘单。
于 2011-01-22T05:42:47.373 回答