数据库设计 : Categories in their own table?

Question

我正在将几个数据库重新设计成一个包含数据库，并且我注意到旧数据库的前任设计者喜欢将类别存储在他们自己的表中。例如，假设有一个表格 boats(bid: integer, bname: string, color: integer)，并且在应用程序中有一个下拉框允许用户指定船的颜色，然后有一个表颜色(cid:整数，cname:字符串)。我不会包括颜色表，只是将颜色作为字符串放在船表中。我意识到这减少了颜色名称的冗余存储，但是将船表与颜色表连接起来所增加的运行时成本“值得”吗？下拉菜单中还填充了 SELECT cname FROM color 语句，而我会定义一个关于 SELECT DISTINCT color FROM boats 的 View 来填充下拉菜单。

这个例子很简单，但是在我重新设计的系统中这种情况发生了多次，即使对于只有两个选项的类别也是如此。这导致许多表只有 2 个字段。有些只有 1 个字段(我还没有弄清楚这些是干什么用的，但我认为它们只是用来填充下拉菜单，实际的表格也包含这些值)。

Answer 1

如果这是我的数据库，我会亲自将它们保存在自己的表中。

如果您遇到这样的情况，即船 a、b 和 c 只能有银色和黑色，那么您会庆幸自己做到了。我已经在很多项目中看到了这些类型的请求。

如果您只关心查询的复杂性，您可以创建一个 View 来连接您需要的信息，这样您只需查询一次，无需 JOIN。

如果您担心 JOIN 的性能影响，那么我会考虑创建适当的索引或可能创建索引 View 。

祝你好运!