设计数据库表结构必须遵从 3 范式吗? 我感觉字段冗余更好用呀？冗余的字段也不超过 10 个
kikione · 2022-03-12 15:02:32 +08:00 · 3620 次点击这是一个创建于 768 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
RainCats 2022-03-12 15:03:23 +08:00
范式就是拿来打破的，冗余看情况
|
 |
2
aristotll 2022-03-12 15:06:27 +08:00
一般第二范式就好了。冗余看业务场景
|
 |
3
pendulum 2022-03-12 15:10:34 +08:00
个人项目喜欢 BCNF ，其他的随意
|
 |
4
iseki 2022-03-12 15:12:38 +08:00
你想好万一出现修改该怎么办就好
|
 |
5
chenxytw 2022-03-12 15:12:59 +08:00
看实际情况。最最常见的不遵守范式的理由就是更在意性能吞吐。
|
|
6
iseki 2022-03-12 15:19:35 +08:00
能不打破就别打破，但有时候也没办法
|
 |
7
NCry 2022-03-12 15:27:51 +08:00  1
我的看法是只要你明确知道自己为什么需要冗余字段，并且考虑到了可能带来的问题，那么就可以不遵循。
|
 |
8
dobelee 2022-03-12 15:30:44 +08:00 via iPhone
是范式，不是规范，更不是规定。实际情况大把冗余和快照以避免连表。
|
 |
9
Chad0000 2022-03-12 15:56:02 +08:00 via iPhone
想想微服务，数据更冗余了
|
 |
10
falsemask 2022-03-12 17:59:36 +08:00
可千万别，接手的一个项目完全按照第三范式规则来的，A-B-C-D-E-F ，从左到右都是一对多的映射，都是用一个 id 对应，到了 F 表，完全看不出来对应的 A 表的字段是啥了，每次查个数据，血压都高了
|
 |
11
elboble 2022-03-12 18:05:12 +08:00
来 v2 时间不长，知道的月经讨论有两个，
sql 要不要物理外键， http 除了 get,post 其他行为能不能用， 是否遵守范式可以算第三个吧。 |
 |
13
LLaMA2 2022-03-12 18:40:57 +08:00 1
请先设计好数据结构，有了好的数据结构，ORM 会自动生成你想要的数据库，当然，性能问题可能不好，
但是有数据结构，代码写的飞起，根本不在乎数据库里叫什么，怎么存的。 要是用 typescript 的 typeorm 。连 hibernat 里恶心的 nested object mapper 问题都没了。那开发速度更进一部，这样，你就有时间做自己想做的事情了 |
 |
14
kingjpa 2022-03-12 22:17:37 +08:00
对于大厂为了性能，肯定能遵守最好了啊
对于我们外包仔，null text like 满天飞， 交付了事，规矩多就是给自己找不自在 |
 |
15
glovebx 2022-03-12 22:19:21 +08:00
适当冗余，用空间换效率很划算
|
 |
16
westoy 2022-03-12 22:19:54 +08:00
抛开业务类型和规模谈这个没意义啊
|
 |
18
xuanbg 2022-03-12 23:48:12 +08:00
可以冗余的当然就要冗余，不然什么都联表查询效率就太低了。
|
 |
19
huyi23 2022-03-13 00:20:24 +08:00
能冗余尽量冗余，一切为了不连表
|
 |
22
IvanLi127 2022-03-13 08:16:24 +08:00 via Android
如果性能允许，尽量遵守咯。关联表查询不就是关系型数据库干的活么。要是很多字段都冗余，可以换文档型数据库了
|
 |
24
melkor 2022-03-13 13:21:53 +08:00 via iPhone
@falsemask 有数据库操作权限是危险的行为，所以压根不该直接进数据库查数据。如果为了查业务数据，应该有一层 ORM 把逻辑封装了，直接按对象查询；如果为了离线运营，应该把数据上报离线存储后重新组织成宽表。
|
 |
25
ychost 2022-03-13 14:21:13 +08:00
尽量不要 join 表，一旦多了维护起来真炒蛋
|
 |
26
andytao 2022-03-13 14:54:30 +08:00
范式太严谨，真的很讨厌，各种连接找数据；命名不规范直接降低效率；
|
Select Language