The stage information of a task is stored directly in JSON format, which avoids table association, avoids building tables, and the application layer processing is much simpler. 1. JSON content is informational in nature, not non-statistical, simple to show, not for deep processing; 2. JSON content should not be multi-table needs, such as some of the information is actually shared by multiple tables, this is not possible, because there is an update batch problem; Once the JSON content is modified/created to affect more than one table, use json;3 with caution. JSON content should be strong dependency, such as the stage information is always dependent on the task and exist, if there is a logic to separate for the "stage" content to deal with, or in the concept of the table need to "stage table" in the case of the master table, the JSON is used with caution, preferably a single table. 4. Fields in JSON are used with caution in terms of retrieval criteria, although MySQL and MongoDB support the use of JSON, but it is undoubtedly inefficient for the database server to parse and re-process the JSON.
Design idea of database JSON field
