明天就要软考了，我发现了数据库三范式之第一范式好像过时了

是的，现在很多系统数据库的设计都是反范式的
三范式并不是一定要遵守，只是遵守但是能够帮你避免一些问题，但是可能会降低查询效率之类的
可以根据自己的需求来打破范式，但每打破一个范式，就要增加对应的处理方案，避免引入新的问题，比如数据结构教研，数据同步更新等等

@aes114514gcm #2 但是，MySQL 存 JSON 的场景也不少了。是个 SQL ，甚至 NoSQL ，只要能存长字符串的，都会有人存 JSON 。

pg 还有 array

居然有人说数据库范式没啥用
PS: 1981 的图灵奖就是颁发给研究数据库的，而数据库范式是其中很重要的一部分

三范式并不是不能违反的

范式没有万能的，具体还要根据你自己业务和上下游去决定。
但是你不能不学，不能不了解这些范式是为了解决什么问题产生的。试想一下，一张表里只有 id 和 data 俩字段，做业务时候一把 data select 出来，然后在程序中用代码逻辑组织数据结构或者进行过滤，光想想就灾难。

@airqj 但那是 1981 啊, 祖宗之法不可违?

先懂得规则，然后才能知道何时打破规则，代价是什么，收益是什么

是不是应该有个约束条件：在多大程度上是原子的，这就取决于业务需求了。

范式是思维模型，依据模型你就能知道你的设计如何取舍：应用便利、性能、扩展性等等。
没人说按照范式执行一定更好，都是权衡和取舍。

三范式属于用了不会错，但是不一定好
反范式一定是是有什么好处，但是可能会犯错，特别是为了偷懒反范式
只能说具体情况具体分析

纸上谈兵不代表兵法书籍是无用的

那么，古尔丹，代价是什么呢

实践和理论不冲突啊

@huangsijun17 当长字符串存跟用原生 JSON 支持是两码事。后者可以直接对 JSON 内容做检索和解析。

你在说啥，考试该怎么复习准备？

现代数据库 json 列提供了按 json path 更新值，甚至按 json path 索引，把 json 列当 join 表，其中的每个 json path 当作真正的列值就行了。
如果用字符串类型的列，强行存 json 序列化值，而不提供局部更新能力，才是违反范式。

原则 > 范式 = 风格

钱都交了，明天去裸考了，我是一道题都没刷

@dacapoday 有道理，但是 json 作为字段通常都是全部覆盖更新这个字段的吧（数据库层面），需要存储 json 字段的通常是一些配置项

@soleils 兄弟你是真 NB 。
我只是反驳人家说的数据库范式无用论，没有说数据库一定得遵循规范来设计吧？

@dushixiang 这是一种场景，而且该场景下，该列不参与索引和进入过滤条件，也就是非关系的 blob 附件，那自然也不受范式约束了。

@Bigstupidcat 补贴了解下

@Rickkkkkkk

这种看法片面了，也低估了范式与 REST 规范在复杂商业系统里的底层价值。
数据库三范式从来不是死板教条，而是帮开发者规避数据冗余、更新异常、删除错乱的基础设计准则，真正长期做商业系统的人都清楚，前期不守范式，后期多表联查、数据同步、业务迭代、对账统计都会频繁出隐性 BUG ，维护成本会成倍飙升。
RESTful 也同理，规范统一的接口设计，能降低跨团队协作、前后端对接、服务拆分重构的沟通损耗。
规范本身不是束缚，而是工业级开发的通用共识，只会觉得规范无用，大概率只做过小体量单体项目，没经历过业务膨胀、数据迭代、多人协作、系统拆分的真实场景，自然体会不到底层规范规避风险、降本增效的实际作用。

后天考，明儿还能突击一天

@hongye 但实际上，真正设计的时候并不会拿着这些东西来用。

恰恰是大规模的系统才不会去遵守这些协议，小的项目反而好实现

（你可以随便去看阿里腾讯这种大厂的任何一个组，设计的时候这些规范都不会出现的

因为业务需求或者性能考虑不遵守某些范式很正常，可以看下 DDIA 相关章节： https://ddia.vonng.com/ch3/#sec_datamodels_normalization

你说他没用，还是有用，你说他有用，它却没啥用，实际就是鸡肋

突然想起来我也报名了，一点没学

@Rickkkkkkk #38 恰巧我在交易中心工作过一段时间，应该是比较核心的系统了。方案评审的审核还是很关注库表设计的，DBA 会耳提面命的。

RESTFul JWT 中台 DDD 数据库三范式 有勇士凑齐了吗

@hongye 当然会注重 db 字段的设计，接口的设计也会考虑。

我的意思是，但这里并不会去通过范式、restful 这种规范来考虑。你会有印象在讨论设计合理性上，有人提过 db 范式吗？说实话我工作这么多年，几个大厂也呆过，从来没听过。

说到底远古时期算力和 io 都严重不足，只有遵守范式你这个系统才不会三天两头卡出屎，没有其他路可以走。。。
现在这年头处理器核心数跟个不要钱一样，存储的 io 和容量起码都翻了几万倍。。。
时代变了，现在遵守这东西和进机房要穿鞋套有啥两样。。。
真要考究到这些，那你也不会问这个了

不是过时了，是还有个相应的概念叫“反范式”，但更多实践上来说大概率是二者都沾一点，从“没有银弹”的角度来说，软件工程还是符合国人的“折中”的习性的

没看题 去年差 3 分 今年再试

看到你这个帖子我才发现忘记报名了

。。。。第一题就是这个

突然很忙，没有时间突击，准考证都没有打，贡献 190

关键字: mysql ，json 类型，虚拟字段

CREATE TABLE user_profile (
id INT PRIMARY KEY AUTO_INCREMENT,
info JSON NOT NULL, -- 原始 JSON 字段
-- 从 JSON 中提取字符串字段（虚拟列）
username VARCHAR(50) GENERATED ALWAYS AS (info->>'$.username') VIRTUAL,
-- 从 JSON 中提取数值字段（存储列）
age INT GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(info, '$.age'))) STORED,
-- 基于 JSON 数组的计算字段
hobby_count INT GENERATED ALWAYS AS (JSON_LENGTH(info->>'$.hobbies')) VIRTUAL
);

-- 为虚拟字段创建普通索引
CREATE INDEX idx_username ON user_profile(username);

-- 为存储字段创建唯一索引
CREATE UNIQUE INDEX idx_age_unique ON user_profile(age);


INSERT INTO user_profile(info) VALUES
('{"username":"zhangsan", "age":25, "hobbies":["reading", "coding"]}'),
('{"username":"lisi", "age":30, "hobbies":["travel", "photography"]}')

-- 直接查询虚拟字段，无需手动解析 JSON
SELECT id, username, age, hobby_count FROM user_profile;

-- 结合虚拟字段进行条件查询
SELECT * FROM user_profile WHERE age > 28;


神奇吧， 用了好几年乐，都用上瘾了， 上面的例子，大模型生成