什么是贷款发放系统的良好架构设计？
我正在设计一个贷款发放系统，该系统允许用户创建贷款，根据贷款产品参数制定贷款还款计划。我还应该能够添加罚款、费用等。重新安排贷款应该是可能的。我还需要一份贷款时间表来进行快速报告。
我有一个贷款表、贷款产品表、付款计划表和贷款历史表等。我无法理解如何提前设计这个模式以防止它发生太大变化。
我正在 ruby、rails3 和 datamapper 中执行此操作。
I am designing a loan origination system which would allow it's users to create loans, draw repayment schedule of the loan depending on the loan product parameters. I should also be able to add penalty, fees etc. Rescheduling loan should be possibility. I also need a loan schedule to do fast reporting.
I have a loans table, loan product table, payment schedule table and loan history table etc. I am not able to understand how I can design ahead this schema to keep it from changing too much.
I am doing this in ruby, rails3 and datamapper.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除了在最严格指定的应用程序中之外，我不确定您是否可以设计一个不会发生太大变化的模式。您可以做的是创建不易损坏的模式，允许更改发生的模式。在大多数情况下，这意味着。
第一条规则类似于“尽可能做最简单的事情”或“你不会需要它”，这是程序员用来避免代码膨胀的规则。较小的模式（例如较小的代码库）需要较少的更改工作量。第二个（规范化）类似于不要重复自己（DRY）原则，也称为“一次且仅一次”，这是另一个用于降低代码更改成本的规则。第三条规则（测试）是程序员如何使重构成为可能，而不必担心破坏一切。通过测试，我的意思是测试使用该模式的代码，但也测试模式本身：触发器、规则、级联删除等。可以进行测试，并且在测试后，可以更轻松地更改它们以响应不断变化的需求。
在数据库世界中，违反这些规则是有借口的。违反规则 1（做最简单的事情/YAGNI）的原因是，有些数据从一开始就更容易收集，但如果您决定稍后确实需要它，则很难甚至不可能收集它们。不过，在屈服于这个借口之前，请三思而后行。您几乎总是可以轻松处理因稍后添加列或表而导致的数据间隙，但如果您包含今天的数据，您可能只需要明天，那么每次更改架构时您都将为此付出代价。您包含的每一位最终不需要的数据都只是成本，没有任何好处。也许更重要的是，额外的数据会对性能产生可怕的影响，因为它减少了内存中可以容纳的记录数量。尽管数据库在从磁盘读取时付出了巨大的努力才能提供良好的性能，但它们的最佳性能来自于拥有足够的内存（或足够少的数据），以便所有或大部分工作集都适合 RAM。
违反规则 2（规范化）的借口是性能：在多表连接导致数据库缓慢且不稳定的情况下，“数据仓库”应用程序有时需要非规范化。我想确定在非规范化之前需要它，因为它不是免费的：存在于多个位置的数据使模式更难以更改，并且在插入和插入时会牺牲查询速度以换取更多工作。更新。
我不知道有什么理由可以违反规则 3（测试），或者至少不是一个好的借口，但这并不意味着没有理由。
Martin Fowler 撰写了“进化数据库设计”。 Scott Amber 和 Pramod Sadalage 有一本关于重构数据库的书。另请参阅本书重构的摘要/备忘单。
Except in the most tightly specified applications, I'm not sure you can design a schema that won't change much. What you can do is to make schemas that are not brittle, schemas that allow for change to happen. For the most part, that means.
The first rule is akin to "do the simplest thing possible," or "you ain't gonna need it," the rule that programmers use to avoid code bloat. Smaller schemas, like smaller code bases, need less effort to change. The second (normalize) is analagous to the Don't Repeat Yourself (DRY) principle, also known as "once and only once," another rule used to make code cheaper to change. The third rule (tests) is how programmers make refactoring possible without worrying about breaking everything. By tests, I mean testing the code that uses the schema, but also testing the schema itself: triggers, rules, cascading deletes, &c. can be tested, and when tested, it is easier to change them in response to changing requirements.
There are excuses, in the database world, for breaking these rules. The reason to break rule 1 (do the simplest thing/YAGNI) is that some data will be easier to collect from the beginning, and difficult or perhaps even impossible to collect if you decide you do need it later. Still, think twice before giving in to this excuse. You can almost always deal without too much fuss with gaps in the data caused by adding columns or tables later, but if you include today data you might only need tomorrow, you will be paying for it every time you change the schema. Each bit of data you include that you end up not needing was nothing but cost with no benefit. Perhaps more significantly, extra data can have a terrible effect upon performance, since it reduces the number of records that can fit in memory. Even though databases go through great pains to give good performance when reading from disk, their best performance comes from having enough memory (or little enough data) so that all or most of the working set will fit in RAM.
The excuse for breaking rule 2 (normalization) is performance: "Data warehouse" applications sometimes require denormalization in cases where many-table joins make a database slow and cranky. I'd want to be certain it was needed before denormalizing, since it's not free: data that exists in more than once place makes the schema more difficult to change, and trades off speed of queries for more work when inserting & updating.
I don't know of an excuse for breaking rule 3 (testing), or at least not a good one, but that doesn't mean there isn't one.
Martin Fowler writes "Evolutionary Database Design". Scott Amber and Pramod Sadalage have a book on Refactoring Databases. See also a summary/cheat sheet of the book's refactorings.