3 ms·

I recommend this book: http://amzn.to/13NgjU9 http://amzn.to/13NgjU9 (affiliate link), which I bought for inspiration on how to build my own database from scrat

I recommend this book: http://amzn.to/13NgjU9 http://amzn.to/13NgjU9 (affiliate link), which I bought for inspiration on how to build my own database from scratch and finally put down, after reading several chapters, with a reasoned appreciation for the way things are. To simplify, the SQL data model exquisitely balances: * expressivity - queries involving both GROUP BYs and subqueries, which I've needed more than once, are challenging at best to translate into Mongo's query model, which is one of the most expressive outside SQL * speed - as long as your query can run on a single machine, SQL query planners are the best, period. Other models tend to be more horizontally scalable, but this was not a priority for most of database history, nor for most real-world situations. * compactness - the on-disk overhead of a SQL database is fairly limited, about 40-50% in practice. Obviously, a flat file has even less overhead (<10%, generally), but some non-SQL systems consume storage willy-nilly (it's not uncommon to see XML overheads surpass 500%, and Mongo overhead hovers around 90-100%). * robustness - in the SQL standard, "undefined behavior" is kept to an absolute minimum. In particular, transactions are invaluable anti-Heisenbugs, but cascading rules, sanity constraints, and fixed schemas also reduce production gotchas (at the cost of development agility, of course).

twic 14y ago
If i think about what scares me most about using a noSQL database, it's the loss of expressivity. I believe noSQL databases can be fast, compact, and well-behaved. But SQL is a phenomenal query language; it anticipates Alan Kay's (alleged) maxim that "simple things should be simple, complex things should be possible". Not only does it make complex things possible, but modern query planners make a decent fist of making them fast, too. NoSQL databases either don't support rich queries at all (eg Riak, which is in all other respects rather wonderful), or have substantially less power (eg Mongo). Even databases which are queried with map-reduce operations using functions written in real programming languages (eg CouchDB) are lacking compared to SQL, due to the lack of anything like joins, subqueries and so on. (The only kinds of noSQL databases that have something approaching SQL's power are graph databases (eg neo4j, whose Cypher query language is really rather nice), some object databases (eg ObjectDB, which supports JPQL), and some of the pre-SQL options like Pick databases. However, these are rarely the ones which get the attention, and it's notable that their data models are actually not far removed from the relational model.) The reason this flexibility matters is because it supports change in the future. I might be storing and querying data for some purpose now, but it's possible that a year down the line, i will want to do something entirely different with it - usually yawn-inducing things like reporting and auditing, sometimes just implementing new features that look at the data in a different way. The expressiveness of SQL lets me be confident that i will be able to do that with my relational database. With a noSQL solution, i run a substantial risk of not being able to do it, and so being forced to export my data into another store to do it, with all the headaches that that entails.
VLM 14y ago
"the on-disk overhead of a SQL database is fairly limited" The ___minimum___ on-disk overhead... At run time after deployment after growth sometimes I have to scramble adding indexes and depending on the business demand for "instant" online reporting or query speed, you can end up with a ridiculous number of large indexes. Which also has a negative, hopefully survivable effect on insert/update/delete speeds. I guess I'd add: * tunability - the DBA decides at the DB level based on defined business requirements how to trade disk space for read speed.

twic 14y ago

If i think about what scares me most about using a noSQL database, it's the loss of expressivity. I believe noSQL databases can be fast, compact, and well-behaved. But SQL is a phenomenal query language; it anticipates Alan Kay's (alleged) maxim that "simple things should be simple, complex things should be possible". Not only does it make complex things possible, but modern query planners make a decent fist of making them fast, too. NoSQL databases either don't support rich queries at all (eg Riak, which is in all other respects rather wonderful), or have substantially less power (eg Mongo). Even databases which are queried with map-reduce operations using functions written in real programming languages (eg CouchDB) are lacking compared to SQL, due to the lack of anything like joins, subqueries and so on. (The only kinds of noSQL databases that have something approaching SQL's power are graph databases (eg neo4j, whose Cypher query language is really rather nice), some object databases (eg ObjectDB, which supports JPQL), and some of the pre-SQL options like Pick databases. However, these are rarely the ones which get the attention, and it's notable that their data models are actually not far removed from the relational model.) The reason this flexibility matters is because it supports change in the future. I might be storing and querying data for some purpose now, but it's possible that a year down the line, i will want to do something entirely different with it - usually yawn-inducing things like reporting and auditing, sometimes just implementing new features that look at the data in a different way. The expressiveness of SQL lets me be confident that i will be able to do that with my relational database. With a noSQL solution, i run a substantial risk of not being able to do it, and so being forced to export my data into another store to do it, with all the headaches that that entails.

VLM 14y ago

"the on-disk overhead of a SQL database is fairly limited" The ___minimum___ on-disk overhead... At run time after deployment after growth sometimes I have to scramble adding indexes and depending on the business demand for "instant" online reporting or query speed, you can end up with a ridiculous number of large indexes. Which also has a negative, hopefully survivable effect on insert/update/delete speeds. I guess I'd add: * tunability - the DBA decides at the DB level based on defined business requirements how to trade disk space for read speed.