7
实际工作中数据库表设计会遵循范式吗？
source link: https://www.v2ex.com/t/785947
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
大家在实际工作中的表设计，会遵循《数据库系统概念》中提到的各种范式吗？比如第二范式、BC 范式等？ 我先说说我自己的情况，我自己在工作中基本没有特别地遵守其中的各种范式去设计表。我自己认为原因有两点： 1.大学时关于这块确实学习地不是特别深入，久而久之也就忘的差不多了，这块内容也是最近重新捡起《数据库系统概念》学习时才回忆起的，所以工作中完全没有考虑过相关概念（说白了就是人菜）。 2.感觉如果按照各种范式设计表结构的话会对业务的开发实现增加许多困难。 不知道各位大佬在实际中是怎么样的，想结合理论知识与实际经验学习一下。
39 条回复 • 2021-06-29 01:49:09 +08:00
xuanbg 2 天前 
2
范式 1 、2 、3 都是自然范式，也就是天然的、天经地义的，根据关系逻辑能够轻易推导得到的，不用学都会的。如果这 3 条范式都需要特别去学习才能理解 /运用的话。。。怕是逻辑思维能力有点捉急啊。趁年轻，赶紧转行。
shyrock 2 天前
1.适用 RDB 的场景是要求数据强一致，且对并发要求没有高到双十一抢购这种级别。
2.既然使用了 RDB，就应该熟悉关系设计范式，并且主动运用到设计中，这能有效减少数据冗余和数据不一致问题。
3.实际应用中，会遇到为了提高性能等需求而增加冗余的情况，但是这跟优先满足范式的原则不冲突。
2.既然使用了 RDB，就应该熟悉关系设计范式，并且主动运用到设计中，这能有效减少数据冗余和数据不一致问题。
3.实际应用中，会遇到为了提高性能等需求而增加冗余的情况，但是这跟优先满足范式的原则不冲突。
xuanbg 2 天前
@NeroKamin 第一范式（ 1NF ）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
证件号码和证件类型显然是两个属性，所以并没有违反。倒是譬如一个字段存一个集合或对象，确实是不符合“每一列都是不可分割的基本数据项”的。我认为这一点是过于理想化的，并不需要遵循。只需要遵循“同一个表不能有重复的属性”这一点就好了。
证件号码和证件类型显然是两个属性，所以并没有违反。倒是譬如一个字段存一个集合或对象，确实是不符合“每一列都是不可分割的基本数据项”的。我认为这一点是过于理想化的，并不需要遵循。只需要遵循“同一个表不能有重复的属性”这一点就好了。
xuanbg 2 天前 2
说到这里了，索性多说几句。关于数据模型的设计，任何一本书上都没有提到的，但非常非常重要的一点：准确识别业务对象。反过来就是需要把对象属性进行准确的归属。要做到这一点其实并不容易，需要对业务有深入的理解才行。
其实这一点也应该是产品经理的基本能力。所以，数据模型其实应该由产品经理来设计而非程序员。现在产品经理不干这事，就造成了这么几个问题：
1 、逻辑无法闭环，程序员在设计的时候发现产品到处都是漏洞，甚至很多自相矛盾的操作。
2 、数据缺失，编程过程中才发现某些功能所需要的数据缺失了，这些数据不知道是什么样，更不知道要从哪里来。
3 、功能缺失，产品都干出来了，到测试的时候发现跑不通，少了一些功能，进入某些场景就进行不下去了。
这么一来，产品和程序的对立也就不难理解了。
其实这一点也应该是产品经理的基本能力。所以，数据模型其实应该由产品经理来设计而非程序员。现在产品经理不干这事，就造成了这么几个问题：
1 、逻辑无法闭环，程序员在设计的时候发现产品到处都是漏洞，甚至很多自相矛盾的操作。
2 、数据缺失，编程过程中才发现某些功能所需要的数据缺失了，这些数据不知道是什么样，更不知道要从哪里来。
3 、功能缺失，产品都干出来了，到测试的时候发现跑不通，少了一些功能，进入某些场景就进行不下去了。
这么一来，产品和程序的对立也就不难理解了。
snw 1 天前 via Android
用 Excel 数据模型时被坑过，一开始尽量按范式设计成关系表，结果 Power Pivot 经常遇到性能问题。后来发现大表在大部分情况下性能更好些，于是以后就尽量拼大表了。
zpf124 1 天前 1
数据库三范式 和 xhtml 一样， 是一种追求严谨的设计思想，希望的是人类去匹配机器的结构，毕竟机器是死的所以要人去绝对优化尽量发挥 100%机器性能的。
这种思路希望一个东西从设计到开发全部都是绝对理性绝对归纳的，业务变化之后依旧不要破坏当前结构，而是要重新梳理重新归纳，修改为新的绝对严谨规范的设计进行重构。
然而现实就是人都是懒的，而且科技发展使得计算机成本降低，技术的门槛也降到了大多数人都可以掌握了，但普罗大众的平均技术水平并无法与计算机新兴时期的顶尖行业精英群体比较，对极致性能利用的追求也逐渐优先级低于了对开发便利性的需求，所以 html5 和数据冗余干掉了 xhtml 和各种数据库范式。
这种思路希望一个东西从设计到开发全部都是绝对理性绝对归纳的，业务变化之后依旧不要破坏当前结构，而是要重新梳理重新归纳，修改为新的绝对严谨规范的设计进行重构。
然而现实就是人都是懒的，而且科技发展使得计算机成本降低，技术的门槛也降到了大多数人都可以掌握了，但普罗大众的平均技术水平并无法与计算机新兴时期的顶尖行业精英群体比较，对极致性能利用的追求也逐渐优先级低于了对开发便利性的需求，所以 html5 和数据冗余干掉了 xhtml 和各种数据库范式。
siyemiaokube 1 天前 via iPhone 1
数据库的范式不是从业务层面或效率层面出发的，而是从关系代数的描述能力出发的。
在为数据的增删查改提供 api 的时候，怎样的 api 才是必然足够的、拥有足够强的描述能力、必然无需后续再进行增加？关系代数给出了一个答案。（过强的描述能力也带来了安全性的问题）
但是，关系代数本身并未约束 table 的具体形式，我们容易意识到，把所有 table 自然连接成一个大表的话，会带来很多问题，教科书上对这些问题有足够的描述。我个人的概括是，这些问题要归咎于关系型数据库无法（完全）支持 lazy 特性。
那么，一个可以稍微弥补的方法，就是通过数据库的范式，约定好表的格式，从而间接地，对于一定的调用，我们可以一次性完成所需的操作，而不用对自然链接后的大 table 逐条执行。
但是，如果我们可以从业务层面确认，上述情况不会出现，或者出现的频率相比而言较低，把表细致的拆分就是不经济的。
在为数据的增删查改提供 api 的时候，怎样的 api 才是必然足够的、拥有足够强的描述能力、必然无需后续再进行增加？关系代数给出了一个答案。（过强的描述能力也带来了安全性的问题）
但是，关系代数本身并未约束 table 的具体形式，我们容易意识到，把所有 table 自然连接成一个大表的话，会带来很多问题，教科书上对这些问题有足够的描述。我个人的概括是，这些问题要归咎于关系型数据库无法（完全）支持 lazy 特性。
那么，一个可以稍微弥补的方法，就是通过数据库的范式，约定好表的格式，从而间接地，对于一定的调用，我们可以一次性完成所需的操作，而不用对自然链接后的大 table 逐条执行。
但是，如果我们可以从业务层面确认，上述情况不会出现，或者出现的频率相比而言较低，把表细致的拆分就是不经济的。
chensuixiang 22 小时 6 分钟前
@xuanbg 现实中要是碰到你这样的人，我一句话都不想和你说。要么别回复，要么就好好说话，别一边回复一遍说人这不行那不行的。你自己厉害就厉害呗，干啥非得说别人不行，还特么扯到劝人转行上。
VIVVACI 15 小时 43 分钟前 3
@xuanbg 我想知道你到底是在那个厂上班的。这些结论感觉非常的脱离实际，一股浓郁的学术气。范式的目的减少数据冗余等，但是当你处理大量数据的时候，时间才是瓶颈。
几个 partition 里存的东西一样十分正常，因为逻辑代码就是 date={$date}，我直接去这个分片里找，为什么要把这个字段交给浪费时间的 where 。
这个表在时时访问我为什么不把两天的数据分别存到两个分片里，添加到同一个分片不怕对业务逻辑产生影响吗。
两个表 join 才能得到的结果，但是用到的频率相当高，我为什么不存在同一个表中。
数据中台产出的表都是有明确的业务场景的。这个表的目的是什么，说实话在项目建立的时候就出来了，RD 有资格不和 PM 沟通直接让 OP 建表吗？冗余字段不就是为了如果后续有升级的需求可以在新表上线之前做一个缓冲吗？
这就是我讨厌学术圈的一点，各个方向都在纸上谈兵，AI 领域尤其是重灾区。现在看来数据库也要沦陷了？
几个 partition 里存的东西一样十分正常，因为逻辑代码就是 date={$date}，我直接去这个分片里找，为什么要把这个字段交给浪费时间的 where 。
这个表在时时访问我为什么不把两天的数据分别存到两个分片里，添加到同一个分片不怕对业务逻辑产生影响吗。
两个表 join 才能得到的结果，但是用到的频率相当高，我为什么不存在同一个表中。
数据中台产出的表都是有明确的业务场景的。这个表的目的是什么，说实话在项目建立的时候就出来了，RD 有资格不和 PM 沟通直接让 OP 建表吗？冗余字段不就是为了如果后续有升级的需求可以在新表上线之前做一个缓冲吗？
这就是我讨厌学术圈的一点，各个方向都在纸上谈兵，AI 领域尤其是重灾区。现在看来数据库也要沦陷了？
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK