没有，谢谢
  回复  引用    

使用第五范式
  回复  引用  查看    

楼主说设计 其实部分已经踏入所谓优化的范畴

提升性能的方法无非是适当的增加存储空间(索引（当然有很多种不同），触发器（为了在不同表填入相同值）)

要不就是提前完成(Oracle 中的物化视图)

“应用程序本地缓存数据” 应该不能算数据库优化的范畴， 缓存会带来脏读等问题，而破坏读写移植性。

“将活动数据和历史数据分开存储” 这个应该属于减少查询总量。 既数据库没有必要去查那么多数据。 为什么不将其归档？ 但假如要查了呢？ 其实只是一个概率的问题。

具体怎么的设计还要看 所谓硬件的提供与业务逻辑的搭配。 个人认为磁盘I/O一般作为首要考虑（谁让他最慢呢，内存又便宜。。。）
  回复  引用    

好！随笔与评论同样精彩，学习之！
  回复  引用    

挺有意思，自己比较懒，不好好总结，今天看到了，如遇知音。用空间换时间不亏是个不错的方法，有的时候还有意外的收获，比如发货单中存放联系人，公司名称等信息，一方面省笛卡尔积的时间，其次，即使今后客户信息改了，也不会影响这些发货单，保持了他的真实性；至于父表放放汇总值，我不太常用，比如发货单基本信息中放总货品件数，有一个问题比较麻烦，如果一旦UPDATE OrderDetail 中 Product 的 数量，往往导致汇总的和基本信息中的数量不一致，除非你用触发器这个无形的手，或者显示修改总数；觉得不方面，一般我会根据不同需要做个视图，以满足不同场合的需求；活动数据和历史数据分开似乎成了一个习惯。在一个ＨＲ系统中，我将计算总的工资与工资报表中分开，只有工资一旦发下，锁定后才将数据滚入报表中，这样一方面降低了应用程序开发的复杂度，其次，提高了计算速度（计算过程中的数据量很少，不需要做无谓的笛卡尔积或者过滤了），第三，提高了数据的安全性，不会对历史数据做误操作。
至于冗余，我觉得在前面的利诱之下已经变得不太重要。
当然，有时候也还是要参考一下范式，好好权衡范式与楼主总结的原则。
  回复  引用  查看