我不确定这个例子的最佳路线：
保存工作信息的表格;工资、就业日期等。我想知道如何最好地存储的字段是"job_title"。
- 职务将用作自动完成字段的一部分，因此我将使用查询来获取结果。
- 数据库中的多个作业将使用相同的作业名称。
- 职称将成为许多查询的重要组成部分应用。
- 单个作业只有一个标题。
1 .我应该有一个 2 个表，作业和job_title，作业表引用job_title表的名称。
阿拉伯数字。我是否应该有一个 2 个表，作业和job_title但将标题存储为作业中的直接值，job_title只是存储所有预先存在的值的列表（有些多余）？
3 .或者我根本不应该使用参考表/其他建议。
在这种情况下，您对设计的选择是什么，在一对多设计中它将如何变化？
这是一个例子，实际设计要大得多，但我认为这很好地传达了这个问题。
更新，澄清：
一个用户（问题范围之外）有许多工作，一个工作（开始/结束日期，{职务}）有一个头衔，头衔（名称（即。'Web Developer' ）
您的选项 1 是最佳设计选择。按以下行创建两个表：
- 工作（job_id PK，title_id FK不为空，start_date，end_date，...
- job_titles（title_id PK，标题）
PK 应具有聚集索引;jobs.title_id 和 job_titles 应具有非聚集索引或二级索引;job_titles.title 应具有唯一约束。
这种关系可以建模为 1 对 1 或 1 对多（一个标题，多个作业）。若要强制实施一对一建模，请对jobs.title_id应用唯一约束。但是，不应将其建模为 1 对 1 关系，因为事实并非如此。你甚至自己也这么说："同一个职位将被数据库中的多个作业使用"和"一个作业只有一个头衔"。作业表中的条目表示特定用户在特定时间段内持有的特定头寸。由于这是一对多关系，因此单独的表是建模数据的正确方法。
这里有一个简单的例子来说明为什么会这样。你的公司只有一位CEO，但如果现任CEO下台，董事会任命新CEO，会发生什么？您将在工作中有两个条目，它们都引用相同的标题，即使只有一个 CEO"职位"并且两个用户的工作日期范围不重叠也是如此。如果强制实施 1 对 1 关系，则无法对此数据进行建模。
为什么会有这些特定的索引和约束？
- 出于显而易见的原因，ID 列是 PK 和聚集索引;您可以将这些列用于连接
- jobs.title_id是FK，希望是显而易见的数据完整性原因
- jobs.title_id不为空，因为每个作业都应该有一个标题
- jobs.title_id需要一个索引来加速连接
- job_titles.title 有一个索引，因为您已经表示您将基于此列进行查询（尽管我不会以这种方式查询，特别是因为您说过会有很多标题;见下文）
- job_titles.title 具有唯一的约束，因为没有理由具有同一标题的副本。您可以（并且将）拥有多个具有相同头衔的作业，但您不需要job_titles中的"CEO"两个条目。实施这种唯一性将保持对报告目的有用的数据完整性（例如，根据填补的"Web开发人员"职位数量绘制IT网络部门的生产力）
言论：
职务将用作自动完成字段的一部分，因此我将使用查询来获取结果。
如前所述，在此处使用键值对。将它们的列表提取到应用的内存中，并查询该列表以获取自动完成值。然后将 ID 发送到数据库以进行实际的 SQL 查询。这样查询的性能会更好;即使使用索引，搜索整数通常也比搜索字符串更快。
您说过标题将由用户创建。设置一些输入清理和验证过程，因为您不希望出现多余的条目，例如"WEB DEVELOPER"、"Web 开发人员"、"Web 开发人员"等。验证应在应用程序和数据库级别进行;唯一约束是其中的一部分（但全部）。Prodigitalson关于机器和显示列分开的评论与这个问题有关。
编辑：在得到澄清后
这样的表就足够了 - 只需将job_title_id列作为外键添加到主member表中
__---- "job_title" table ---- (store the job_title) 1. pk - job_title_id 2. unique - job_title_name <- index this
原答案 __
您需要澄清job_title代表什么
- 一个担任这个职位的人？
- 担任此职位的部门/部门？
- 一组特定的属性？就像销售总是有佣金一样
- 或者只是一串叫什么？
从我目前阅读的内容来看，您只需要"job_title"作为某种维度 - 为它制作 id，使字符串可搜索 - 仅此而已
例
---- "employee" table ---- (store employee info)
1. pk - employee_id
2. fk - job_title_id
3. other attribute (contract_start_date, salary, sex, ... so on ...)
---- "job_title" table ---- (store the job_title)
1. pk - job_title_id
2. unique - job_title_name <- index this
---- "employee_job_title_history" table ---- (We can check the employee job history here)
1. pk - employee_id
2. pk - job_title_id
3. pk - is_effective
4. effective_date [edited: this need to be PK too - thanks to KM.]
我仍然认为您需要为我们提供一个用例 - 我相信这将大大提高我们的理解
如果只有几个固定的职位，你可能想在我们的数据库中使用枚举。请参阅 http://dev.mysql.com/doc/refman/5.0/en/enum.html如果您的 mysql 版本不支持这一点，只需使用数字索引对其进行编码，并在查询中将其解析为人类可读的形式。