4 ms·
Not everyone jumped on the NoSQL bandwagon. Software development is a horrible gaping maw of fad-driven, ill-thought-out crap.
by dunk010 9y ago
Not everyone jumped on the NoSQL bandwagon. Software development is a horrible gaping maw of fad-driven, ill-thought-out crap.
- arca_vorago 9y agoI'm so glad I started reading Michael Stonebreakers opinions on nosql before I dove into it. This is why scidb and voltdb are very intriguing to me.
- veritas3241 9y agoDo you have any recommendations on what to read? I'm curious about both of these DB's. Thanks!
- arca_vorago 9y agoSure, just a few blog posts and some other things really, but here you go. https://cacm.acm.org/blogs/blog-cacm/50678-the-nosql-discussion-has-nothing-to-do-with-sql/fulltext https://cacm.acm.org/blogs/blog-cacm/50678-the-nosql-discuss... http://www.labouseur.com/courses/db/Stonebraker-SQL-vs-NoSQL-2010.pdf http://www.labouseur.com/courses/db/Stonebraker-SQL-vs-NoSQL... http://www.redbook.io/ http://www.redbook.io/ https://www.barrons.com/articles/michael-stonebraker-describes-oracles-obsolescence-facebooks-enormous-challenge-1427744933 https://www.barrons.com/articles/michael-stonebraker-describ... https://blog.jooq.org/2013/08/24/mit-prof-michael-stonebraker-the-traditional-rdbms-wisdom-is-all-wrong/ https://blog.jooq.org/2013/08/24/mit-prof-michael-stonebrake... http://wp.sigmod.org/?p=1629 http://wp.sigmod.org/?p=1629 https://www.voltdb.com/blog/ https://www.voltdb.com/blog/ http://www.paradigm4.com/category/blog/ http://www.paradigm4.com/category/blog/
- veritas3241 9y agoOh wow! Thank you!
- whatyoucantsay 9y ago> Software development is a horrible gaping maw of fad-driven, ill-thought-out crap. Words such as these deserve a poster to live on.
- dboreham 9y agoT-Shirt
- matte_black 9y agoIf you want this on a poster I could easily have it printed up and sent for $35.
- geebee 9y agoYeah, what a disappointment. In the early days of NoSql, a lot of dev were still shoehorning graphs, objects, or giant look up tables into SQL database, and yes, it turns out that there are some wonderful databases to store and query this sort of data that don't rely on a relational model. And then... yep, a bunch of magpies decided that SQL shouldn't ever be used. It's important to point out that plenty of people who pioneered and promoted graph databases, object databases, and so forth didn't go down this rabbit hole. When the data was relational, plenty of these folks were all for relational databases. But I don't think you can claim the "NoSQL => never use SQL => SQL is obsolete" crowed was just a few outliers. This opinion infected a lot of software development organizations, and did plenty of harm. I love SQL, but let's not get too enthusiastic about sending the pendulum swinging back the other direction, even if tempting to watch it knock a few of the overly zealous NoSql types off their perches. Trust me, I still feel a flash of anger inside when I think of some of the arguments I had to go through when I advocated for relational SQL databases. But I don't want to be that guy myself - plenty of non-sql data bases are really well conceived and designed, and are ideal for the problems they address.
- bunderbunder 9y agoI would lay some of this at the feet of the fad for object-relational mapping, too. Trying to deal with object/relational impedance by sticking an object-oriented API in front of the database, and then using that to shoehorn OO ways of organizing and accessing data into an RDBMS, is a great way to place an upper bound on what kind of performance you can get out of the database. It also makes (what should be) routine schema migrations much more painful than they need to be. I think that that can explain a lot of the perceived success people were seeing with many document stores.
- geebee 9y agoThat's a really good point. I have, certainly in Rails projects[1], seen the strangest databases. They are SQL databases that are useless outside the rails application. You actually can't query them in a relational sense, you have to go through the app and its methods of querying, transforming, and merging data, before you understand what it means. In short, the developers more or less used the ORM to serialize and object and write it out to disk. The persistent data basically makes no sense on its own, it has to repopulate the objects before it can be accessed in any meaningful way. There's little doubt that the devs behind these project had very little understanding of what an RDMBS actually is. And if you don't, then I suppose NoSql makes sense, because your data is never relational - not because it the relational model wouldn't be helpful, but because the developer can't see the relational model in the data stored, and is incapable of structuring it this way. I remember this idea (paraphrasing)[2] - the data will outlast the application, and the application will most likely outlast the developer. To me, this led to a design principle - the database should always be useful outside the context of the application. If you want information about the data you're storing, the DB should be a very, very useful place to get it. I'm not ruling out the value of the app! There are lots of ops you'd want to do as a combination of code and data, lots of UI, plenty of things. But if your data is useless and nonsensical unless your app transforms it, that is probably a sign of a big mistake[3] [1] I love rails, and I like ORMs. They save me so much typing compared to the old days of JDBC. It turns out it's not all that hard to create a well organized relational database through generators, and if you prefer to design the DB separately, it's not hard to map models to db tables. It really only gets out of control when people are essentially designing an RDBMS through generators and an ORM, but have no idea what idea what it all means on the backend. [2]https://blog.jooq.org/2014/01/02/why-your-data-will-outlast-your-sexy-new-technology/ https://blog.jooq.org/2014/01/02/why-your-data-will-outlast-... [3] probably