|
> for instance, would you create a table with only one JSONB column. Sure. To make it more practical, I'd use a primary-key column too (like most document-only databases do). We actually do use a (INTEGER PK, JSONB) table in Pg, for a variable-depth permission-model store. The permissions (per PK) are encoded into a JSON document and queried using a 'get json object at path' lookup. Turns out, the way json & jsonb operators and functions are designed in Pg, it feels exactly like a document store, just available in your SQL (which is a plus, in my book). I think the larger theme here is your feeling that this is abusing or hacking around "the schema", but really, what is "the schema"? I've seen people use MySQL as just a store, using plain, NULLABLE VARCHAR and INT columns, and enforce a "schema" at the application layer, serializing and de-serializing their data from the VARCHAR columns. I've seen projects reinvent MVCC using an INT 'version' column in their tables. Databases can only allow defining and enforcing a schema at the database layer, they can't force it. Some databases allow a lot of control and many ways to define a schema, some allow little, but there's no requirement that one MUST use all the ways when available. In fact, even with rich databases like Postgres, sometimes even the db-level enforceable schema is not sufficient and one has to make do with enforcing some of it at application-level, and I'm talking about just the traditional data types here. Using JSON columns and operators and functions is — at the end of the day — using just another data type. Given Postgres is an object-relational database (it IS, after all, post-INGRES), it's only natural to use Postgres with data types like JSON (and arrays, and ranges, and GIS). |