我有一个关于数据库设计的简单问题......
假设我们Table Customer有一些字段：
(PK) Id,
Firstname,
Lastname,
Address,
City,
(FK) Sex_Id...
所以......
有一个额外的表格Table Sex是否可以保存有关性别（'M'，'W'）的数据？
Sex_Id,
Value
或应将{{1}}值（'M'或'W'）直接保存到表Sex中？查询速度等怎么样？
提前致谢， 最好的问候。
答案 0 :(得分：2)
或者，可以使用现有标准。 ISO 5218涵盖四个代码：
0 = Not Known
1 = Male
2 = Female
9 = Not applicable (lawful person such as corporation, organization etc)
ISO 5218是一种合法编码，不适用于医学/生物学方面。
显然，包含这些代码的参考表应使用自然键（如上面所列），而不是同义词。
Joe Celko's Data Measurements And Standards in SQL是一个伟大的（尽管很无聊）阅读。
答案 1 :(得分：1)
您可以尝试multivalued attribute，但我更喜欢这样做：如果只有2个值，您可以考虑在数据库中为该属性使用BOOL类型，并使0 =男性和1 =女性（当然，评论，以避免混淆）。当在外部程序中输入数据时（如果有的话），您可以快速映射，如果它们检查“male”，则DB中的属性为0，如果它们检查“female”，则属性值为DB中有1个。
答案 2 :(得分：0)
您计划使用Sex多少个不同的值？如果您不打算为该列添加更多可能的值，则使用外键没有意义。
答案 3 :(得分：0)
如果你需要存储关于那个东西的更多细节，你可以使用一个字符作为列，存储“M”或“W”，并使用外键到表（字符的主键）;您可以获得基本内容易于编写/读取查询（无需加入）的好处，但仍可以在以后添加更多数据。
也就是说，除非你的Sex表中确实有更多的列，否则你现在可能根本就没有创建它，而是在你真正需要的时候添加它。
答案 4 :(得分：0)
在你的例子中，额外的表格不会给你买任何东西。
@marc_s在这里有正确的想法，可以添加一个好的CHECK CONSTRAINT来确保本地值在正确的子集中。
现在，如果您的示例包含相关对象的其他属性，如“名称”或“描述”或其他对象的链接，如“别名”或某种日期范围 - 那么绝对是，请创建另一个表。< / p>