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