表设计与“馄饨”理论 想作为一个问题来讨论

其实是写错了，应该是混沌理论，不过大清早6:00在发这篇的时候，的确是饿了，见谅。

表设计的时候，大部分公司都是开发或相关的开发DBA 来进行设计，如果项目再大一点，架构师估计也要过问一下。那表设计到底为什么这么重要，而在经历了业务的时间迁移后，表的设计怎么就混沌了。

我说说自己得看法，首先表的设计并不简单，主要有以下几点

1 业务的变化，导致前期设计的表已经不适合当前的业务逻辑

2 多部门对数据库表的定义不同，例如有些部门有特殊需求，例如业务部门需要在业务系统中，去做大数据要做的事情，或者有些数据的变动太大，导致传统数据库RDS无法承受这样的业务

3 业务的变化太频繁，导致初期的表设计的还好，后边越来越乱，越来越和脱缰的野马一样。

我们这期先不说怎么解决，先说这些问题是怎么形成的，想想有不少同学都有共鸣。

1 业务的变化快，在表设计的初期，某个字段的表达状态可能只有2个，并且即使变换也不会很频繁，后期由于业务扩展达到10多个，状态会经常变动，这会导致什么，首先如果这个表是业务关键性的表，并且其他的表都会和这个表进行关联，那就很可能出现性能瓶颈。

为什么？一个表的每一行都有一个状态，而如果状态会经常变换，也就是说要经常进行UPDATE 的操作，那UPDATE 必然会在任何数据库产生X锁（当然这是锁的叫法是通用的叫法，每种数据库都有对X锁不同的定义和前期的一些相关锁）频繁的对一个HOT表进行UPDATE的操作，并且还要进行查询，这就为产生瓶颈种下的因果。系统的并发一大，不出问题是你"人品“太好，实际上老天爷是公平的，那会放过这样的设计。

这是一个问题

2  业务变化还是快，之前一个表的字段有10个，后期由于业务扩展在这个关键表上添加了20个字段，而查询的条件也由原来一个查询2-4个索引就可以解决问题，变化到 5-12个解决，并且这些条件大多是 = 等于的方式来做的，而数据库又是MYSQL 即使我们使用了dynamic的方式，一个表的索引行的大小也是有数量限制的，如果使用其他格式那一个表的索引行更小，怎么办？（建索引来加速查询的方式可能就会落空）

3  从ORACLE 迁移过来的表到MYSQL中，怎么弄，照搬过来的确是简单，并也未必不能运行，但就怕数据量大，数据量大了怎么办，现在有些单位ORACLE 到MYSQL 的数据库转移，数据库类型是转移了，看似也跟上业界的水平和发展的，可是换汤不换药的做法会让最后的结果很尴尬，MYSQL还要背上性能不优，太“刺” 的称号。所以ORACLE 到MYSQL 不是简单的更换的表字段的类型，将数据导入到MYSQL 就可以了，那是需要整体梳理逻辑，进行整体的系统的重新设计和优化，才可行的。（这也是为什么大多数单位的迁移都失败的原因，大领导不懂只看数据库类型换了，但实际上底下都是炸药包）。

4  表设计主键问题，其实在不同的系统中，主键对整体的表设计起到了关键性的作用，例如对查询的速度有要求，又都是等式查询的，但表的列太多怎么弄， 又或者数据写入量大，主键又怎么设计，能提高插入数据的速度，是有主键好，还是没主键好，在不同的数据库都有不同的定义，甚至有的数据库种类，直接告诉你，在某些表设计中，不要主键，利用其它的方式来代替。

5  关于默认值的问题，关于默认值的设计基本上都是在依仗开发来进行相关的默认值的设计，但实际上默认值的设置的问题会导致一些问题，例如默认值为'' 如果在转换的时候不注意，那很可能程序读取后，到另外的数据库去写入的时候就变成了 null， 这也是问题，如果给一个字母，这样的情况程序在展示的时候又有问题，程序要对这个字母进行转换，否则展示的时候没有值的情况下，显示值了，用户是不懂其中的奥秘的。

表设计中的问题可不仅仅是这几个，千奇百怪耐人寻味的问题太多，绝对不比开发的事情少，但问题是开发人家可以改代码，DBA 敢随便改表结构。所以前期的前瞻性，那是相当的重要，否则后面很多活多是在，填补漏洞，修修补补，甚至越修越糟糕。

最后，这样的问题就需要综合性的解决方法，需要数据库，架构，开发共同集思广益来在初期就避免某些问题的发生，预防后期的部分问题。

目前大部分DBA 的工作热情都在 硬件方面的架构，感觉考虑与软件开发的idea 越来越少，诚然有行业的因素，很多DBA 在软件开发中都插不上手，最后就变成，军规，各种硬件的架构， 但数据库工作者到底应该服务于谁，无论你是数据库的硬件，高可用架构， 数据库原理，数据库设计，统统的不都是在为你的应用服务，没有应用，要数据库干什么？

有兴趣研究的同学，可以加个群，里面进行讨论，共同提高，使整体DBA行业的重要性继续提高。