2

我喜欢纯粹的关系设计，但有时需要一种实体/值方法来存储数据。尤其是用户需要频繁创建新类型数据的地方。

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

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

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

所以对我来说，这听起来很棒，但是如果把这个想法通过 DBA，你会吃很多苦头。这是一个好主意，有什么陷阱，有没有人尝试过这样做？

4

2 回答 2

2

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

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

第三：如果操作不当，可能会对使用数据库的其他事情（备份和维护脚本、其他应用程序等）造成一些严重的副作用。

于 2009-01-17T12:10:21.243 回答
1

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

  • 最初将值存储在键/值表中。
  • 使用动态的临时表，因为键/值对在每次调查时都转换为自定义表。
  • 填充这些临时表可以通过一条繁重的INSERT INTO temp_table SELECT ...语句完成，使用大量的LEFT JOINs。

这种方法非常适合这个特定的应用程序，因为调查通常有一个插入答案的阶段和一个分析结果的阶段。

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

所以我的建议是：考虑一下预期用途是什么。这个例子只是因为这个应用程序的特定要求而制定的。您主要是插入和更新值（OLTP）吗？或者您想运行聚合查询 (OLAP)？根据此问题的答案构建您的架构。

于 2009-01-17T12:23:37.160 回答