鉴于我有一个保存车辆信息的表格，其中一条信息是VehicleType（通常是6-20个字符），为什么设计这样的表格更好的技术原因是什么：
VehicleID
VehicleTypeID（INT）（与VehicleTypes表中的INT相关）
与此相对：
VehicleID
VehicleType（NVARCHAR（50））
我能想到一些......
1）如果车辆类型的描述发生变化，则只需在一条记录中进行更改
2）存储INT的空间比NVARCHAR少（当然，取决于字符串长度，特别是如果我更改为TINYINT。）
一些问题......
1）任何索引考虑因素？我假设如果我要在VehicleType上编制索引，如果我使用的是INT而不是NVARCHAR，它会更快并占用更少的空间。
2）任何查询优化问题？我知道前一种方法需要JOIN，但我不认为这会对SQL 2008产生负担。
我将捍卫自己的立场，并希望获得尽可能多的信息。
感谢您抽出宝贵时间作出回应。
谢谢，
Darvis
答案 0 :(得分：4)
如果您有一个“已批准”车辆类型列表供用户选择，从“VehicleType”表格驱动，这对数据输入表格也很有用。如果你不这样做，你最终会得到列表中没有的拼写错误和车型。此外，当添加新的车辆类型时，如果您从查询中填充下拉列表，则无需更改数据输入前端，查询将只获取表格中的所有车辆类型。
答案 1 :(得分：1)
请记住，nvarchar每个字符需要2个字节，所以如果int是4个字符，那么要使用相同的空间，你只能在nvarchar列中使用2个字符。
如果tinyint（最多255个）不够，我会使用int或甚至smallint（最多32,767和2个字节的存储空间）
所以我会在这种情况下使用第一个表
不知道你的查询会是什么样子，但可能想要切换列并从typeid开始
答案 2 :(得分：1)
前者是3NF，正确归一化数据。
1）任何索引考虑因素？
不会自动为外键创建索引。在外键上创建索引是有意义的 - 它很可能被用作标准，但应该考虑数据和对它的访问。 MySQL对分配索引的空间量有限制（没有其他人知道），虽然索引有助于数据检索，但它们也会影响INSERT / UPDATE / DELETE语句。如果处理SQL Server，我highly recommend reading Kim Tripp's The Tipping Point series。
2）任何查询优化问题？我知道前一种方法需要一个JOIN，但我不认为这会对SQL 2008造成负担。
连接是最优选的数据检索和操作方法，而不是子查询......
答案 3 :(得分：1)
如果车辆类型的描述发生变化，则只需在一条记录中进行更改。
正确。还有当前未使用的“车型”，例如燃料电池车。
这些是“data modification anomalies”
其他人也回答了指数问题......
答案 4 :(得分：0)
基本上你要做的是对表设计进行去规范化。这对于报告目的（当有数百万条记录时）非常有用，但出于应用目的，我会使用标准化数据库，并在其上构建适当的索引。这也有助于参照完整性。
希望这有帮助。
答案 5 :(得分：0)
小心更改“选择列表”（域）中的名称，例如Vehicle Type。
如果您使用外键，那么该类型的所有现有条目都将受到影响 - 这是否有效？
我不知道Vehicle Type是什么意思，但如果Vehicle Type = Vehicle，
例如，如果 Datsun 将其名称更改为 Nissan ，则可能会出现Make问题 - 表格中的现有车辆仍为 Datsuns .....