Those who have never read Edgar Codd's seminal paper on RDBMS are doomed to repeat the sounds-good-if-you-dont-think-about-it-too-much mistakes that NoSQL makes people sleepwalk into - and this will never end because database-theory is always an unpopular elective for CS undergrads (and a very dry, unappealing, subject-matter at that) - everyone wants to do Graphics or NLP or even Haskell instead - and if that's what CS degree-holders are like think about how even less well-prepared (for formal-modelling, etc) that a self-taught or bootcamp attendee would be: my point being that people with the right knowledge are always in the minority in this industry).
I say this isn't new because on the desktop in the 1990s, both Apple and Microsoft's dev platforms included some form of "object storage" based around their respective OLE/COM systems[1] and before then in the 1970s and 1980s it was people building business-systems on AS/400 (going back to the System 360...) where too many people never had a clue how to persist data on-disk (which was the whole impetus for Codd's paper, after-all) - so I think the 2000-2010 years where PHP+MySQL was dominant - and where most of us cut-our-teeth - was the exception: SQL is hard, relational theory is harder, relational calculus is harder-still (I think I got a B grade in that course...).
Non-experts have a very reasonable expectation that platforms should make it straightforward to save and load structured data without needing to spend a year of CS spending hours on exercises about functional-composition, surrogate keys, and decomposing tables to their 6th Normal Form - the embarrassment here isn't the non-experts you might think I'm dunking on, but it's the opposite: I'm very disappointed in the experts: the database-vendors and the platform-vendors, that they haven't solved the object-graph persistence library design problem.
------------
[1]: OLE/COM was for more than just composition, embeddeding Excel worksheets in Word documents and GUI design-tools: COM/OLE also featured a binary object structured storage API ( https://en.wikipedia.org/wiki/COM_Structured_Storage )
I say this isn't new because on the desktop in the 1990s, both Apple and Microsoft's dev platforms included some form of "object storage" based around their respective OLE/COM systems[1] and before then in the 1970s and 1980s it was people building business-systems on AS/400 (going back to the System 360...) where too many people never had a clue how to persist data on-disk (which was the whole impetus for Codd's paper, after-all) - so I think the 2000-2010 years where PHP+MySQL was dominant - and where most of us cut-our-teeth - was the exception: SQL is hard, relational theory is harder, relational calculus is harder-still (I think I got a B grade in that course...).
Non-experts have a very reasonable expectation that platforms should make it straightforward to save and load structured data without needing to spend a year of CS spending hours on exercises about functional-composition, surrogate keys, and decomposing tables to their 6th Normal Form - the embarrassment here isn't the non-experts you might think I'm dunking on, but it's the opposite: I'm very disappointed in the experts: the database-vendors and the platform-vendors, that they haven't solved the object-graph persistence library design problem.
------------
[1]: OLE/COM was for more than just composition, embeddeding Excel worksheets in Word documents and GUI design-tools: COM/OLE also featured a binary object structured storage API ( https://en.wikipedia.org/wiki/COM_Structured_Storage )