Re:Web Developer Security Checklist
by cookiecaper on Tuesday May 16, 2017 @12:30PM
(#14350866)
If document databases like MongoDB have taught us anything, it's that developers hate any sort of data organization, which is ridiculous and ironic since most of their day-to-day is about manipulating data. Mongo is popular because it allows the developer to stuff a value without thinking about its structure and role, generally leading to utter disaster further down the road.
I do think the biggest problem is that it brought everything into the DBA's turf, and made it too difficult for devs to do their jobs without meddling. As long as there is a dev/DBA organizational dichotomy, there will have to be a structural dichotomy in the software (cf. Conway's Law).
I wonder how many developers would consider using the filesystem as a document store bad practice, but at the same time be happy using mongodb.
It's odd that with the rise of solid, free rdbms' like postgresql (and the current generation of mysql forks) - the general reaction among developers hasn't been to realize that 99% of systems are/should be data-first/data centric - but rather a stubborn struggle to pretend their language supports transaction-guaranteed persisted runtime/memory -- without actually using a real object database like zoodb (for python) or gemstone.
Somehow a mess of structures/data objects paired with functions working on these objects - with only ad-hoc ways of enforcing foreign key relationships are seen as "easier", and "better for maintenance" than leveraging an actual (relational) database management system.
Sure it's more fun writing functions than thinking about data integrity - but the vast number of applications are concerned with managing structured information: from scenes in a game that could be interlocking state-machines to the more mundane user/message pairs or similar.
Design is eschewed for prototyping - but then the prototype is kept as the production system, rather than as a basis for design of a better (simpler) system.