本篇内容主要讲解“MySQL的表设计与使用”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MYSQL的表设计与使用”吧!
创新互联公司-专业网站定制、快速模板网站建设、高性价比佳县网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式佳县网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖佳县地区。费用合理售后完善,十载实体公司更值得信赖。
一个表的设计,个人愚见,首先要看业务,以及你选择的架构,业务量是大还是小,业务是互联网性质的,还是传统性质的,业务是可变化较大的,还是比较固话的,等等,当然可能还有更细分的,从数据库的角度来看,你是准备使用哪种数据库,决定是可以分库分表,还是分区表,或者冷热表,在或者使用特殊的某些小手段,来让你的表更清爽一些。同时不同的数据库也赋予表设计更多的余地,所以我一直在希望开发和DBA能紧密结合,因为开发大部分是不知道各种数据库的门道,和一些奇特的功能,而DBA可能并未有开发人员的对业务理解的深刻,如果二者结合,则设计的表会比单方面设计的表要好的多。也更值得推敲。
下面就说说,在MYSQL 表设计中的一些见过的,小麻烦,以及如何化解。
1拿到的数据中,MYSQL的表竟然没有主键,根据和开发人员交流,发现他们有一个很有趣的想法,认为没有主键的表的插入速度会快,因为他们要要求插入的速度要快,而根据他们以往的ORACLE的经验是这样认为的。当时和他们解释,他们提出ORACLE的表没有主键会在表上默认产生ROWID,所以对这样的信息记录的表(弱业务)是可以这样设计的,先不提在ORACLE 这样是否OK,在MYSQL 中我只问了他们一个问题,“请问这个表还需要查询吗”,回答是当然。
根据他们的回答,我建议,既然要查询,则需要建立主键,或者退而求其次建立唯一索引。并解释了为什么(MYSQL的表的原理,以及底层结构),开发人员表示认同,随即添加主键。
其实之前也是遇到过这样的情况,但当时解释的角度就是一句,规章制度,军规,或者在解释MYSQL的复制必须要设置主键,等等。但开发人员给我的回馈是不是太好,这让当时我的反思,在解决问题的时候要站在对方的角度,来处理,对方会更好的接受和理解,并且还会和你一条心的解决,因为这设计了他自己的利益。
2 在参与一个系统的设计时,开发人员将一个表的主键设置为多个列,根据业务逻辑来看,他这样做是没有问题的,地区编码,加客户编码,加客户的类型,是能决定这个表中客户的唯一性,虽然从MYSQL本身的角度不建议这样做,但开发人员提出,那业务已经这样设计,你让我怎么办,这里面差一个字段,都不能确认具体的客户的唯一性,而且业务也没有打算给每一个客户分配一个唯一的编码。
到此即使你拿出军规,或者数据库原理来和开发讲,也是无效,他也是受害者。现在关键的问题是你怎么来化解这个事情,而不是强硬的创造“对立面”。
解决方法1 和开发人员商量,是否可以创建递增主键,按照INT 类型,而我们的区域,客户类型,以及客户ID,则作为唯一索引进行创建,开发人员表示可以考虑。
解决方法2 和开发人员商量,是否可以通过重新物理编码的方式,通过三个字段的值进行运算后得出一个唯一值,将这个值作为主键,并且计算值的时候可以考虑一下顺序性例如
区域+ 用户类型 + 用户ID +数据插入时间 (可以到秒)--根据输入的用户量与时间的之间的比率。并且在表的字段中加入数据插入的时间,这样虽然看上去比上面的方式麻烦,但可以解决查询时的唯一性,也不需要建立唯一索引,通过主键可快速定位相对应的用户。
最后的结果,开发选择了第二种方法,其实大部分DBA 都是拿出,规则,规矩来进行限制,当然这本身是对的,这也是为系统正常运行来考虑的,但如果稍微站在对方的角度,来处理,可能效果预期会更好。
3 在开发一个系统的时候,大部分开发人员之前是没有使用过MYSQL数据库的,在表结构的设计,虽然之前提及过的一些MYSQL 特有的规范,但还是在数据库的设计中发现了大量的主外键设计,随即和开发人员沟通,发现开发人员的想法还是在三范式,3NF,以及表之间关联性完整性,以及数据的不重复性考虑。后面和开发人员沟通,对当前使用的MYSQL的版本以及 Join 的MYSQL 操作原理进行了讲解,开发人员表示理解,后面和开发人员将原来的表设计重新梳理,将一些频繁查询的数据汇总到一张表,或两张表中,不在4-9张表进行JOIN 才能获得数据,同时也对开发人员在改变设计后的繁琐表示理解。
从沟通中也了解,程序员的想法,大多是根据3NF的影响,避免不同表中重复的字段,在查询中通过多个表的关联+条件,进行信息的输出,与互联网行业相比某些传统的行业的逻辑会比较复杂,所以使用MYSQL 会让程序在非数据库层做的更多,想的更多。这也是部分程序员吐槽MYSQL 数据库不好用的原因。
所以和在使用任何一种数据库的时候,前提要以服务业务为中心,基于所使用的数据库的原理进行发散,或混合行的思维方式,不能只死在一个数据库,例如如果频繁的更新状态,但一行记录或业务无论有多少次变化,但最后的变化的值是固定的,那是不是可以使用其他的数据库(非RDS)来进行快速的状态缓冲最终将结果刷入的到数据库表中,避免由于频繁更新和查询产生的性能问题,等等这都是需要开发和DBA 进行沟通,利用互有的知识进行,以达到最大的优化和将问题消灭在系统设计的初期。
所以,合作能共赢,而军规,规定等等都是一个范围,而如果在这个范围无法解决问题,则这个范围是不是有问题,或者我们是否还能更进一步的提高自己的能力,利用各种手段维护军规的同时,还能满足业务,开发的需求,这就要看个人的能力,你会的越多,你解决问题的高度就会更高。相关与你有关的对立面就越少。
到此,相信大家对“MYSQL的表设计与使用”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!