怎么可能设计一个可能靠谱的业务系统数据库（1 提出问题）

实际上大部分人尤其DB人员基本上，大部分是不会和设计业务系统的数据库又半毛钱的关系，主要的原因，在于不理解业务，或者在工作中根本就接触不到，有些公司本身是由开发人员自行设计业务表，有些是开发和DB人员共同设计，但实际上DB 人员的大部分工作范围在于，架构和规范类的设计，而非和业务有关的设计。

今天并不是要说一些和架构有关的设计，例如怎么分库分表，或者怎么利用某些数据库的特性，做继承表，分区表之类的东西，而是想从业务的角度来看看程序人员到底是一般是怎么设计一些业务表，To know one's own strength and the enemy's is the sure way to victory.

当然下面的思路完全是一个DB人员的视角来揣测开发人员的想法，所以一定有错误点，如果有，还请developers let me know, thanks.

从一个开发人员拿到需求后，以及在排除技术栈的选择后，基本上就要和业务逻辑进行相关的分析，并且按照相关的设计理念来设计数据库表，实际上有些开发人员是不大注意表的设计的，大部分人还是遵循了三范式，当然也有一些因为架构设计中，让某些业务逻辑屈从于技术栈，当然这还是少数，大部分还是技术要屈从于业务，尤其在传统企业。

数据表设计当中会有两个对立面

1  数据表中数据的冗余

2  数据库表中的数据一致性和准确性

这两个对立面分别面对这业务逻辑中的 ，基础表和业务表，基础表冗余是大概率的事情， 而业务表的数据库都是尽量避免冗余的。

可以考虑一下我这一样说有没有道理，一个公司的业务系统大概会模块化进行处理，例如订单进单系统，订单跟踪处理系统， 客户关系管理系统， 合同管理系统，财务系统， 客户系统，............. 

每个系统其实都可能和其他系统会公用一些基础信息， 订单系统中有订单号，订单跟踪处理系统有订单号， 客户管理系统中是不是也有每个客户下的订单号， 而订单跟踪处理系统到流程完毕后，可能就会有合同号，合同管理系统中也会有合同号。

一个系统和另一个关联系统中必然必须存在练习，而这个联系就和你的业务有关。

如果我在订单跟踪处理系统中生成了合同号，那后续将信息传输到合同管理系统中，通过和合同系统中共同的合同号，就可以将订单，或者多笔订单关联到一个或多个合同号中。

实际上这里的设计和业务息息相关，如果业务提到，一个订单必须只能有一个合同号，和多个订单可能只有一个合同号，在表设计上就会出现不同的复杂度。而这些复杂度就会影响后期数据库可能遭受的性能问题。

 

实际上着就是表设计中，有些设计当中程序员提出多个列作为主键的一个可能的原因，因为单列可能无法作为他标识出一个元祖（行），信息的定位。

此时如果我们是DB 人员，使用的是MYSQL数据库，你是按照开发人员的意思，在一对多的情况下，让他使用多列组合的主键，还是能给他提出点其他的意见，来尽量避免多列主键？

如果此时你仅仅告诉，他不行你必须按照数据库的规范，只能一个列作为主键，那.........

大多数的DB 人员本身可能大部分情况都是不行然后就没有然后，让开发自己想办法，解决问题。

另外在业务系统设计中，还存在冗余数据的一致性的问题， 例如业务系统都有一些基础信息表，每个业务系统都需要使用，那就存在多点写，和数据库表一致性的问题， 解决的方法也不少，单点写，然后通过数据库本身的功能进行信息的分发， 或者通过非数据库系统的方式，让程序方做大事务一次在多个业务系统中写入数据，在或者准备一个数据库系统，其他业务子系统直接在使用这些信息的时候来去查询这个数据库的表信息，这都是解决问题的方式方法。但到底哪种更好，哪种应该被使用那就不一定了。

如业务子系统多，并且这些基础信息频繁的被访问，并且还要这些信息在各个子系统中不能有半秒的数据不一致。那要用什么方式方法来解决。

在或者设计业务表，数据量比较大，那到底是根据三范式的方式来设计表，每个表中都不能有其他表中的字段信息，例如在设计一个表中分为实体和属性两类， 那如果一个实体的属性比较多，那就会造成一个表的列数很多，那到底要不要进行拆分将部分属性移除这张表，在另一张表中体现。

又或者在分库分表中，可以通过中间件将一部分表通过hash的手段打散，一部分数据库表则全部下发到每个物理的服务器，这样做的好处是什么，为什么这样设计？

另外根据业务中的业务逻辑，如  客户  店铺    销售  产品

客户实体和店铺实体有关系

客户实体和产品又实体关系

客户实体和销售实体有关系

甚至客户实体和客户实体本身有关系

店铺实体和销售实体有关系

店铺实体和客户实体有关系

店铺实体和产品实体有关系

产品实体和销售实体有关系

产品实体和客户实体有关系

产品实体和店铺实体有关系

产品实体和产品实体有关系（例如：产品的附属品）

销售实体和客户的关系

销售实体和店铺的关系

销售实体和产品的关系

销售实体和销售的关系  （代买的关系）

看似简单的四个实体，其实之间犹豫业务的复杂度，造成关系错综复杂，其中的业务逻辑也是层出不穷，到底客户， 店铺， 销售， 产品，这些表到底怎么设计，才能避免一些犹豫设计表时的问题（信息分的过于三范式），导致查询需要带有多个表join才能将信息捕获全，造成性能的问题。

所以一个系统设计好，数据库本体（数据库本身的架构）要设计的好，选择的对，而上层到底怎么设计出一个符合业务逻辑的，符合数据库操作原理的数据库表，才是更上一层楼的操作。