企业管理信息系统（mis）的业务数据类型大体分为几种：主数据，交易数据，结果数据，配置数据等。其中交易数据就是大家通常说的表单，结果数据是交易数据导致的结果，比如各种账本。这两类数据分属于不同的类型，作用，存在的时间，消费的对象，特性都不一样，因此在数据库设计时，要考虑这个区别。
具体怎么设计呢？
我们举个具体的例子好说，合同和合同台账。在这里，签订合同时属于交易数据，合同执行台账是结果数据。为什么叫合同“执行”台账，因为合同签订后，有后续的执行动作，比如验收，收付款。合同执行台账，会记录合同的履行数据，后续的这些操作，都会修改合同执行调账（合同台账的精简结构：合同，合同金额，验收金额，收付款金额）。
设计的误区
在设计表结构时，有一种设计是把 合同 和 合同台账 合二为一，在合同表中，增加了验收金额，收付款金额等。
这样设计的优点或者理由是“节省”一个表，查询合同时好查询（不用关联），界面展示的时候也简单。
这样做“可以用”，但是不是好的做法。我们做任何事情，尤其是系统开发，不能满足于可以用，而是要好用。
为什么这样做不是好的做法呢？
1、不符合我们的认知常识。大家知道在设计数据库时，有概念设计，就是从业务的角度和立场来考虑数据库实体，合同 和 合同台账是两个东西。
2、从数据稳定性来讲，合同数据是稳定的，生效后一般就不变化了，这叫静态数据；而合同台账则不同，随着合同的履行，每次验收和付款都会修改合同台账的数据，所以说台账是“动态”的。动静不同的业务对象不适合混在一起。
3、从结构的稳定性上讲，较结果对象而言，交易对象的结构更易变，这符合“越贴近实际的东西越易变”这个常识。比如增加个字段啊，减少个字段啊，经常的事。因此，从结构上讲，台账是稳定的，合同是多变的。所以，二者也不适合混在一起。
4、从设计的耦合性上讲，设计的一个原则就是尽量降低模块间的耦合，所谓高内聚低耦合。在这个例子中，合同是“消息”（台账数据）生产者（合同生生效后，创建合同台账），验收单和付款单是“消息”消费者。除此之外，还有其他的消费者，可能是本系统的，还可能是外部系统（比如外部系统查询合同台账）。因此在这个模型中，“台账”是个中间者，是生产者和消费者之间的隔离，在“使用”合同台账时，大家虽然都访问“合同台账”，但可以互不知晓（低耦合）。台账结构，访问和修改的规则，这就是协议、契约，大家遵循这个契约就ok。
5、想想你要给客户上系统，初始化数据，对执行中的合同进行初始化，交易数据和结果数据混在一块，想想就复杂。我举个具体的例子，某个系统的业务流程：合同，验收，付款。已验收金额放在合同中，已付款金额放在验收单中，如果初始化的时候，本来只初始化合同就可以了，为了初始化付款金额，还要初始化验收单。
6、最后一点，在数据表上，把不同的数据混在一块，看上去就很不“干净”，不利索，增加了使用者的成本和困惑。这都是潜在的不利因素。
因此，在系统设计上，要有一定的“道”，也就规范，模式。规范和模式都是大家在长期实践中总结出来的好的做法，是最佳实践。我们要做的是遵循它，改进它，而不是违背它。
这就是设计之道也。