设计原则

经验

扩展性：是否对后期的业务开发，拥有扩展功能。这也是架构设计和基础开发的区别；

字段冗余原则

1. 相关字段是否变化：例如订单存储商品的成本价，批发价等，这些在后期是会变化的，因此下单时候需要存储当时的以便追踪当时订单的价格情况；
2. 性能问题：如果这个字段数据操作中频繁使用，需要冗余。例如退款时候，需要用户ID，而且是异步任务在处理，如果此时不容易用户id,任务处理时候就需要调用接口来获取用户ID，造成操作不方便和性能问题，此时就需要容易会员ID字段；
3. 是否方便查询：正常严格按照也对对象来设计表，但是有时候为了方便业务数据查询，例如避免连表查询，常常会在表里面冗余字段，来方便数据查询和操
4. 冗余过多字段不一定好：每冗余一个字段，就意味着维护成本增加，为ERP开发时候应收单、收款单冗余了区域、等相关字段，这些字段有些为了推送NC冗余，有些事为了推送K3冗余，有些是为了其他操作冗余，这样造成开发时候，操作数据库表，创建对象时候，需要设置很多变量，代码量很大，非常被动，因此，后期表设计，应该尽量只是冗余相关数据主键，其他频率很高的字段可以冗余进来，不要过多的冗余很多无用字段，基础资料发生变化时候，也导致后面的单据无法推送下去；
5. A系统依赖B系统的数据，是直接冗余存储还是查询时候同步取出。判断依据是若B系统的数据变化不大，则可以直接冗余存储，查询时候直接读出来，若B系统数据变化较为平凡，则需实时查询；

垂直切分原则

1. 从业务角度来拆分，不同业务不同的库以及表；
2. 使用方便性和查询效率：表拆了过多之后，往往不方便查询，或者查询效率低，此时需要做最终的权衡；