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

Question

我喜欢纯关系设计，但有时需要实体/值方法来存储数据。特别是在用户需要频繁创建新类型数据的情况下。

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

显然，这不是万能的解决方案，只有在您限制可以定义的数据种类时才有效。但是，它有以下好处:-

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

所以对我来说，这听起来不错，但是如果让 DBA 提出这个想法，您会感到很吃力。这是个好主意吗？有哪些陷阱？有人试过这样做吗？

Answer 1

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

第二:我认为创建一个用于动态创建良好数据库结构的良好解决方案的开销不会得到返回。

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