这是一个创建大型手表的好习惯吗？

Question

我正在企业实习，在那里我对SQL Oracle数据库进行选择查询，我想退后一步，确保什么是好的做法，不要这样做。

他们制作了一个包含不同类型代码的表格，如：

ID       |  TYPE       | Code       |
-------------------------------------
1        |   1         | red        |
2        |   1         | white      |
3        |   1         | blue       |
4        |   1         | green      |
5        |   2         | dept1      |
6        |   2         | dept2      |
7        |   2         | dept3      |
8        |   3         | prodtype1  |
9        |   3         | prodtype2  |
10       |   3         | prodtype3  |

如您所见，每个代码的信息都很少。这是一个有效的做法，重新组合一个大表中信息很少的小表，并通过列上的WHERE子句选择检索我们的信息＆＃34;键入＆＃34; ？ 按照我的规模，我必须创建三个表（颜色，部门，生产类型），但信息很少。保留三张小桌子需要花费大量资源吗？长期使用带有不同种类的大桌子会导致巨大的问题吗？信息呢？

Answer 1

如前所述，这是一个实体 - 属性 - 值模式，通常被视为反模式。可以在https://www.red-gate.com/simple-talk/blogs/when-the-fever-is-over-and-ones-work-is-done/

阅读最诙谐的谴责

一个True Lookup设计无法完全实现参照完整性，也不会增加复杂性。

设计代表数据库中的数据库，有时称为内部系统效应。

有特定和有限的用例或情况，其中EAV模型是有用的。这些往往是在一个实体的属性可以非常自由的形式的情况下。

• 大量数据类在属性方面几乎没有共同之处。
• 每个对象的少量属性。
• 流量业务要求或难以确定数据要求，使传统数据建模变得困难或不切实际。
• 实体内的变化率很低，仅限于插入和删除。
• 与模型中的对象的交互主要在实体级别，即检索整个实体，如果在属性级别执行任何过滤，则很少。

工作的系统

• 调查和问卷调查
• 产品审核系统
• 应用程序配置系统
• 医疗系统

这些天我会质疑RDBMS是否是这些用例的正确解决方案。 NOSQL解决方案（如文档存储）与上述用例更为匹配。

Answer 2

我们同时使用键/值表和多个表。这取决于你需要什么。

例如，你有一个＆＃34; dept1＆＃34;。您想保存有关您部门的更多信息吗？然后创建一个新表＆＃34; Department＆＃34;以及它的位置，并为这个新表制作一个外键。

就性能而言，只要索引正确，两者都可以正常工作。