基于三大范式设计数据库结构的矛盾体

一、简述

开发中必不可少的要与数据库打交道，那么优秀的数据库设计则显得尤其的重要。一个合理的数据库结构可以为当前开发及未来维护提供强有力的支撑。
什么样的数据库结构才能称得上优秀呢？个人的理解点是：

• 满足需求
• 性能与冗余（例：某需求，有一需频繁访问的查询功能，查表A时需通过关联ID访问B表的对应名称，那么是否可以将B表名称直接冗余到A表中，减少频繁的关联查询，增加查询语句的性能）
• 预见性扩展需求（例1：目前只需要的"地址"字段，是否有必要改为"国"+"省"+"市"+"区"+"详细地址"组合字样，以免后期需要根据区域统计分析业务；例2：未来可能的分库分表时的标识设置、sql关联等）
• 接近三大范式的理念

 

二、范式解析

说道数据库设计，很多人都会想到三大范式。这里我要说的是：三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库；特殊情况要特殊对待，数据库设计最重要的是看需求及性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。

（先理解下，数据库的"行"通常表示一个对象，"列"表示对象的属性）
我们先来回顾一下三大范式，书面的术语就不复述，白话性的讲述下：

范式一："列"原子性

即：不要1列对应多个属性；且不要出现重复列属性

 

范式二：属性要依赖于"完全"主键

 

范式三：属性要直接依赖于主键，不要间接依赖

 

三、设计矛盾体

a、如上：范式二与范式三的区别，若有很多店铺或涉及店铺业务时，需要展示店铺对应站点的文字描述，我们直接将站点名称冗余到店铺表中，采用范式二何尝不可？可以减少频繁的关联查询。

b、扩展：例如，现在店铺只有阿里巴巴的平台，但是可以预见的是马上要多平台的运营，什么亚马逊、eBay等等都会开设店铺。那么我们怎么区分店铺是属于哪个平台呢？事先加入platform_code字段标识平台也是很方便的。

 

冗余：

为什么我老是拿冗余字段和扩展冗余来说事呢，结合上面两点：
a、假设现在有1000个平台店铺，每个店铺每天销售出100个订单，那订单表每天就会有10万的数据生成。要不了多久，这个表就扛不住了，那咋办呢？按平台分表吧！之前的扩展冗余是不是就起到作用了？！
a、随着公司的发展，我们可能慢慢就会有物流系统、仓库系统、店铺数据中心、订单系统等等平台，然后自然而然的要进行分库，部分库中的数据就靠定时任务或者触发同步数据了。
现在站点、店铺分成了两个系统，在不同的库里了，那链接查询还方便吗？此时字段冗余是不是又给你解决了问题？！

注：开发中尽量的单表操作，业务关联能上java交互的上java交互，可以为系统的后期减少很多麻烦事！ZZZ...内容是不是跑偏了？