工作中对数据库设计的经验

以下描述仅仅是个人经验总结，仅供参考！！！

我认为数据库设计分为库和表的设计，所以从这两方面着手介绍。
库的设计
1、数据库名称要明确，可以加前缀或后缀的方式，使其看起来有业务含义，比如数据库名称可以为Business_DB(业务数据库）。
2、在一个企业中，如果依赖很多产品，但是每个产品都使用同一套用户，那么应该将用户单独构建一个库，叫做企业用户中心。
3、不同类型的数据应该分开管理，例如，财务数据库，业务数据库等。
4、尽可能少的使用业务逻辑，由于存储过程在不同的数据库中，支持方式不一样，因此不建议过多使用和使用复杂的存储过程。为数据库服务器降低压力，不要让数据库处理过多的业务逻辑，将业务逻辑处理放到应用程序中。

表设计

1. 数据库表命名，将业务和基础表区分，采用驼峰表示法见文知意等。
2. 数据不要物理删除，应该做逻辑删除，加一个标志位，以防用户后悔时，能够恢复 。
3. 添加时间，有添加时间可以明确知道记录什么时候添加的
4. 修改时间，可以知道记录什么时候被修改了，一旦数据出现问题，可以根据修改时间来定位问题。比如某人在这个时间做了哪些事。
5. 基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是 最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间 的目的
6. 若两个实体之间存在多对多的关系，则应消除这种关系。对数据库的查询都要进行磁盘的读写，多对多要通过三张表的查询，每张表的打开关闭要耗时间的，如果把它拆分为一对多的关系，就相当于减少了一张表，速度会提快。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配 到三个实体中去
7. 对于主键的设计：
   1. 不建议用多个字段做主键，单个表还可以，但是关联关系就会有问题，主键自增是高性能的。导入导出就有问题
   2. 一般情况下，如果有两个外键，不建议采用两个外键作为联合主键，删除记录的时候有可能删除多了。另建一个字段作为主键。除非这条记录没有逻辑删除标志，且该表永远只有一条此联合主键的记录。
   3. 一般而言，一个实体不能既无主键又无外键，至少有个主键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。