1.C.J.Date关于分布式数据库的12条告诫
本地站点的独立性。每个本地站点都有一个独立自主的集中式DBMS，每个站点都必须保证安全性，并发控制，备份和恢复
中心站点。在网络中的站点都与中心站点或其它站点无关，所有站点具有同样的功能
故障独立性。节点发生故障不会影响到系统，即一个节点发生故障，系统也能继续运行
位置透明。用户检索数据时，不需要知道数据的位置
分割透明。数据分割对用户透明，用户仅能看到一个逻辑数据库，用户检索数据分割时，不需要知道数据库分割的名字
复制透明。用户仅看到一个逻辑的数据库，DBMS透明的选择数据库分割，对于用户来说，DBMS透明的管理所以分割
分布式查询。查询可能在不同的的DB站中运行，DBMS透明的实行查询优化
分布式事务管理。一个事务可能在不同的站点更新数据，DBMS透明的实行事务管理
硬件独立性。系统必须可以在任何硬件平台运行
操作系统独立性。系统必须可以在任何操作系统平台上运行
网络独立性。系统必须可以在任何网络平台上运行
数据库独立性。系统必须支持任何厂商的产品数据库
2.数据库设计策略
数据库设计的两个经典方法是：自顶向下设计，自底向上设计。
自顶向下设计：先识别数据集，然后对集合定义数据元素，这个过程将经历实体识别到实体的属性定义。
自下向上设计：先定义数据元素项，然后将其组合成数据集，这个过程经历属性定义到组合成实体。
这两种方式是相互补充的，根据业务场景和开发经验来做出选择，通常少量实体，属性，关联关系的数据库时可以将关注点放在自底向上的方法。如果数据库更为复杂，则考虑使用自定向上的方法。
依个人经历，倒是很少使用自底向上的方法，不过当数据集较为庞大的时候或多或少用到该方法的思想，比如先抽取一些属性，初步组合成一些实体供后续分析使用。
3.关于数据库中的命名
可能较为严格的命名约定会让人头疼，甚至为了一个表或者属性的名称简明思议绞尽脑汁，但是正真做到这样的约束带来的好处会让人成为命名约定的忠实粉丝。
使用描述性的词语来命名表，属性名，管理关系等
复合实体命名通常可以描述所表示的关系
避免数据库系统的关键词作为命名名称
所有的命名规则做到统一
4.主码（数据库表主键）的选择原则
| 主码特征 | 描述 |
| 唯一性 | 唯一的识别一个实体实例（数据库表的一条记录），值不能为空 |
| 非智能（不含具体语义） | 无实际语义（如学生学号），含有语义的属性更适合描述实体特征 |
| 不随时间变化 | 比如姓名，婚姻状况，地址，手机号码等都可能变化，应该选择永久不变的 |
| 最好单属性 | 非必须，但最好，单属性可以简化外键的实现和应用程序编码 |
| 最好是数值类型 | 数值类型便于管理，方便数据库实现计数，自增等功能 |
| 安全编码 | 不能存在安全风险，如身份证号码作为住码则有可能被碰撞检测到数据 |
本文出自 “野马红尘” 博客，请务必保留此出处http://aiilive.blog.51cto.com/1925756/1663448
原文地址：http://aiilive.blog.51cto.com/1925756/1663448
