专栏首页AustinDatabases为凡人默哀 与 怎么从开发人员的角度,来看表设计和优化

为凡人默哀 与 怎么从开发人员的角度,来看表设计和优化

此篇的开始之前,默哀3分钟,某些伟大的凡人不是他位高权重,也不是他能一句话使整个世界停转,而是 陌生人 想起他,从心底为他的离去感到伤心,哪怕只有一秒。

What one does when he faced with truth is more difficult than you think.

十分抱歉本期没有彩色的图片,但希望这一个有温度的技术公众号

___________________________________________________________________________

怎么从开发人员的角度,来看表设计和优化

一个开发人员如果主动的来优化自己的查询,其实是一件不容易的事情,首先很多查询并不是开发人员自己写的,而是通过各种框架生成的语句.

所以这就造成了,优化语句的工作不在开发人员这一端,因为他们不知道实际上执行的语句是啥样子的,即使知道啥样子,实际上也很难来进行优化。

所以一般来说,他们需要对数据库捕捉后的语句的从慢到快的一个排列序列。通过这个序列,开发人员通过表的名字以及查询的结果,应该能很快的定位差不多的语句与模块之间的关系。

这样的方式的结果很可能是,对这个查询来分析是否缺少 INDEX ,或者语句的撰写是否有问题,将撰写的方式进行修改等等。实际上这样的方式仅仅能解决一部分问题,而将一部分问题掩藏,最终当数据变得更多的时候,问题可能再次出现,并且到时候在进行改变就很难了。

所以从开发人员的角度其实应该从以下方式来想以下问题

1 没有好的表设计,会为日后的问题埋下炸弹,数据库表设计是基础工作

2 表设计以及底层设计,会直接影响你后期的查询,数据写入

3 添加索引并不是解决问题的优选,或者出现问题的唯一解

4 差的表设计,将在数据量变大后,使得你上不去下不来,到时在进行表重新设计,将给程序的修改引起麻烦,甚至是导致部分模块重构。

在明白以上问题,开发人员优化语句的角度就会改变,不在仅仅以功能为主,而是从另一个角度来看待问题。

那说的容易,做的难,道理谁都懂,但怎么做

1 由于是框架来主导并生成语句,则表设计的时候,要考虑一个点,易读性也就是这个表最终对外提供的数据,是不是仅仅需要这一个表就能提供,还是需要几个表。

2 如果仅仅是需要这一个表提供数据,则这个表的数据量有多大,可以预估一下,一天大于多少,(不必要很准确,我经常听到的是,我也不知道数据量有多少,或者我不知道一天有多少数据量)其实我觉得听到这些声音的时候,让我有一种不大负责的感觉,因为一个表的使用者,或者设计者竟然不知道这个表要承载的数据,这不大让人能接受。(你自己都不清楚,你要别人怎么办)

3 如果是多表查询,则多表查询里面那些是基础表(因为多表查询或多或少符合了三范式),那些是业务表,或者哪里是记录表(流水账式的表)

4 根据上面 2 3 的问题,在各个击破,如果是单表,则要考虑是否有标有进行分区,或分库分表,在数据量较大的情况下,针对不同数据库的特点,以及架构进行,这时开发人员可能就需要介入 DBA 或者相关的人员来进行混合式的分析和相关的设定,专业的人做专业的事情。如果是多表的情况下,在分析出基础表,业务表,记录表等多种表是否需要混合查询后,会对表的设计进行重新规划,是否需要将数据进行冗余,避免太多表的关联,而数据的冗余就需要开发人员进行对程序的重新设计。

5 在设计时会有两种极端,1 将所有数据集中在一张表上,2 严格遵循三范式

这两种都不是好的设计,将所有数据都集中在一张表上,会让这张表变成热表,因为基础数据和业务数据在一起,无疑会将列数,行宽,以及行数都以倍数进行扩展。这样的结果就是,这张表会变得很大,并且锁会由于表访问的频度来增加,读失败和写失败的可能性,也就是我们俗称的锁。

而严格遵循三范式的表,在数据的DML 上将产生很多问题,在数据的写入时,是需要原子性的,如果将表拆的过散,则程序上会使用很多的锁,来保证数据到多个表的原子性,而这样的方式,也会产生,将数据写入一个表的产生的问题,产生大量的锁。

6无论是严格符合三范式,或者将表严格不符合三范式,都将产生的最终结果就是,表中的锁的增加,以及数据的访问和写入的困难增加。

举例,用户的地址信息

我们有以下设计方式

1 用户家庭地址,一个字段解决,内容是 XX省XX市XX镇XX路XX号XX层房间号

2 多个字段来解决

省市,市, 镇,村,路,号,层,门牌号

上面两种都不是好的设计方式,一个太粗,一个太细,直接导致的结果就是提取数据的时候,统计用户所在的省市有多少用户,这会遇到很多的麻烦,字符的分割,以及拼接,以及业务中各种应用场景,或者直接需要客户的详细地址。

好的方式可以是结合1 + 2 的方式,在表设计时,就将可以详细分类的省市,或者镇等信息分开存储,而在设计一个总体信息存储的字段。看上去这样会占用更多的存储空间,但一张表的信息的访问热度就会分散,统计会着重统计类的字段,省市,镇, 而功能性应用会去直接找到原始字段,进行输出。

当然还有另外一种方式的设计,就是将省市,镇单独存在一张表并给她们定义编码,而实际应用的时候,非功能+功能表 的方式来输出。这样的设计也有好处,就是大量的缩小的数据的存储空间,加速了提取数据的速度,试想我是对文字进行过滤快,还是对数字过滤快,对内存的占用低,对内存占用的低,则更有效的利用CPU,降低I/O交互。

当然这样的设计也是有缺点的,就是增加了表之间的 关联性,将单表访问变成多表访问,实际上我们只要变化思路,这样的方式还可以进行优化,当然需要更多的数据库的进入,各分其责。

其实表设计,牵扯的到的事情很多,甚至包括了硬件的部分,一个好的系统的设计是缺少不了,表的设计,以及相关架构的设计,而不好的设计,将让你的系统后期的维护成本和故障率都越来越高。

所以设计表时是要符合三范式还是不严格遵守三范式,根据业务逻辑大部分情况可能会选择后者。

注:什么是三范式

1F 指定表中的每个单元格只能有一个值,而不能有值列表.

2F 要求每个属性都必须完全依赖于整个主键。这意味着每个属性应该直接依赖于主键,而不是通过其他属性间接地依赖于主键。

3F 规则增加了一个要求,即每个非键列独立于每个其他列。如果在一个非键列中更改一个值会导致另一个值更改,则该表不符合第三种范式

本文分享自微信公众号 - AustinDatabases(AustinDatabases),作者:carol11

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-02-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 征信上报系统的渐进思路

    公司最近在研究怎么将CMS 系统中的征信上报的功能,拆分出来。原来的系统在ORACLE 数据库中,每次需要通过存储过程进行数据的生成在同步到征信上报系统中。

    AustinDatabases
  • PostgreSQL 烤面包的味道好极了 TOAST

    在传统的数据库中,DBA最恨 听到的词就是,我要使用 BLOB 字段,或者类似的类型来处理,huge的数据,他可能是一段图形的在转换后的“乱码”,也可能是某个...

    AustinDatabases
  • MONGODB 嵌套数组更新 与 设计

    (注:最近我发现MONGODB 的文字,大家好像不大感兴趣,不知道是大家的公司不使用MONGBDB 还是由于MONGODB 太稳定,所以就忽略了,其实MONG...

    AustinDatabases
  • 不用代码也可以采集到高质量网页数据!

    最近浙江省新高中信息技术教材将VB语言替换成python,并且使用「Python/Matplotlib/Pandas」组合作为高中计算机高考内容,这个引起了使用...

    沉默的白面书生
  • 也来聊聊 HTTPS.

    前言: 网上聊 HTTPS 的文章已经数都数不过来了吧,厚着脸皮,整理下读书笔记,结合平常项目的实践,也来聊聊 HTTPS。

    JMCui
  • 黑客最想要的礼物!看完我眼红了 你呢?

    有个黑客朋友(其实在做安全)马上要过生日了,问他想要什么礼物,然后,他丢给了我上面这张图,留言“看着图买”。

    闫小林
  • 使用xcopy向远程复制新增文件

    用户2657851
  • 再议EOS众筹的死循环

    昨天写了《PRS众筹对EOS和币市是利好,但作用不大》发表在猫友圈,和圈友有了很多讨论,对EOS的众筹逻辑有了更深入的思考。再写一文,与大家共...

    凌帅出口
  • Redis 4.0 PSYNC2中second_replid_offset探究

    Redis 4.0起引入了PSYNC2同步方式,分析源码时我们注意到,server数据中增加了replid2、second_replid_offset两个成员。...

    廖可知
  • R语言数据地图——全球填色地图

    今天这篇是昨天美国地图的续篇,同样的方法技巧,不同的对象。 整个过程以及代码并没有太大差别,只要拿到世界地图素材,根据之前的代码,自己修改参数和指标名称以及引用...

    数据小磨坊

扫码关注云+社区

领取腾讯云代金券