【发布时间】：2018-10-25 15:59:20
【问题描述】：
我想问一个只能通过经验来回答的问题。
我正在创建一个 SQL 数据库（金融） - 它使用实体框架。
数据库可以分为两个不同的部分：
- （申请人）- 个人详细信息、地址、联系方式和 提出的申请；
- （处理）-贷方，花费的时间 流程、支付的佣金等。
这两个部分可以通过ApplicationId连接起来，ApplicationId也是#2中的TransactionId。
但是，这两个部分有两个截然不同的目的：
第 1 部分 - 客户申请记录（可能存储至少 6 年）并用于为客户提供服务；
第 2 部分 - 内部统计数据/分析（可能存储的时间要少得多，并且随着时间的推移会发生更多变化）。
最初的想法是构建一个单一的数据库（通过 ApplicationId 链接），但我现在不确定这是不是正确的方法。对每个部分进行的查询不太可能交叉，并且在极少数情况下需要进行几次查找而不是一次。
考虑到这一点，将其分成两部分或两个模型是否是一种更明智的长期方法？
这是一个关于实用性的问题，而不是关于大型数据库大小或模型复杂性的问题。
任何建议表示赞赏。
【问题讨论】：
-
这里没有正确或错误的答案。而且几乎不可能根据这么少的信息得出可靠的意见。
-
我同意肖恩的观点，但正如我从一开始就指出的那样，有了经验（我没有），这个决定变得更容易。
-
你是对的。但这被认为是 SO 的主题。即使它是关于主题的，也无法回答，因为几乎没有提供任何细节。也许简单地使用 2 个模式就可以了？也许你完全想多了，你只需要一个数据库（我猜）？或者您可能需要一个填充了日常数据移动的分析立方体？谁知道？
标签： sql sql-server entity-framework database-design database-schema