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

时间:2017-12-31 01:52:05

标签: mysql sql sql-server postgresql

我希望为技能和教育细节整理一个矩阵。我有专栏:

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,但我并不特别偏爱任何一个数据库平台。

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

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

2 个答案:

答案 0 :(得分:2)

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

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

答案 1 :(得分:0)

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

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

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

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