合理规划mysql表 (表规划规范)

mysql表的规划和相关问题

这个问题问的好，要弄一个表很简单，关键是表规划出来是否合理！

假如表规划的好，则会适当明晰，易于了解，后续开发上事半功倍，保护也便利；假如规划的欠好，则难以了解，保护困难，价值大。

表与表之间的联络有三种：1.一对一，2.一对多，3.多对多

一对一的表，两表的特点实际上完全能够合并成一个表，共用一个主键即可；

一对多的表，能够设中心相关表，也能够将相关表并入“多”这头；若设独立相关表，则可引进“多”这头的主键作为其主键，也可另立主键，并将“一”和“多”两表的主键作为相关表的外键；

多对多的表，则有必要设中心相关表，相关表设独立主键，并引进两个“多”头的表的主键作为相关表的外键。

这是上述三种联络表在键处理上的基本准则。

范式仍是要遵从的，这套理论仍是科学合理的。不要信任反范式规划，反范式规划在规划巨大时，数据冗余多，编码及保护会变得困难，假如考虑漏掉的将导致数据不一致，乃至变成灾祸。严厉依照范式理论来规划数据库，将使你编码及保护时少操很疑心。

一般来说，先进行需求剖析，然后画出数据流图，然后再依据数据流图画出ER图，然后再依据ER图创立各种表。表是依据ER图来创立的，表规划的合不合理，关键是ER图抽像的合不合理。在抽像ER图时，一般遵从这样的准则：

能用1对1的，就不必1对多；能用1对多的，就不必多对多，往简单化方向靠；

能当特点处理的，尽量当特点，而不是当实体处理去另立新表，这样可使问题简化。

把含义附近联络严密的特点放在一张表内，而不是拆在多张表中。

看了一下你上述几张表，我以为不合理，户主是人，家庭成员也是人，把他们分在户主表和家庭成员表中不合理，他们是同一类的，宜合在一张家庭成员表中，并添加一个标志性字段，以指明哪个人是户主。其他，宜树立一张地址表，以替代户主表，地址表中宜指明乡场镇、村巷道、几区、门牌号等与地址联络严密的特点，把户籍、联络方法、户主等字段拿走，他们不是地址特点，这几个宜放在成员联络表中，户籍是人的特点，并非地址的特点，联络方法就更显着了，要联络的是人，而不是地址。

很显着，地址和家庭成员是一对多联络，一个地址一起能够住着多个成员，而一个成员一起只能住一个地址，这样，规划成地址表和家庭成员表之后，要在家庭成员表中再加一个地址外键字段，把地址表的主键当作家庭成员表的外键填入，这样，成员表中的每个人都能够经过地址外键字段到地址表中找到其所住地址。其他，成员表中也指明晰哪个人是户主，也指明晰每个人的户籍和联络方法，这些信息你都能够找得到。

Blue and Glue HAO Design

“mysql”到达1亿等级怎么规划优化？

1.首要能够考虑事务层面优化，即笔直分表。

笔直分表便是把一个数据量很大的表,能够按某个字段的特点或运用频频程度分类,拆分为多个表。

如有多种事务类型，每种事务类型入不同的表，table1,table2,table3.

假如日常事务不需要运用一切数据，能够按时刻分表，比如说月表。每个表只存一个月记载。

2.架构上的优化，即水平分表。

水平分表便是依据一列或多列数据的值把数据行放到多个独立的表里，这儿不具有事务含义。

如依照id分表，结尾是0-9的数据别离刺进到10个表里边。

或许你要问，这样看起来和方才说的笔直分表没什么差异。只不过是否具有事务含义的差异，都是按字段的值来分表。

实际上，水平分表现在最盛行的完成方法，是经过水平分库来完成的。即方才所说的10个表，散布在10个mysql数据库上。这样能够经过多个低装备主机整合起来，完成高性能。

最常见的解决方案是cobar，这个帖子介绍的比较完善，能够看看。