13518219792
选中某个表，然后右键点击，选择“设计表”即可。
创新互联公司专注于石狮网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供石狮营销型网站建设，石狮网站制作、石狮网页设计、石狮网站官网定制、小程序定制开发服务，打造石狮网络公司原创品牌,更为您提供石狮网站排名全网营销落地服务。
也可以左键点击某个表（即选中某表），在上面辅助菜单栏里有“打开表”、“设计表”、“新建表”等按钮可点击，点击“设计表”按钮即可。
进入后，会弹出新的操作窗口，新窗口的菜单栏里有常用的修改表结构的按钮，右键点击某列字段也可以弹出相应的修改表的操作按钮。
其它摸索着看提示操作即可，还是很简单的。
修改好表后点击菜单栏上的“保存”按钮即可。
注：若要查看修改表的sql语句，必须在“保存”之前点击“SQL预览”按钮。
1.数据库中的多对多关联关系一般需采用中间表的方式处理，将多对多转化为两个一对多。
2.通过表的关系，来帮助我们怎样建表，建几张表。
一对一
一张表的一条记录一定只能与另外一张表的一条记录进行对应，反之亦然。
学生表：姓名，性别，年龄，身高，体重，籍贯，家庭住址，紧急联系人
其中姓名、性别、年龄、身高，体重属于常用数据，但是籍贯、住址和联系人为不常用数据
如果每次查询都是查询所有数据，不常用的数据就会影响效率，实际又不用
常用信息表：ID(P)，姓名，性别，年龄，身高，体重
不常用信息表：ID(P)，籍贯，家庭住址，紧急联系人
解决方案：将常用的和不常用的信息分享存储，分成两张表
不常用信息表和常用信息表，保证不常用信息表与常用信息表能够对应上：找一个具有唯一性的
字段来共同连接两张表。
一个常用表中的一条记录永远只能在一张不常用表中匹配一条记录，反之亦然。
一对多
一张表中有一条记录可以对应另外一张表中的多条记录；但是反过来，另外一张表的一条记录
只能对应第一张表的一条记录，这种关系就是一对多或多对一
母亲与孩子的关系：母亲，孩子两个实体
母亲表：ID(P),名字，年龄，性别
孩子表：ID(P),名字，年龄，性别
以上关系：一个妈妈可以在孩子表中找到多条记录（也可能是一条），但是一个孩子只能找到一个妈妈
是一种典型的一对多的关系。
但是以上设计：解决了实体的设计表问题，但是没有解决关系问题，孩子找不到母亲，母亲也找不到孩子
解决方案：在某一张表中增加一个字段，能够找到另外一张表中的记录:在孩子表中增加一个字段
指向母亲表，因为孩子表的记录只能匹配到一条母亲表的记录。
母亲表：ID(P),名字，年龄，性别
孩子表：ID(P),名字，年龄，性别，母亲表ID（母亲表主键）
多对多
一对表中（A）的一条记录能够对应另外一张表（B）中的多条记录；同时B表中的一条记录
也能对应A表中的多条记录
老师和学生
老师表 T_ID(P),姓名，性别
学生表 S_ID(P),姓名，性别
以上设计方案：实现了实体的设计，但是没有维护实体的关系
一个老师教过多个学生，一个学生也被多个老师教过
解决方案：增加一张中间关系表
老师与学生的关系表：ID(P),T_ID,S_ID
老师表与中间表形成一对多的关系，而中间表是多表；维护了能够唯一找到一表的关系；
同样的学生表与中间表也是一个一对多的关系;
学生找老师：找出学生ID---中间表寻找匹配记录（多条）---老师表匹配（一条）
老师找学生：找出老师ID---中间表寻找匹配记录（多条）---学生表匹配（一条）
建一个字段就可以了
存入的时候用一个特殊的标点符号隔开
现在大部分的网站都是这么做的，你可以看看起点，迅雷
他们要求输入标签的时候就是让你直接输入一个字符串，然后用逗号隔开
到时候你读的时候也截取下字符串来读
这样就可以了
截取字符串可以在数据库里做，这样比较快
最好就是做成存储过程，到时候调用一下就可以了，方便的很
表统计信息是数据库基于成本的优化器最重要的参考信息；统计信息不准确，优化器可能给出不够优化的执行计划或者是错误的执行计划。对统计信息的计算分为非持久化统计信息（实时计算）与持久化统计信息。
非持久化统计信息
统计信息没有保存在磁盘上，而是频繁的实时计算统计信息；
每次对表的访问都会重新计算其统计信息；
假设针对一张大表的频繁查询，那么每次都要重新计算统计信息，很耗费资源。
持久化统计信息
把一张表在某一时刻的统计信息值保存在磁盘上；
避免每次查询时重新计算；
如果表更新不是很频繁，或者没有达到 MySQL 必须重新计算统计信息的临界值，可直接从磁盘上获取；
即使 MySQL 服务重启，也可以快速的获取统计信息值；
统计信息的持久化可以针对全局设置也可以针对单表设置。
接下来，详细说 MySQL 统计信息如何计算，何时计算，效果评估等问题。在 MySQL Server 层来控制是否自动计算统计信息的分布，并且来决策是持久化还是非持久化。
这个问题问的好，要弄一个表很容易，关键是表设计出来是否合理！
如果表设计的好，则会相当清晰，易于理解，后续开发上事半功倍，维护也方便；如果设计的不好，则难以理解，维护困难，代价大。
表与表之间的关系有三种：1.一对一，2.一对多，3.多对多
一对一的表，两表的属性实际上完全可以合并成一个表，共用一个主键即可；
一对多的表，可以设中间关联表，也可以将关联表并入“多”这头；若设独立关联表，则可引入“多”这头的主键作为其主键，也可另立主键，并将“一”和“多”两表的主键作为关联表的外键；
多对多的表，则必须设中间关联表，关联表设独立主键，并引入两个“多”头的表的主键作为关联表的外键。
这是上述三种关系表在键处理上的基本原则。
范式还是要遵循的，这套理论还是科学合理的。不要相信反范式设计，反范式设计在规模庞大时，数据冗余多，编码及维护会变得困难，万一考虑漏掉的将导致数据不一致，甚至酿成灾难。严格按照范式理论来设计数据库，将使你编码及维护时少操很多心。
一般来说，先进行需求分析，然后画出数据流图，然后再根据数据流图画出ER图，然后再根据ER图创建各种表。表是根据ER图来创建的，表设计的合不合理，关键是ER图抽像的合不合理。在抽像ER图时，一般遵循这样的原则：
能用1对1的，就不用1对多；能用1对多的，就不用多对多，往简单化方向靠；
能当属性处理的，尽量当属性，而不是当实体处理去另立新表，这样可使问题简化。
把意义相近联系紧密的属性放在一张表内，而不是拆在多张表中。
看了一下你上述几张表，我认为不合理，户主是人，家庭成员也是人，把他们分在户主表和家庭成员表中不合理，他们是同一类的，宜合在一张家庭成员表中，并增加一个标志性字段，以指明哪个人是户主。另外，宜建立一张地址表，以取代户主表，地址表中宜指明乡场镇、村巷道、几区、门牌号等与地址关系紧密的属性，把户籍、联系方式、户主等字段拿走，他们不是地址属性，这几个宜放在成员关系表中，户籍是人的属性，并非地址的属性，联系方式就更明显了，要联系的是人，而不是地址。
很明显，地址和家庭成员是一对多关系，一个地址同时可以住着多个成员，而一个成员同时只能住一个地址，这样，设计成地址表和家庭成员表之后，要在家庭成员表中再加一个地址外键字段，把地址表的主键当作家庭成员表的外键填入，这样，成员表中的每个人都可以通过地址外键字段到地址表中找到其所住地址。另外，成员表中也指明了哪个人是户主，也指明了每个人的户籍和联系方式，这些信息你都可以找得到。
