Question

我遇到了一些使用大量查找表的表，以引用它们的特定值。对于因查找而只能将5个表扩展为20个以上的表的结构，这使数据库设计极为复杂。我环顾四周，但没有讨论是否使用查找表是一种好习惯。

使用一个查找表，您可以管理域，允许向域中添加新值，并向devs / dbas显示要遵循的域。但是同时，查找表会使数据库混乱，将不必要的业务逻辑添加到核心数据表中，并使从表中获取信息变得更加复杂。它还要求通过数据库提取来执行域查找，这将为使用它的应用程序增加额外的运行时。

没有查找表，数据很容易呈现，在数据库中减少了混乱，并使数据库设计更易于查看。但是，这使得查看数据的任何人都无法确定特定列中的值是否与域相关联，并且，如果存在域，则使得该域的管理可以通过应用程序完成。

我的问题是：使用现代标准，查找表是否是实施的好习惯？

Answer 1

如果您有一个像这样的表：

CREATE TABLE Bugs (
 bug_id INT PRIMARY KEY,
 bug_status VARCHAR(20) DEFAULT 'NEW',
 description TEXT
 ...
);

您想知道bug_status的所有有效值是什么，您可以获取当前正在使用的状态集：

SELECT DISTINCT bug_status FROM Bugs;

但是您怎么知道查询表时该表中存在该域所支持的每个状态的样本？

如果您使用此方法来获取允许的错误状态列表，例如填充用户界面的下拉列表，则您永远不能包含至少一个错误尚未使用的状态。这意味着用户界面不允许任何人第一次将错误的状态更改为某个值。

这应该是为什么查找表仍然是数据库设计中合法条目的一个示例。它与“现代标准”无关。我不知道为什么那会改变什么。

请注意，如果您不喜欢在查询表中使用doin JOIN来获取字符串值，则不必这样做。如果您希望将字符串值直接放在主表中，则SQL完全允许。

CREATE TABLE Bugs (
 bug_id INT PRIMARY KEY,
 bug_status VARCHAR(20) DEFAULT 'NEW',
 description TEXT
 ...
 FOREIGN KEY (bug_status) REFERENCES BugStatusTypes (bug_status)
);

CREATE TABLE BugStatusTypes (
 bug_status VARCHAR(20) PRIMARY KEY,
 description TEXT,
 is_active BOOL
);

您可以在字符串列上创建外键，引用查询表的字符串主键。然后，主表中的值被限制为允许的值，但是您不需要每次都想要显示人类可读的值而不是INT主键时进行联接。

查阅表还允许您添加描述性文本来解释域中每个值的用法（我在上面的示例查阅表中显示了description列）。如果您避免使用查找表或使用ENUM类型，则不能这样做。

同样，我在查找表中添加了is_active属性，该属性可让您“淘汰”某些值，因此您知道它们不应再出现在UI中，尽管您可能需要将其保留在查找，以便主表中的历史记录仍可以引用该值。这是将额外属性与域中的值相关联的示例。除非您使用查找表，否则您将无法做另一件事。

Answer 2

我仍然使用查找表，因为它们通常可以比主表快许多许多倍。我认为我的表大小增长速度超过了高清查找速度，因此-如果出于提高速度的目的-我认为它们仍然有意义。

这取决于要用来解决什么问题。

查找表是否是2019年的良好数据库做法？

2 个答案: