SQL语言艺术(数据库建模要点)

自从第一次数据库以来，我一直都在做所谓的建模。想来建模无非就是建建表，加加字段，最多还摆几个索引上去。建表的话，程序怎么方便怎么来，字段的话，甚至可以全部用varchar....

经常也会考虑到怎样的表，怎样的模型才是最高效的模型，最好扩展的模型，最能够体现业务的模型。在仔细读这本书之前，一直不得其法。 虽然也会努力的想设计好这些模型，比如采用面向对象的方式，但做出来的东西，还是缺乏保障，需求稍微抖一抖，数据模型就稀里哗啦，程序就更不用说了。


SQL语言艺术这本书，开篇就说明了不适合SQL的所谓精通者，如果没有经历过海量数据的折磨，就不能够领悟都里面的要点。 2年前买这本书的时候还不信邪，果然最后还是没有啃下来。


下面列出数据建模的几个基本原则：

1. 确保属性的原子性，这个原子性和业务相关，某些时候的原子，在另外的业务场景下并不原子。

2. 确保没有冗余（最近非3NF的设计总是吸引眼球，用故意冗余来提高效率）

3. 确保依赖关系的独立性，依赖到足够的键 （冗余是键多了，这里是键少了）

4. 限制用1/0这种开关值，用富有意义的值来代替。isComplet < completDate, 为了避免Null值，completeDate可以用单独表划出来

5. 值不能出现三元逻辑，Y/N/Unknow

6. 不能有null值的属性，更不能出现两个字段，A有值则B=null, B有值则A=null

7. 出现null的时候，就表示需要添加子类型。

8. 子类型的规则，a.主键就是父类型的外键 b.是父类型的子集 c.各个子类型之间没有交集。

9. 不要建立什么通用表，即把表名，字段名，等都存入value，用以获取最通用的效果

10. 保存History的数据要规范，每个时间点保存一个数据，不要太取巧

11. 考虑数据量，考虑访问的方式 同步还是异步， 处理的方式。

12. 考虑架构的方式，是集中还是多台服务器，集群呢还是网格

13. 表中切勿包含隐藏的业务规则，比如某个值只能>1000,应该包含明确的约束。定义好外键和约束有助于DBMS进行优化


总之，以后设计表，要一条条过，争取获得最好的设计。