将多对多关联存储在JSON字段而不是第三级表中会带来什么不利影响？

问题描述

假设我打算将以下对象存储在关系数据库（伪代码）中：

Domain:
   id: 123
   Name: A
   Variables: Thing_X,Thing_Y,Thing_Z

Domain:
   id: 789
   Name: B
   Variables: Thing_W,Thing_X,Thing_Y

我知道在结构域和变量之间建立多对多关系的标准方法是使用第三级表。但是，如果我用JSON表示相关内容，我想我可以做一些有趣的事情。并且，想知道执行以下操作的缺陷：

Domain:
   id: 123
   name: A
   variable_relates_JSON:{
      {table: 'Variable',id: 314,name: 'Thing_X'},...
   }

 Variable:
   id: 314
   name: Thing_X
   domain_relates_JSON:{
      {table: 'Domain',id: 123,name: 'A'},...
   }

我还专门针对此JSON方法与使用第三表的时间复杂性做了另外一个post。我也很高兴在这里听到这个问题的答案。但是，我也对这种方法可能遇到的一般挑战感兴趣。

解决方法

JSON字符串会导致必须存储字段的 name 及其值的开销。这会使数据大小成倍增加。

此外，日期和数字存储为字符串。在常规数据库格式中，2020-01-01占4个字节左右，而字符串中的10个字节（不包括定界符）占10个字节。数字同样如此。

数据所需的更多空间使数据库变慢。然后，搜索特定的JSON需要扫描或解析JSON字符串。一些数据库提供了对二进制JSON格式或字符串的支持以简化此操作，但您必须将其设置为表的一部分。

,

这是我想到的一个问题：当前更新。

继续上面的示例，假设用户将变量Thing_XX和变量Thing_YY都分配给域A。

对于每次分配，我将必须获取JSON并将相关ID添加到其结构中的某个位置。如果任何一个在另一个完成分配之前获取JSON，则它将覆盖另一个的分配。

一个松散的解决方案可能是在有人编辑时以某种方式“锁定”该字段。但是，这可能会变得很成问题。