以下是三个可能值得考虑的选择：

1. json/jsonb
2. hstore
   1.父子树表
   一曰：如果名为“设置”的表中的行数非常大（人们在数据库中存储值的原因之一），并且您需要执行查询来查找或排序值，从PostgreSQL v12开始，您可能需要考虑使用jsonb or json PostgreSQL data types，它提供：

• 根据JSON规则，强制每个存储值都是有效的。
• 可用于存储在这些数据类型中的数据的各种JSON特定函数和运算符
• 对jsonb类型的数据值有一定的限制，但对数据库效率有一定的提高（从v12开始索引），或者放松了对json类型的数据和原始数据保留的限制，但降低了数据库效率

这可以是JSON特定字符串的附加列，或者原始基本字符串值可以重新工作或规范化为JSON值（例如["original value"]或{"value": "original value"}），这取决于哪个设置值更常见或您喜欢如何结构和管理表。
第二章：hstore module and data type对于在单个PostgreSQL值中存储键/值对集很有用，但与json或jsonb类型相比可能会受到更多限制，部分原因是存储的键/值对的平面性质（无嵌套）。
第三章：虽然不太可能满足您的需求/要求，但另一种替代方案可能是通过使用父+子关系结构增强表来避免完全存储JSON，这将允许您将JSON解构为与祖先条目键或id相关的各个后代条目/行。
其中{"range":[10, 50],"valid":2,"notvalid":0}存储为字符串可能是：

ID | KEY          | VALUE
1  | jsonSetting1 | {"range":[10, 50],"valid":2,"notvalid":0}
2  | strSetting1  | anySettingValue

字符串
相反，父/子结构可以是：

ID | PARENT | KEY           | VALUE
1  | null   | jsonSetting1  | null
2  | 1      | rangeMin      | 10
3  | 1      | rangeMax      | 50
4  | 1      | valid         | 2
5  | 1      | notValid      | 0
6  | null   | strSetting1   | anySettingValue

型
或更深的祖先层次：

ID | PARENT | KEY           | VALUE
1  | null   | jsonSetting1  | null
2  | 1      | range         | null
3  | 2      | min           | 10
4  | 2      | max           | 50
5  | 1      | valid         | 2
6  | 1      | notValid      | 0
7  | null   | strSetting1   | anySettingValue

型
父/子关系也可以通过UUID创建。
这种方法的一些缺点是增加了对JSON进行马歇尔/解编组的复杂性，SQL查找是如何结构化的，或者（通常）增加了SQL查询的复杂性，但如果希望对单个值运行查询，它可能会很有用。