我刚刚为我的头数据库人员创建了一个DB数据库图表，并在其上放了一堆注释，建议我重命名某些表，因此很清楚它们是查找表（在开头添加“lu”）表名）。
我的问题是这些不符合我认为查找表的定义。我一直认为查找表基本上是一组没有定义任何关系的选项。例如：
luCarMake
-----------
id Make
-- ---------
1 Audi
2 Chevy
3 Ford
我工作的数据库人员建议我重命名几个表，这些表只是将一个表作为查找表的一个表。示例（下面的Location_QuadMap）：
Location
----------
LocationId
name
description
Location_QuadMap <-- suggesting i rename this to luLocationQuad
----------------
QuadMapId
LocationId
luQuadMap
---------
QuadMapId
QuadMapName
假设她误读了图表还是有其他我不知道的定义是否安全？
答案 0 :(得分：34)
答案 1 :(得分：21)
选择你的战斗 ，但我要求此人澄清命名惯例，因为他们建议使用相同的惯例进行一对多和多对多的关系。看起来任何外键关系都意味着涉及“查找”表。
如果这是其他数据库的命名约定，那么我就不会耽搁运气。
答案 2 :(得分：12)
查找表通常是一个充当某个东西的“主列表”的表，您可以使用它在exachange中查找业务键值（如“Make”），以获取它的标识符（如id列）在其他一些表的外键列中。
基本上，你会有一些东西要“查找”并将其换成其他东西。
另一方面，location_quadmap是一个桥表，正如其他人已经说过的那样，当你在两个实体之间存在多对多关系时使用它。如果你称之为查找表，那么我会说任何表都可以称为查找表。这些表只包含其他表的标识符，因此您必须首先在一个表上查找id，查找桥表中匹配的id，然后在中查找匹配的行。第3桌？似乎对这个术语有点过分了。
答案 3 :(得分：4)
有些人使用术语查找表作为位于多对多关系中间的表。
答案 4 :(得分：4)
Mark Byers对该表有正确的定义。基本上是交叉表。查看任何数据库教科书。
但实际上我和许多DBA /建筑师合作过，大多数人都发明了自己的做事风格，并且不愿意听别的事情。诸如缩进规则，SQL语句的情况，表的命名约定（甚至是非常糟糕的），存档策略等等......如果他们控制数据库，你基本上别无选择。你可以提一下它是一个交叉表，指向正确的文献，但最后如果她想把它称为MyStupidlyLongAndPointlessPrefixForTablesBecauseICan_Lookup_Location_Quadmap并且坚持那么你就什么也做不了。
所以试着向她指出，但如果她不顺其自然，那就不要太认真了......
我只想到别的东西。查找表（我们的定义）通常也称为代码表。所以她可以调用交叉表查找表和查找表代码表。在这种情况下，你可能必须学会说她的语言......
答案 5 :(得分：3)
查找表是仅包含ID，名称和某些主题/对象/事物的描述的表。 ID是主键和auto_increment。没别了。
答案 6 :(得分：2)
查找表的一个用途是存储其他enum值。
说，我们有一个Status枚举。
而不是在数据库中的每条记录中保存“未启动”，“正在进行”，“已完成”，“已发回”...我们只保存整数1,2，...
在编程方面，像Entity Framework这样的ORM可以轻松地将基础整数转换为枚举类型。
这样，缺点是整数值不能从数据库端读取。在解决此问题时，我们添加查找表，如
Id Status
1 Not Started
2 In Progress
...
这样我们的DBA就可以有一个字典来“查找”，通过加入这个查找表来显示状态文本。
答案 7 :(得分：0)
我想重复@Blaise 给出的答案。
这主要是针对这个问题的标题，而不是实际问题本身，但我仍然想指出我所知道的“查找表”。
在我工作的公司中，我们开发了一个包含大量“枚举”值的网络应用程序。想象一下，几乎每个 HTML 表单中都至少有一个下拉菜单，其中有 +10 个选项可供选择。在其他表单中，您可以勾选数十个复选框来启用或禁用我们系统的某些方面。
从历史上看，我已将此类数据硬编码到我的程序中，因为我没有将其视为“实时”数据，因此不值得保存在关系数据库中。但后来我的一位同事建议这样做，我很快就采纳了。
此类查找表的示例（包括数据）：
feature
-------
id int (PK): 1, 2, ...
key varchar: "fulltextSearch", "apiDebugger"
name: "Use fulltext search", "Enable API debugging console"
像这样的表格会有几十行代表系统设置、功能标志等。
在开发具有多租户的系统时，这会变得有趣且有用。在这样的系统中，可以使用 n-m 关系表管理每个租户的设置/功能：
tenant
______
id int (PK): 1, 2, ...
name varchar: "Your Company", "My Company"
tenant_feature
______________
tenant_id int (foreign key to tenant.id)
feature_id int (foreign key to feature.id)
feature_config varchar: {...}, {...}
tenant_feature 现在不仅用作将租户链接到功能的表，还包含附加信息，例如给定功能的配置元数据。
我没有在很多应用程序中使用过这种模式，但在我当前的项目中，这让我可以做一些事情：
active 列并使用它而不是构建单独的应用程序, 一个启用了功能，一个禁用了它