实体/属性替代 - 动态创建的表

Question

我喜欢纯粹的关系设计，但有时需要一种存储数据的Entity / Value方法。 特别是在用户需要经常创建新类型数据的地方。

我在一些商业软件中看到他们动态创建标准表而不是使用EV表。

显然，这不是一个解决所有的解决方案，只有在限制了您可以定义的数据类型时才能工作。 但是，它具有以下好处： -

• 模型已明确定义 - 您无需询问架构即可理解架构。
• 您可以获得更好的性能，因为表只包含该类型数据的数据，因此不需要查询明显不相关的行。
• 同样，索引仅保存表定义的数据类型的值，再次提高性能。 （即在EV模型中，如果索引是valueid，则为entityid - 您将搜索与查询无关的实体的值 - 除非您对索引进行分区）。

所以对我来说这听起来很棒，但是这个想法超越了DBA，你会得到大量的吸吮牙齿。 这是一个好主意，有什么陷阱，有没有人试图这样做？

Answer 1

首先：应用程序不应该能够改变数据库结构，因为它们没有权限这样做。

第二：我认为为动态创建良好数据库结构创建一个好的解决方案的开销不会有回报。

第三：当不正确地使用数据库（备份和维护脚本，其他应用程序等）时，它可能会导致其他一些严重的副作用。

Answer 2

不久前，我建立了一个在线调查应用程序。我使用混合形式作为数据库模式：

• 最初将值存储在键/值表中。
• 使用动态临时表，因为每个调查都会将键/值对转换为自定义表。
• 使用大量INSERT INTO temp_table SELECT ... s，可以使用单个繁重的LEFT JOIN语句填写这些临时表。

这种方法对于这种特定的应用是理想的，因为调查通常具有插入答案的阶段，以及分析结果的阶段。

• 有时建立临时表可能非常耗时，但只需在调查结束后进行一次。
• 之后查询结果表非常快。
• 临时表，如果删除或过期则会自动重新创建。因此，他们不必备份。

所以我建议：考虑一下预期的用途。此示例仅在此应用程序的特定要求下才得以解决。您主要是插入和更新值（OLTP）吗？或者您想运行聚合查询（OLAP）？根据这个问题的答案构建你的架构。