8.14.2. Designing JSON documents effectively

8.14.2. 有效设计JSON文档

Representing data as JSON can be considerably more flexible than the traditional relational data model,which is compelling in environments where requirements are fluid. It is quite possible for both approaches to co-exist and complement each other within the same application. However, even for applications where maximal flexibility is desired, it is still recommended that JSON documents have a somewhat fixed structure. The structure is typically unenforced (though enforcing some business rules declaratively is possible), but having a predictable structure makes it easier to write queries that usefully summarize a set of “documents” (datums) in a table.

与传统的关系数据模型相比，将数据表示为JSON灵活得多。这两种方法可以在同一应用程序*存和互补。但是，即使对于需要最大灵活性的应用程序，仍然建议JSON文档具有某种固定的结构。该结构通常是不强制执行的（尽管可以声明性地强制执行某些业务规则），但是具有可预测的结构可以使编写查询变得更加容易，该查询可以有效地汇总表中的一组“文档”（基准）。

 

JSON data is subject to the same concurrency-control considerations as any other data type when stored in a table. Although storing large documents is practicable, keep in mind that any update acquires a row-level lock on the whole row. Consider limiting JSON documents to a manageable size in order to decrease lock contention among updating transactions. Ideally, JSON documents should each represent an atomic datum that business rules dictate cannot reasonably be further subdivided into smaller datums that could be modified independently.

JSON数据存储在表中时，与其他任何数据类型一样，都应遵循相同的并发控制注意事项。 尽管存储大型文档是可行的，但是请记住，任何更新都将获得整行的行级锁。所以，考虑将JSON文档限制为可管理的大小，以减少更新事务之间的锁争用。 理想情况下，每个JSON文档都应该代表一个原子数据，即业务规则规定不能将其进一步细分为可以独立修改的较小数据。