这是一个很好的练习来创建一个大的桌子吗？

我正在一家企业实习，在SQL数据库上进行选择查询，并且我想退一步确定什么是一种好的做法，或者不保持这种做法。这是一个很好的练习来创建一个大的桌子吗？

他们做了一个表，不同类型的代码，如：

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 |

正如你看到的，对于每个代码的一些信息。这是一种有效的做法，重新组合一个大表中只有少量信息的表，并在通过列“type”上的WHERE子句选择时检索我们的信息？在我的规模上，我将不得不创建三个表格（颜色，部门，生产类型），但是很少有信息。保留三张小桌子是否耗费大量资源？它是否会导致长期存在的巨大问题，使用一张包含不同“种类”信息的大表格？

来源

2017-08-09 Exomus

它们似乎是简单的文本查找。为每个查询分开的表格有优点和缺点。没有明确的“最佳”选择。 – Richard

你能列举这种做法的一些优点和缺点吗？因为我发现保留单独的表格更清晰，但是它也会使关系模型变得沉重，没有任何好处。 – Exomus

这种（反）模式通常被称为OTLT（一个真正的查找表）。国际海事组织的主要缺点是，除非你使用更广泛的外键约束，否则没有什么可以阻止某人存储例如'prodtype2'，a.k.a'9'列在期待颜色的列中。即为了获得体面的完整性，FK必须覆盖'type'列和'id'。 –

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

例如，您有一个“dept1”。你想保存更多关于你的部门的信息吗？然后创建一个新表“Department”与它的位置并为这个新表创建一个外键是有意义的。

至于性能，只要您的索引是正确的，两者都应该可以正常工作。

来源

2017-08-09 08:03:37 Carra

表中的信息仅用于在某些报告上进行打印，并且没有关于每个代码的更多信息。 – Exomus

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

一个真正的查找设计完全或者不增加巨大的复杂性实施参照完整性时遇到麻烦。

设计表示数据库内的数据库，有时称为内部系统效果。

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

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

系统中它的工作原理是

调查和问卷
产品评价系统
应用程序配置系统
医疗系统

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

来源

2017-08-09 10:32:36

这是一个很好的练习来创建一个大的桌子吗？

回答

相关问题