我不确定这个例子的最佳路线:
保存工作信息的表；薪水、就业日期等。我想知道如何最好地存储的字段是“job_title”。
- 职位名称将用作自动完成字段的一部分，因此 我将使用查询来获取结果。
- 数据库中的多个作业将使用相同的职位。
- 职位将成为许多查询的重要组成部分 申请。
- 一份工作只有一个头衔。
1 。我是否应该有 2 个表，job 和 job_title，job 表引用 job_title 表的名称。
2。我是否应该有 2 个表，job 和 job_title 但将 title 存储为 job 中的直接值，job_title 只存储所有预先存在的值的列表(有些多余)？
3。或者我根本不应该使用引用表/其他建议。
在这种情况下，您的设计选择是什么？它在一对多设计中会如何变化？
这是一个示例，实际设计要大得多，但我认为这很好地传达了这个问题。
更新，澄清:
一个用户(在问题范围之外)有很多工作，一个工作(开始/结束日期，{job title})有一个标题，标题(名称(即'Web Developer')
最佳答案
您的选项 1 是最佳设计选择。按照这些行创建两个表:
- 工作(job_id PK，title_id FK 不为空，start_date，end_date，...)
- job_titles (title_id PK, title)
PK 应该有聚簇索引； jobs.title_id 和 job_titles 应该有非聚集索引或二级索引； job_titles.title 应该有一个唯一的约束。
此关系可以建模为一对一或一对多(一个职位，多个职位)。要强制执行一对一建模，请对 jobs.title_id 应用唯一约束。但是，您不应该将其建模为一对一关系，因为它不是。您甚至自己这样说:“同一个职位将被数据库中的多个职位使用”和“一个职位只有一个职位”。 jobs 表中的条目表示某个用户在某个时间段内担任的某个职位。因为这是一对多关系，所以单独的表是对数据建模的正确方法。
这里有一个简单的例子来说明为什么会这样。贵公司只有一名 CEO，但如果现任 CEO 下台，董事会任命新 CEO 会怎样？您将在工作中有两个条目，它们都引用相同的标题，即使只有一个 CEO“职位”并且两个用户的工作日期范围不重叠。如果强制执行一对一关系，则无法对此数据建模。
为什么要使用这些特定的索引和约束？
- 出于显而易见的原因，ID 列是主键和聚簇索引；您将这些用于连接
- jobs.title_id 是一个 FK，希望是出于明显的数据完整性原因
- jobs.title_id 不为空，因为每个工作都应该有一个标题
- jobs.title_id 需要一个索引以加速连接
- job_titles.title 有一个索引，因为您已经表明您将基于此列进行查询(尽管我不会以这种方式进行查询，尤其是因为您已经说过会有很多职位；见下文)
- job_titles.title 具有唯一约束，因为没有理由重复相同的职位。您可以(并且将会)有多个职位名称相同，但您不需要在 job_titles 中为“CEO”添加两个条目。实现这种唯一性将保持对报告目的有用的数据完整性(例如，根据“网络开发人员”职位的填补情况绘制 IT 网络部门的生产力)
备注:
Job title is going to be used as part of an auto-complete field so I'll be using a query to fetch results.
正如我之前提到的，这里使用键值对。将它们的列表获取到您应用程序的内存中，并查询该列表以获取您的自动完成值。然后将 ID 发送到数据库以进行实际的 SQL 查询。查询将以这种方式执行得更好；即使使用索引，搜索整数通常也比搜索字符串更快。
You've said that titles will be user created .实现一些输入清理和验证过程，因为您不希望出现诸如“WEB DEVELOPER”、“web developer”、“web developer”等冗余条目。验证应该在应用程序和数据库级别同时进行；唯一约束是其中的一部分(但全部)。 Prodigitalson's remark about separate machine and display columns 与此问题有关。
关于mysql - 一对一单列表的DB设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28171722/