一对一关系：
一对多模型：
商城中的 商品表shop_product 和 商品物品表 shop_product_item 是 一对多关系 。 关联字段是shop_product_item的product_id字段
多对多模型：
合能项目中 角色表manager_role 和 菜单表manager_menu 是多对多关系。中间表为manager_role_menu
三大范式：
1NF：
数据库表的每一列都是不可分割的基本数据项；
2列的属性相近或者相似，尽量合并成一样的列
2NF:
首先满足1NF，要求表的每条记录可以唯一区分（主关键字），要求实体(记录)的非主属性完全依赖于主关键词。
3NF：
必须先满足2NF ； 要求表中的每一列只与主键直接相关而不是间接相关。
3大范式总结：
- 2列的属性相近或者相似，尽量合并成一样的列
- 第二范式是说一张表中包含了所种不同的实体属性，那么要必须分成多张表，
- 第三范式是要求已经分成了多张表，那么一张表中只能有另一张表中的id（主键），而不能有其他的任何信息（其他的信息一律用主键在另一表查询）。
数据库命名：
- 字段和表名称 应该是 a_b , 用下划线隔开
navicat查看mysql表的关系：
数据库设计:
概念：
- 根据业务系统需要，结合选用的DBMS，为业务系统构造出最优的数据存储模型，建立好数据库中表结构及表与表之间的管理关系
为什么要进行数据库设计？？
物理设计：
目的：建立表结构
1、选择数据库系统：应用特点、成本
2、定义库、表、字段的命名规范（数据库系统对此有限制）
3、根据系统选择合适的字段类型
4、反范式化设计：增加冗余，提高效率备注：反范式，不满足范式的模型，就是反范式模型。反范式跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联。（如果关联查询效率很低，可以考虑使用反范式设计）
选择哪种数据库？？
- 成本 方面
- 事务成本 （大的事务操作）
备注：事务的大小通常是指一个事务中所处理的数据的多少和所包括的SQL语句的数量，比如说，我们在一个事务中既包括了UPDATE，INSERT，DELETE语句同时以有大量的SELECT语句那边这个事务就可以认为是一个大事务。
- 开发使用的语言
Java,php -- mysql ,oracle
- 应用场景
开源数据库 --- 适用于互联网项目
商业数据库 --- 更适合企业级项目
mysql常用的存储引擎：
表及字段的命名规则：
1、可读性原则
表名使用大写和小写来格式化库对象名字以获得良好的可读性。
字段使用下划线来连接
2、表意性原则
对象的名字应该可以描述他所标识的对象
3、长名原则
尽可能少使用或者不使用缩写，适用于数据库名之外的对象
数据库字段类型选择原则：
举例：
字段类型原则原则：当一个列可以选择多种数据类型时，应该优先考虑数字类型，其次是日期或者二进制类型，
最后才是字符类型。队友相同级别的数据类型，应该有限选择占用空间小的数据类型。
char和varchar如何选择？？
- char列的长度固定为声明的长度 ； varchar列的值为可变长字符串，长度为 L+1 字节 ；varchar需要额外的字节存储大小
- 如果列中的最大长度小于50byte,一般考虑用char （一般不宜定义大于50byte的char类型列）
- 如果列中要存储的数据长度差不多一致，应该考虑用char，否则用varchar
- 举例：身份证号、手机号使用char ；
decimal 和 float如何选择？？
- decimal用于存储精确数据
- 由于float的存储空间开销比decimal，故非精确数据优先选择float类型
时间类型如何选择？？
使用int来存储时间字段的优缺点：
- 优点：字段长度比datetime小
- 缺点：使用不方便，需要进行函数转换
- 限制：之恶能存储到2038-01-19
如何选择主键？？
避免使用外键约束？？
- 降低数据导入的效率
- 增加维护成本
避免使用触发器？？
- 降低数据导入的效率
- 可能会出现意想不到的数据异常
- 使业务逻辑变的复杂
关于预留字段
- 无法准确的知道预留字段的类型
- 无法准确的知道预留字段中所存储的内容
- 后期维护预留字段所要的成本，同增加一个字段所需要的成本相同的
- 严谨使用预留字段
- 需要根据实际情况考虑
为什么要反范式化？？
举例：
sql中select占比更多，所以可以增加读取效率，但是插入效率较低 。
反范式化优缺点：
- 减少表的关联数量
- 增加数据的读取效率
- 反范式化一定要适度（如果大量使用反范式化，会导致大量操作异常）