设计数据库表结构必须遵从 3 范式吗? 我感觉字段冗余更好用呀？冗余的字段也不超过 10 个

[kikione]

[RainCats]

范式就是拿来打破的，冗余看情况

[aristotll]

一般第二范式就好了。冗余看业务场景

[pendulum]

个人项目喜欢 BCNF ，其他的随意

[iseki]

你想好万一出现修改该怎么办就好

[chenxytw]

看实际情况。最最常见的不遵守范式的理由就是更在意性能吞吐。

[iseki]

能不打破就别打破，但有时候也没办法

[NCry]

我的看法是只要你明确知道自己为什么需要冗余字段，并且考虑到了可能带来的问题，那么就可以不遵循。

[dobelee]

是范式，不是规范，更不是规定。实际情况大把冗余和快照以避免连表。

[Chad0000]

想想微服务，数据更冗余了

[falsemask]

可千万别，接手的一个项目完全按照第三范式规则来的，A-B-C-D-E-F ，从左到右都是一对多的映射，都是用一个 id 对应，到了 F 表，完全看不出来对应的 A 表的字段是啥了，每次查个数据，血压都高了

[elboble]

来 v2 时间不长，知道的月经讨论有两个，
sql 要不要物理外键，
http 除了 get,post 其他行为能不能用，

是否遵守范式可以算第三个吧。

[Chad0000]

@elboble 还有 win/mac android/iOS ，感觉这个都属于周经了。

[LLaMA2]

请先设计好数据结构，有了好的数据结构，ORM 会自动生成你想要的数据库，当然，性能问题可能不好，
但是有数据结构，代码写的飞起，根本不在乎数据库里叫什么，怎么存的。
要是用 typescript 的 typeorm 。连 hibernat 里恶心的 nested object mapper 问题都没了。那开发速度更进一部，这样，你就有时间做自己想做的事情了

[kingjpa]

对于大厂为了性能，肯定能遵守最好了啊
对于我们外包仔，null text like 满天飞，
交付了事，规矩多就是给自己找不自在

[glovebx]

适当冗余，用空间换效率很划算

[westoy]

抛开业务类型和规模谈这个没意义啊

[melkor]

@falsemask 写个类把这逻辑都封装起来呀

[xuanbg]

可以冗余的当然就要冗余，不然什么都联表查询效率就太低了。

[huyi23]

能冗余尽量冗余，一切为了不连表

[huyi23]

@huyi23 有一个前提，当前值基本不存在更新操作