Question

我正在设计一个数据库，在该数据库中我想跟踪用户操作和注释。

记录示例：

Sally edited this note at 11:34 on 11/25/2019
Matt changed note status from 'incomplete' to 'complete' at 13:57 on 12/15/2019

注释示例：

This customer is difficult to work with. - Matt 14:32 12/17/2019
Called customer, they told me they have a dog named George - Matt 18:32 12/17/2019

我的应用程序代码将格式化数据并将其解析到结构中，而如何执行则没有问题。

我的问题是，最好对每个表使用单独的表作为注释和日志。

我将有很多表，您可以想象将需要两个表。其他用户需要做笔记的供应商/联系人/客户。

最好将它作为JSON存储在customers表中，该表中的每个用户操作都在操作JSON对象下进行，并且我实际上制作了一个不断扩展的数组？ customers.notes就像

"notes": [{
  {
    "user": "Matt",
    "timestamp": "2019-04-21T16:18:18+00:00"
    "note": "Customer has a dog named fluffy"
  },
  {
    "user": "Sally",
    "timestamp": "2019-05-28T9:11:56+00:00"
    "note": "Called them just now"
  }
]

这是否会导致性能问题，我应该创建一个JOIN表以及一个customers_note和customer_log表，并且对于其他表（例如联系人，供应商等）也应类似

Answer 1

RDBMS最擅长的是将结构良好的数据存储在表中。当您处理的数据仅是半结构化时，即当它们的结构因记录而异时，必须使用诸如jsonb字段之类的No-SQL东西。一个典型的示例是某些数据库中的“附加信息”字段，其中每个记录都有一组不同的附加信息项。（SQL纯粹主义者会说这样的数据库设计不当。）

这不是您的情况。

每个注释由一个操作员ID，一个时间戳和一个小文本组成。再添加两个字段（一个note_id自动递增主键和一个要连接的customer_id外键），您将获得一个高效的notes表。与回答塞入customers表中且难以使用的那些json数组相比，回答各种问题（例如“运算符X是否偏向某些类别的客户？”）将更加容易。

如果您的应用程序确实更喜欢json数组而不是记录集作为注释，那么无论如何，您都可以使用json_agg(row_to_json(...))在json中使PostgreSQL回答。

关于性能，您告诉我们的信息太少，无法正确评估其问题：一个客户会有多少笔票据？他们多久需要一次？在当前的互动中，很老的笔记真的有用吗？这些都是评估绩效时要考虑的所有方面。

我应该使用JSONB或JOIN表在PostgreSQL中记录用户操作和注释吗？

1 个答案: