数据库设计最佳实践:返回带有单个条目的多行,或带有多个条目的单行?

问题描述 投票:0回答:2

我正在寻找一个技能和教育细节的矩阵。我会有专栏:

skills_mat_id | user_id | skill | competency_level | priority_level |

和教育类似的东西,其中competency_level和priority_level在论坛中可以为空(或DB中为NULL)。

问题是我应该为每种技能创建一个单独的行条目,即:

1, user1, java, 7, 1
2, user1, php, 6, 2
3, user1, css, 4, 2
4, user1, python, 8, NULL

或者我应该在同一列中包含所有内容:

1|user1|java,php,css,python|7,6,4,8|1,2,2,NULL

我觉得第一个选项更容易实现(并且由于NULL /空字段而不太容易出现前端错误),但第二个选项看起来更“高效”并且会返回单行以查找可能的内容一大堆技能。两种选择都会对性能产生影响吗?这更像是一个前端问题吗?或者设计决策是否会对数据库性能产生重大影响。我将使用MySQL,但我并不特别偏爱任何一个数据库平台。

我有点担心用第二个选项更新或删除特定技能。我不太确定如何以减少意外删除或更新记录错误部分的机会来解决这个问题。

我们正在考虑可能拥有成千上万的用户,这些用户会大大增加“技能”或“教育”表格,因此想知道这样的数据集是否有最佳实践方法?

mysql sql sql-server postgresql
2个回答
2
投票

针对单行读取与多行的优化在过早的微优化领域中非常深入。如果您通过skill_mat_id + user_id对表进行索引,则这些列的选择应该非常快。性能甚至不应该成为一个问题。另一方面,如果以逗号格式存储它,则很难维护,容易出错,并且在任何情况下,前端都需要完成将每个技能名称与熟练程度合并的工作。始终使其首先工作,设计模块化和优雅,然后只在需要时优化性能。

如果您绝对需要这种性能,那么对它进行基准测试,看看额外的提升是否值得。在大型计划中,它很可能不是。


0
投票

从简单的角度来看,多行更好。

否则,您需要在每个字段附近循环。

另外,你节省了什么?不多。如果你输入几行,你将获得不错的空间节省。如果你输入几百,你将从zip工具获得更好的压缩。

代码简单,因此更容易调试。

© www.soinside.com 2019 - 2024. All rights reserved.