作为一个程序员你避免不了要设计数据表，总是一味地根据他人给出的表来写sql这样你永远也得不到成长。所以我现在要来思考如何设计出数据库表。
那问题来了，如何设计呢？这可是大问题啊...因为我之前就没怎么设计过表，我印象中我只设计过一次表，而且那次我记得设计的出了大问题，我要在毫无关联的两张表中查出2个有关联的字段，你看到这句话肯定很蒙，你一定会想问这字段到底有没有关联啊？有的，关联确实是有的，但是我设计的时候并没有把这两张表关联上，再加上当时数据库没学好，而且就剩三天就要验收程序了，慌啊，然后请教同学，他给一通操作整好了，我当时也没多想他到底是如何整好的。这也导致了我对表的设计还是一头雾水。
直到最近，我才有了一点想法。这个想法是这么来的，尽管我不知道表的设计，但是学过MVC框架，我知道MVC框架中必然会有实体，而一张表里的字段对应着实体里的变量，那我们不妨反过来想想，一个实体就对应着一张表，我们设计表不就是设计实体吗？实体有什么属性，表里自然也就有了什么字段。这几个实体究竟有什么关联，以什么作为关联的纽带，这便是我们接下来要考虑的东西，一个实体和另一个实体有没有可以关联的字段？有，好的，那我们给他添加上关联字段。没有？那我们再想想，有没有哪一个或哪几个实体能为他们的联系牵线搭桥，让他们联系上，如果有的话那这个设计就没有问题，至少是行得通的设计。如果没有，则说明这是一个绝对孤立的实体，没有任何实体能与它产生关联，那我认为这种情况就不应该存在，你设计出一个完全孤立的实体出来有什么用？拿来当观众吗？这时你就要想了，这个完全孤立的实体究竟有没有存在的必要，如果有存在的必要，那就建立中间表，把他们连起来，没有存在的必要，就想方设法把这个表里的字段往其他表里添。
话又说回来，实体怎么来？要看你的业务了，业务又从哪里来？就从项目最开始的阶段，需求分析来，所以说需求才是项目的重中之重，不信？你上网搜一搜就会发现，只有需求分析是要多次确认的，有一点不清楚的地方都不行，他有可能导致项目有较大的改动，很可能把之前的努力摧毁掉，所以这个需求分析你一定要做好。
还有一点，属于我还有疑惑的部分，那就是两个表的关联，是关联两个表的字段好，还是建立中间关联表更好，这个我还不太清楚，或者说这个要看情况而定，也希望大家能够给予我一些思路
每张表都具备id这个属性，而随着系统越做越大，id则会越来越多，所以他的类型应设为bigint（也可以是Long），长度设为20
是否启用（bool类型的东西）、类型（type），状态（state）类型应设为tinyint，长度设为1，一般设个默认值0
创建时间（createtime）应设为datetime类型，数据库也是有date类型，而我们用datetime而不用date的原因是datetime有时分秒，而date精确到天
普通的varchar类型字段建议设置默认值为null（empty string)
手机号可以使用char类型，因为手机号都是固定13位的，用char可以节省空间
对于内容字数比较多的时候你就不能使用varchar了，应该改用text类型
表与表之间关系为一对多应该怎么设计？表与表之间关系为多对多又应该怎么设计？一对多关系一般都是主从表，一个主表可以对应着多个从表，也就是说他们需要关联字段（id），分别在主表和从表里加上他们的关联字段就好，没有建关联表的必要。而多对多关系的话，则必须要建立关联表，把两张甚至多张表关联起来，根据aid查询多个bid，再拿这多个bid来用，反过来也是，用bid查询多个aid，就可以拿到这多个aid来用，用的意思就是增删改查及批量增删改查
还有就是状态还可以用enum来声明，值得注意的是他和bit，tinyint有点不同，他对应的java类型不是boolean，而是String，如果他设置好'0'是不开启,'1'是开启，最好是将字段 赋值为 '0'或者'1'，写数字的话就是1,2（神奇的坑....）
之前说了建表，关联。那表里的字段应该怎么设计呢？建表阶段都处在一个系统的起始阶段，那这个时候就肯定会有原型图，这时你就需要看着原型图来设计字段，第一张表肯定是需要什么就加什么，从第二张表开始就要思考这张表和前面的表有什么联系，有联系的话加个关联字段比如id就可以满足需求，因为你只要拿到了id你就可以拿到那一整张表里的数据，其实这个基本操作大家都会的，关键是要根据业务的需要，考虑设计冗余字段方便操作，别拿数据库三范式怼我，有时候你就是需要一些冗余字段方便使用，这个也是我接下来要考虑的问题，怎么把业务体现在表的设计上，字段不清晰可以问问产品
跨境，跨国（跨了时区）应该使用timestamp时间戳而不是datetime，关于delete_flag按照规范来说表表都要有，实际上并不一定，怎么说呢，不重要的记录，删了就删了不会有影响（我觉得这个还是要和产品讨论研究，到底能不能删，一定要想好），像记录这种需要有迹可循的就一定不能删，方便用户也方便管理人员，起了纠纷就是记录说话