实际工作中数据库表设计会遵循范式吗？

不会。 但是都是有原因的，你需要清楚 为什么。

大体上就两个方面的因素，研发成本 性能瓶颈

需求更, 性能, 成本 都可能破式。

多工作年你一定遇到。

大多数情况下遵循范式，特殊情况会冗余数据。当然冗余必须有正当的理由。

不太可能完全遵循范式，冗余啊什么的

范式 1 、2 、3 都是自然范式，也就是天然的、天经地义的，根据关系逻辑能够轻易推导得到的，不用学都会的。如果这 3 条范式都需要特别去学习才能理解 /运用的话。。。怕是逻辑思维能力有点捉急啊。趁年轻，赶紧转行。

不会, 第一范式都会违反. 一个数据库字段里面放上二三十个不需要索引查的那种扩展字段.

@xuanbg 你说话是真难听，别人正常问个问题，扯什么智商，转行？

数据库表设计的规则是单纯从数据库层面考虑的，但实际应用中数据库只是我们整个系统的一部分，数据库范式有时并不能为系统带来好处，不要过度追求

当然不会

就说提出这个概念的人应该是没有接触过大规模业务场景的

提出的东西很多时候脱离实际场景, 参考就好

想想这些泛式什么的理论提出来时候的时代背景和互联网业务的规模就知道这些范式根本不适合用在目前的互联网开发方式上。

建议看看范式产生的时代背景，那时候的主要诉求和现在有大不同
不用盲目遵循，首先还是要看你是否需要

@xuanbg #5 天然？空间换时间的情况不是很多吗？

1.适用 RDB 的场景是要求数据强一致，且对并发要求没有高到双十一抢购这种级别。
2.既然使用了 RDB，就应该熟悉关系设计范式，并且主动运用到设计中，这能有效减少数据冗余和数据不一致问题。
3.实际应用中，会遇到为了提高性能等需求而增加冗余的情况，但是这跟优先满足范式的原则不冲突。

并不会，冗余字段多的很

大方向是遵守的

读《 SQL 反模式》
https://zhuanlan.zhihu.com/p/37534634

数据库第一二三范式到底在说什么
https://zhuanlan.zhihu.com/p/20028672

@xuanbg 素质修养有待提高

ER 图转换关系模型什么的我觉得挺好用，范式这个就要看情况了，没有主动去弄过，大概数据量太少吧

@huntcool001 第一范式怎么违反？？

当然主要看性能

@l00t 第一范式违反的话，我看到过一个银行数据库的，一个字段里面存了各种证件号码（身份证、护照等等），但是有另一个字段做类型区分，不知道算不算

@destinism
@Saurichthys

逻辑思维能力差不是很正常的事情吗？怎么就难听了了？吃编程这碗饭这个能力不可或缺，但搞艺术创作这个能力就没半点用处。

@NeroKamin 第一范式（ 1NF ）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
证件号码和证件类型显然是两个属性，所以并没有违反。倒是譬如一个字段存一个集合或对象，确实是不符合“每一列都是不可分割的基本数据项”的。我认为这一点是过于理想化的，并不需要遵循。只需要遵循“同一个表不能有重复的属性”这一点就好了。

@beichenhpy 一个理想数据模型，必然是符合 3 范式的，所以说 3 范式是天然的。

我说的是理想数据模型，不考虑任何使用场景，仅仅是对业务对象的结构化描述。

说到这里了，索性多说几句。关于数据模型的设计，任何一本书上都没有提到的，但非常非常重要的一点：准确识别业务对象。反过来就是需要把对象属性进行准确的归属。要做到这一点其实并不容易，需要对业务有深入的理解才行。

其实这一点也应该是产品经理的基本能力。所以，数据模型其实应该由产品经理来设计而非程序员。现在产品经理不干这事，就造成了这么几个问题：
1 、逻辑无法闭环，程序员在设计的时候发现产品到处都是漏洞，甚至很多自相矛盾的操作。
2 、数据缺失，编程过程中才发现某些功能所需要的数据缺失了，这些数据不知道是什么样，更不知道要从哪里来。
3 、功能缺失，产品都干出来了，到测试的时候发现跑不通，少了一些功能，进入某些场景就进行不下去了。

这么一来，产品和程序的对立也就不难理解了。

遵守，当然部分时候会有特例情况。遵守起来不是什么难事。当时学到这的时候才知道自己之前设计的数据库原来如此还遵守着范式

用 Excel 数据模型时被坑过，一开始尽量按范式设计成关系表，结果 Power Pivot 经常遇到性能问题。后来发现大表在大部分情况下性能更好些，于是以后就尽量拼大表了。

@xuanbg 所以我说我回忆起各种范式的定义后，发现工作中的表设计没有完全遵守范式，是怎样让你推导出我逻辑思维能力不行的呢？

数据库三范式 和 xhtml 一样， 是一种追求严谨的设计思想，希望的是人类去匹配机器的结构，毕竟机器是死的所以要人去绝对优化尽量发挥 100%机器性能的。

这种思路希望一个东西从设计到开发全部都是绝对理性绝对归纳的，业务变化之后依旧不要破坏当前结构，而是要重新梳理重新归纳，修改为新的绝对严谨规范的设计进行重构。

然而现实就是人都是懒的，而且科技发展使得计算机成本降低，技术的门槛也降到了大多数人都可以掌握了，但普罗大众的平均技术水平并无法与计算机新兴时期的顶尖行业精英群体比较，对极致性能利用的追求也逐渐优先级低于了对开发便利性的需求，所以 html5 和数据冗余干掉了 xhtml 和各种数据库范式。

数据库的范式不是从业务层面或效率层面出发的，而是从关系代数的描述能力出发的。

在为数据的增删查改提供 api 的时候，怎样的 api 才是必然足够的、拥有足够强的描述能力、必然无需后续再进行增加？关系代数给出了一个答案。（过强的描述能力也带来了安全性的问题）

但是，关系代数本身并未约束 table 的具体形式，我们容易意识到，把所有 table 自然连接成一个大表的话，会带来很多问题，教科书上对这些问题有足够的描述。我个人的概括是，这些问题要归咎于关系型数据库无法（完全）支持 lazy 特性。

那么，一个可以稍微弥补的方法，就是通过数据库的范式，约定好表的格式，从而间接地，对于一定的调用，我们可以一次性完成所需的操作，而不用对自然链接后的大 table 逐条执行。

但是，如果我们可以从业务层面确认，上述情况不会出现，或者出现的频率相比而言较低，把表细致的拆分就是不经济的。

@l00t
> 第一范式怎么违反？？

比如表的一项是个字符串，里面储存了多种 tag

@charlie21 感谢，摸鱼看

@xuanbg 现实中要是碰到你这样的人，我一句话都不想和你说。要么别回复，要么就好好说话，别一边回复一遍说人这不行那不行的。你自己厉害就厉害呗，干啥非得说别人不行，还特么扯到劝人转行上。

@xuanbg 你的确是个狗东西， 不知道现实怎么窝囊遭不能发泄。 要网上无缘无故的阴阳怪气的怼别人。

@xuanbg 我想知道你到底是在那个厂上班的。这些结论感觉非常的脱离实际，一股浓郁的学术气。范式的目的减少数据冗余等，但是当你处理大量数据的时候，时间才是瓶颈。
几个 partition 里存的东西一样十分正常，因为逻辑代码就是 date={$date}，我直接去这个分片里找，为什么要把这个字段交给浪费时间的 where 。
这个表在时时访问我为什么不把两天的数据分别存到两个分片里，添加到同一个分片不怕对业务逻辑产生影响吗。
两个表 join 才能得到的结果，但是用到的频率相当高，我为什么不存在同一个表中。
数据中台产出的表都是有明确的业务场景的。这个表的目的是什么，说实话在项目建立的时候就出来了，RD 有资格不和 PM 沟通直接让 P 建表吗？冗余字段不就是为了如果后续有升级的需求可以在新表上线之前做一个缓冲吗？
这就是我讨厌学术圈的一点，各个方向都在纸上谈兵，AI 领域尤其是重灾区。现在看来数据库也要沦陷了？

@VIVVACI date='${date}'

一般不会，原因是时间和成本的问题。

@VIVVACI 没错，生产是生产，学术是学术，生产讲究的是用最短的时间，得到最多的金钱产出，这才叫生产。

@seesky "狗东西"这个词怎么有点肉麻的感觉……

@VIVVACI 我一直说的是用关系代数描述的“数据模型”，哪里有说建表了？

还有某些人，自己脑补出来智商低，我也是无语。看我不爽，来咬我啊。

至于在实际中如何应用理论，我只能说要从实际出发。既不能唯理论纸上谈兵，也不能没有理论指导胡搞瞎搞。这种大家都懂，但总是做不好的废话了。。。其实 1 楼就说的很好，为什么不按范式设计，只要自己清楚就行。

《数据库系统概念》---这书中的范式有几条是经过实际生产而得出的？

@xuanbg 楼主问的是实际业务中的经验，我们应该讨论的是有没有遵循范式和遵不遵循的理由、实际生产中这么做的意义。你没有给出合理的相关解释而是站在学术的角度，站在一种奇怪的制高点上去抨击不遵循范式的人。这不是好的回答和讨论应该有的状态。你可以看一下在你的第一条回应中有多么的咄咄逼人。而我从你后续回答中，感觉你劝人转行的同时，似乎自身并不在行中。

实际工作不会，因为有的时候不遵循范式会更有效率。