4 ms·
Long before databases could even store structured JSON data, junior developers used to bikeshed viciously over the correct degree of normalization. More experi
by beachy 2y ago
Long before databases could even store structured JSON data, junior developers used to bikeshed viciously over the correct degree of normalization.
More experienced developers knew that the correct answer was to duplicate nothing (except for keys obviously) and then to denormalize only with extreme reluctance.
Then databases like mongo came along and encouraged those juniors by giving them something like a database, but where normalization was difficult/irrelevant. The result was a brief flowering of horrible database designs and unmaintainable crap towers.
Now the pendulum has swing back and people have rediscovered the virtues of a normalized database, but JSON columns provide an escape hatch where those bad practices can still flower.
- christophilus 2y agoEh. JSON has its place. I have some stateful data that is fairly transient in nature and which doesn’t really matter all that much if it gets lost / corrupted. It’s the sort of thing I’d throw into Redis if we had Redis in our stack. But the only storage in my project is S3 and Postgres. Postgres allows me to trivially query, update, analyze the usage of the feature, etc. Normalization wouldn’t buy me much, if anything, for my use case, but it would make “save this stuff for later” more of a nuisance (a sync across a bunch of rows vs a single upsert). That said, I’ve worked on projects that had almost no normalization, and it was pure hell. I’m certainly not arguing against normalizing; just saying that data blobs are useful sometimes.
- codr7 2y agoYeah, I'm def not taking a any more mongodb jobs if I can avoid it. I'm fine with using it for simple throw away stuff, but deciphering someone else's ball of json is soul killing.