sql-server - 这是 "correct"数据库设计吗？

Question

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

旧版本的数据库有这样的一般结构:

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

TABLE ENTITY_PROPERTIES
(
    ENTITY_ID,
    PROPERTY_KEY,
    PROPERTY_VALUE
)

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

新版本的数据库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。我已经在我开发过的几乎所有大型应用程序上看到过它。有趣的是，它们都走上了相似的道路，而且大部分都是“成功”的实现。