这是一个"正确"的数据库设计吗？

Question

我正在使用新版本的第三方应用程序.在这个版本中,数据库结构发生了变化,他们说"提高性能".

旧版本的DB具有如下通用结构:

TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES
(
    ENTITY_ID,
    PROPERTY_KEY,
    PROPERTY_VALUE
)

所以我们有一个主表,其中包含基本属性的字段,以及一个单独的表来管理用户添加的自定义属性.

新版本的DB insted有这样的结构:

TABLE ENTITY
(
    ENTITY_ID,
    STANDARD_PROPERTY_1,
    STANDARD_PROPERTY_2,
    STANDARD_PROPERTY_3,
    ...
)

TABLE ENTITY_PROPERTIES_n
(
    ENTITY_ID_n,
    CUSTOM_PROPERTY_1,
    CUSTOM_PROPERTY_2,
    CUSTOM_PROPERTY_3,
    ...
)

因此,现在当用户添加自定义属性时,会在当前ENTITY_PROPERTY表中添加一个新列,直到达到最大列数(由应用程序管理),然后创建一个新表.

所以,我的问题是:这是设计数据库结构的正确方法吗？这是"提高表现"的唯一方法吗？旧的结构需要很多连接或子选择,但这个结构在我看来并不聪明(甚至是正确的)......

Answer 1

我之前已经看到过这个在假设(通常是未经证实的)加入的"费用"上完成的工作 - 它基本上将一个行重的数据表变成一个列重的表.正如你所暗示的那样,当他们用完列时创建新表时,他们遇到了他们自己的限制.

我完全不同意它.

就个人而言,我会坚持使用旧结构并重新评估性能问题.这并不是说旧的方式是正确的方式,它只是略微优于我认为的"改进",并且无需对数据库表和DAL代码进行大规模的重新设计.

这些表格在很大程度上是静态的... 缓存将是一个更好的性能改进,而不会破坏数据库,我会先看一下.做"昂贵的"获取一次并将其粘贴在内存中,然后忘记你的麻烦(注意,我明白需要管理缓存,但静态数据是最容易管理的之一).

或者,等待每个数据库遇到最大表数的那天:-)

其他人建议完全不同的商店.这是一个非常可行的可能性,如果我没有现有的数据库结构,我也会考虑它.也就是说,我认为没有理由说这个结构不适合RDBMS.我已经看到它已经完成了我所做的几乎所有大型应用程序.有趣的是,他们都走了类似的路线,所有这些都是"成功"的实施.

Answer 2

不,这不对.它是可怕的.

直到达到最大列数(由应用程序处理),然后创建一个新表.

这句话说明了一切.在任何情况下,应用程序都不应动态创建表."旧"方法也不理想,但由于您需要让用户添加自定义属性,因此必须如此.

考虑一下:

• 您将失去所有类型安全性,因为您必须将所有值存储在"PROPERTY_VALUE"列中
• 根据您的用户,您可以让他们事先更改架构,然后让它们运行某种数据库更新批处理作业,因此至少所有属性都将以正确的数据类型声明.此外,您可能会丢失entity_id/key事物.
• 看看这个:http://en.wikipedia.org/wiki/Inner-platform_effect.这当然是充满了它
• 也许RDBMS不适合您的应用.考虑使用基于键/值的存储,如MongoDB或其他NoSQL数据库.(http://nosql-database.org/)