Designing Relationships Instead of JSON Blobs

The starting point

JSON is incredibly useful, especially when a payload has controlled structure that genuinely varies by type. The problem begins when JSON becomes the default answer for every relationship. Authors, categories, tags, projects, technologies, and media all have identities and relationships that databases are very good at representing. Hiding those relationships inside arbitrary documents gives up useful guarantees in exchange for flexibility that may not actually be needed.

Stable identity deserves a table

If two articles can belong to the same category, that category has an identity independent of either article. Representing categoryId as a foreign key gives the database a chance to enforce that relationship. The same principle applies to many-to-many relationships such as articles and tags. A join table makes the relationship explicit and queryable.

This structure also makes future changes safer. Renaming a category does not require scanning arbitrary JSON documents for duplicated strings. One row changes, and every relationship continues to point to the same identity.

Use JSON where variation is real

Structured content blocks are a good example of an appropriate JSON boundary. A callout might have a title and text, while a comparison might have columns and rows. Those payloads vary by block type, but the article owning the block, its position, and the block type are still relational facts.

This hybrid approach is more useful than either extreme. A completely rigid relational model can become awkward for genuinely variable presentation data, while a giant JSON document makes stable relationships difficult to enforce.