关系数据库中“注释”表的最佳实践

时间:2010-11-03 15:57:36

标签: sql design-patterns

假设您要为某些Web应用程序构建数据库。此数据库已包含许多表,您可能必须在将来扩展它。

此外,您希望最终用户能够对数据库中的任何类型的对象进行评论。

我想找到一个足够通用的解决方案,这样我每次在数据库中添加新表时都不必扩展它。

我想到了以下内容:

表名:评论

  • id:评论的ID
  • user_id:发表评论的用户的ID
  • object_table_name:注释对象所在的表
  • object_id:object_table_name表中注释对象的id。
  • text:文字
  • 日期:日期

这个表解决了我的问题,唯一困扰我的是它的关系方面相当弱(例如我不能使object_id成为外键)。 另外,如果有一天我需要重命名一个表,我将不得不更改注释表中的所有相关条目。

您如何看待这个解决方案?是否有设计模式可以帮助我?

感谢.-

6 个答案:

答案 0 :(得分:5)

那不是更干净吗?

comment_set

  • ID

评论

  • ID
  • comment_set_id - > comment_set
  • 的外键
  • USER_ID
  • 日期
  • 文字

现有表 foo

  • ...
  • comment_set_id - > comment_set
  • 的外键

现有表

  • ...
  • comment_set_id - > comment_set
  • 的外键

答案 1 :(得分:1)

您正在混合数据和元数据,这不是最佳设计模式。它们应该分开。

但是,由于评论似乎不是很重要,所以你的解决方案是可以的。你最终可能最糟糕的事情就是失去对你的物体的评论。

某些数据库,尤其是PostgreSQL,支持COMMENT条款仅适用于此类案例。

<强>更新

如果您想对每个表中的个别记录发表评论,可以使用这样的表格。

如果重命名表,

object_table_name不必更改,因为它是数据,而不是元数据。

您不能编写本机SQL查询来获取任何表的记录的注释(在查询开发时不知道),尽管您可以构建动态查询来执行此操作。

在这种情况下,当您UPDATE他们引用的表时,您必须保持数据和元数据同步(RENAME注释表。第一个是DML语句(更改数据),第二个是DDL(更改元数据)。

还要确保所有PRIMARY KEYs具有相同的类型(与object_id相同)。

答案 2 :(得分:0)

了解EAV。 你可以像这样制作整个数据库。但是那将是地狱处理这些数据。

为什么不为每个应该支持注释的数据库实体放置一个Comment属性?这样,您就可以在单个查询中获得所需的所有数据,并且许多用于数据库的GUI程序将为您提供SQL中的完整代码完成,这将防止在使用字符串操作时容易发生的错误。这样,代码很大程度上依赖于程序代码,这对于数据库系统来说是不合适的。

答案 3 :(得分:0)

您可以在单独的表中枚举表名,以便名称中的更改不会以任何主要方式影响系统。只需更新枚举表即可。

虽然你将自己与参照完整性保持距离,但我可以看到另一种方法来实现你想要的东西。

答案 4 :(得分:0)

我通常更喜欢将注释与它们适用的行保持在一起。假设您的数据库有效地存储空VARCHAR字段,您不应该为此付出代价。实现此方法时,实际上没有任何“扩展”,注释的维护成为您已用于更新行的查询的一部分。

单注释表方法的唯一优势是它允许在不同类型的数据库条目的注释中轻松搜索。

答案 5 :(得分:0)

假设MS SQL,并且如果您认为该卷相对较小,那么Extended Properties可能值得探索。我过去曾经成功使用它们,它们似乎是永久性的固定装置。