我有一个表，其中有一个JSON列，其中包含产品的所有非常见规格。
例如我可能有
手机，我将屏幕尺寸存储在此json列中，因为我可能有另一种根本没有屏幕的产品（电脑机箱）。
{screenSize: "6 inches" }
但是有些产品我有一个预定义的选项列表，因此在上面的示例中，我的数据库中可能会有另一个表
ScreenSizesTbl（在我的实际数据库中，它更通用，可以容纳所有产品的所有预定义选项）
id Name
1 6 inches
2 5 inches
我应该存储名称或ID吗？
{screenSize: "6 inches" } or {screenSize: 1 }
如果我选择后者，那么在提取此信息时，我会即时获得名称。我看到的好处是，如果我将名称更改为“ 6英寸”，则无需进行数据修复。
我看到的缺点是，如果我正在查看原始数据，那么我只会看到所有id，并且不确定是否真的可以将json属性联接到表上的id。
我正在使用sql server 2017，因此它具有json支持，但是我不确定是否支持加入我需要的东西。
答案 0 :(得分：0)
我看到的缺点是，如果我正在查看原始数据，我只会看到所有 id，不确定我是否真的可以对json属性进行联接 桌子上的ID。
这是一个良好的标准化数据库的标志。您的表应该有很多与其他表连接的ID，然后原始值仅存储在单个表中的某个位置。我每天都会编写大量查询，这些查询需要3次以上的联接才能从主表进入为我提供原始字符串值的查找表。
您应该做的一个例子是：
您有一个包含产品名称，createddatetime等的产品表（product_id为PK）和一个包含“屏幕尺寸”，“芯数”等内容的属性表（attribute_id为PK），但没有值，那么您就有一个将这些值匹配在一起并分配数字/字符串值的表。
所以您的表最终是：
Product_ID Attribute_ID Value
1 1 6in
1 2 2600Hz
1 3 Pepperoni
1 4 Blue
并且您必须加入产品以获得产品名称，并加入属性以获取属性名称。我已经看到了值表，其中每个值都有一个ID，您也必须加入该ID。
在绝对的情况下，您需要存储JSON，但是解析出用于连接和利用索引以进行快速检索的值可能会很痛苦。