Postgresql using json objects to store data sets - sql

Question

I'm fairly new to using postgres and would like to hear some opinions before I take the time to set this up. Not that it matters what framework I'm using, but to better explain the scenario, I'm using django with many custom models (essentially post types) that require many fields which equates to many many columns in each db table.
I know postgres is well optimized for this type of scenario but in my case, I'm planning for this to be a large scale application and when it gets larger, I'll be making many calls to the database which could negatively affect the performance.
I honestly have no idea if this would be a viable option but could setting up my database to store the data in a json format in a single column be a good solution?
for example, let's say I have a model called 'laptop' and rather than have individual columns for specs like:
brand:
model:
screen_size:
ram_capacity:
processor_type:
processor_speed:
hard_drive_capacity:
graphics_card:
drive: ....
and end up having 30 to 40 columns would it be viable to have it set up like:
id(primary_key):
brand:
model:
specs(json object): {
brand:
model:
screen_size:
ram_capacity:
processor_type:
processor_speed:
hard_drive_capacity:
graphics_card:
drive:
}
I'm just using the laptop model as an example but obviously there are millions of potential use cases. Just wanted to know the pros and cons of this potential set up and any insight is appreciated.

Answer 1

Is it viable? Yes. Is it a good idea? Generally no.
Why not? JSON is powerful, but it has some shortcomings:
JSON repeats the headers, so the size of the data is much larger using JSON than without.
JSON's types don't have the same flexibility as Postgres types. For instance, it is missing dates.
It is harder to enforce constraints on JSON objects.
JSON is overly flexible, so there is little validation of the data going into a JSON object (other than the JSON format).
Note that JSONB overcomes some of these limitations.
So, if you have columns that you know are going to be part of each entity, storing them as separate columns is generally the best approach.
When do you use JSON? You use it when you have optional columns that would not be shared among most of the rows in the table. For instance, different manufacturers might have specs specific to that manufacturer and that would be suitable for a JSON object.

Answer 2

#Gordon Linoff explains many of the reasons why that is a bad idea. One question
I would also ask is how do you plan to look up items in the database if all the
information is packed into JSON? You will find it difficult to search for the items with a particular processor or with a particular processor speed for example.
You have not really thought about using the database structure very well. If there is a lot of overlap between your products you not only waste space but will suffer form insert and deletion anomolies. For example you include processor type and processor speed in the record whereas a properly normalised database would look more like :
CREATE TABLE manufacturers (
name ...
);
CREATE TABLE processors (
uid INTEGER GENERATED ALWAYS AS IDENTITY,
model TEXT NOT NULL,
manufacturer INDEX REFERENCES manufacturers (uid),
speed INTEGER NOT NULL,
cache INTEGER ....
)
CREATE TABLE models (
name ...
processor INTEGER REFERENCES processors (uid)
...
)
i.e. would be normalised. This reduces data loads considerably but also helps prevent update anomolies. For example with your scheme there has to be model a with
an AMD xyz processor in order to record details of that processor.
If you really do not want to do database normalisation then you might be interested in the HSTORE type which is a set of key/value pairs you can keep in a
column. This is not so good as a properly normalised database but makes it
possible to do queries on the keys and values.