我写的很多应用程序都使用查找表，因为那是我学习（规范化等方面）的方式。问题在于，由于这个原因，我进行的查询通常更加复杂。它们通常看起来像这样：
获取所有仍然开放的帖子
"SELECT * FROM posts WHERE status_id = (SELECT id FROM statuses WHERE name = 'open')"
通常情况下，查找表本身非常简短。例如，可能只有3个或更少的不同状态。在这种情况下，通过在应用程序中使用常量或类似方式搜索某种类型是否可行？例如：
获取所有仍处于打开状态的帖子
"SELECT * FROM posts WHERE status_id = ".Status::OPEN
或者，如果我将其设置为枚举并通过它进行查询，而不是使用外键ID呢？
谢谢。
答案有点取决于你是否仅限于使用免费软件，例如PostGreSQL（不完全符合SQL标准），或者你正在考虑使用SQL（即符合SQL标准）和大型数据库。
对于符合SQL标准的开放式架构数据库，其中有许多应用程序使用一个数据库，并且许多用户使用不同的报告工具（不仅仅是应用程序）来访问数据，标准、规范化和开放式架构要求非常重要。
尽管有些人试图改变“规范化”等定义以适应其不断变化的目的，但规范化（科学）并没有改变。
if you have data values such as {Open; Closed; etc} repeated in data tables, that is data duplication, a simple Normalisation error: if you those values change, you may have to update millions of rows, which is very limited design.
Such values should be Normalised into a Reference or Lookup table, with a short CHAR(2) PK:
O Open
C Closed
U [NotKnown]
The data values {Open;Closed;etc} are no longer duplicated in the millions of rows. It also saves space.
the second point is ease of change, if Closed were changed to Expired, again, one row needs to be changed, and that is reflected in the entire database; whereas in the un-normalised files, millions of rows need to be changed.
Adding new data values, eg. (H,HalfOpen) is then simply a matter of inserting one row.
in Open Architecture terms, the Lookup table is an ordinary table. It exists in the [SQL compliant] catalogue; as long as the FOREIGN KEY relation has been defined, the report tool can find that as well.
ENUM is a Non-SQL, do not use it. In SQL the "enum" is a Lookup table.
The next point relates to the meaningfulness of the key.
INT;BIGINT;GUID;etc} or whatever is suitable; do not number them incrementally; allow "gaps".Now some people will get in to tangents regarding the permanence of PKs. That is a separate point. Yes, of course, always use a stable value for a PK (not "immutable", because no such thing exists, and a system-generated key does not provide row uniqueness).
{M,F} are unlikely to change
if you have used {0,1,2,4,6}, well don't change it, why would you want to. Those values were supposed to be meaningless, remember, only a meaningful Key need to be changed.
if you do use meaningful keys, use short alphabetic codes, that developers can readily understand (and infer the long description from). You will appreciate this only when you code SELECT and realise you do not have to JOIN every Lookup table. Power users too, appreciate it.
Since PKs are stable, particularly in Lookup tables, you can safely code:
WHERE status_code = 'O' -- Open
You do not have to JOIN the Lookup table and obtain the data value Open, as a developer, you are supposed to know what the Lookup PKs mean.
SELECT p.*,
s.name
FROM posts p,
status s
WHERE p.status_id = s.status_id
AND p.status_id = 'O'
对于银行系统，我们使用有意义的短代码（因为它们是有意义的，所以我们不会随季节更改它们，我们只会添加它们），给定一个查找表，如下（精心选择，类似于ISO国家代码）：
Eq 股票
EqCS 普通股
OTC 场外交易
OF 场外期货这样的代码很常见：
WHERE InstrumentTypeCode LIKE "Eq%"
GUI的用户将从下拉列表中选择值，其中显示为
{普通股;场外交易},
而不是 {Eq;OTC;OF}, 也不是 {M;F;U}。
如果没有查找表，则无法在应用程序或报告工具中执行此操作。
对于查找表，我使用一个明智的主键 - 通常只是一个CHAR（1），在域中具有附加的Title（VARCHAR）字段。这可以保持关系强制执行，同时“保持SQL简单”。记住这里的关键是查找表不包含数据。它包含身份标识。其他一些身份标识可能是时区名称或指定的{{link1：IOC国家代码}}。
例如性别：
ID 标签 M 男性 F 女性 N 中性
select * from people where gender = 'M'
或者，可以使用ORM，而且可能永远不必进行手动SQL生成--在这种情况下，标准的“int”代理键方法很好，因为其他东西会处理它:-)
愉快的编码。
为每个查找创建一个函数。 没有简单的方法。您想要性能和查询简单性。确保保持以下内容。您可以创建一个 SP_TestAppEnums 将现有查找值与函数进行比较，并查找未同步/返回零。
CREATE FUNCTION [Enum_Post](@postname varchar(10)) RETURNS int AS BEGIN DECLARE @postId int SET @postId = CASE @postname WHEN 'Open' THEN 1 WHEN 'Closed' THEN 2 END
RETURN @postId END GO
/* 调用函数 */ SELECT dbo.Enum_Post('Open') SELECT dbo.Enum_Post('Closed')
如果上述假设是正确的，则没有必要将所有这些额外的表添加到连接中，以便您的where子句可以使用朋友名称而不是id值。只需在需要时直接过滤status_id即可。我怀疑where子句中的非关键属性（如上面示例中的“名称”）更有可能发生更改，而不是关键属性（如上面示例中的“名称”）：通过引用加入中域表的所需关键值，您更受保护。
域表用于
自然地，您需要将域表引入到查询中，以便在实际需要域表的非键属性（例如值的描述性名称）时使用。
YMMV：很大程度上取决于上下文和问题空间的性质。
答案是“任何有意义的东西”。
查找表涉及连接或子查询，这并不总是高效的。我经常使用枚举来完成这项工作。它是高效和快速的。