"No to SQL"
Every time I see something or hear something like this I sigh a little bit. Not only when it's related to SQL but in the world of computer professionals in general. "The right tool for the job" seems to be a hard concept to understand sometimes. I wonder why?
When you choose a tool there will be pros and cons. Every time. Understand that and you will understand that picking a tool for a job i not about "saying no" or yes to something. If you want to say no or yes go join some political movement/party/whatever.
Would I choose a RDBMS for all of my database needs? Of course not! It all depends on the project. Is the data sensitive? What about integrity? Atomic operations? Type of data? Accessability? Number of users? The number of questions you have to decide on are many and starting by saying "No to SQL" is a pretty darn stupid. In my book that only proves that you do not understand what you're talking about. Trying to argue that X and Y is storing Z amount of data without using SQL only supports the lack of understanding. (Asking "why" X and Y is doing it that way on the other hand is a very good thing.)
Update: The ongoing discussion at ycombinator just shows how silly these kind of "debates" are.
Update 2: High Scalability have also noticed It Must be Crap on Relational Dabases Week.
The worst part is they are mostly dissatisfied with MySQL, but translate that to dissatisfaction with all SQL and SQL DBMSes
@James:
That's just sad. Like using a crappy web browser and making the conclusion that Internet is crap.
Ürk, yet more golden-hammer rubbish. You're absolutely right, their starting point is plain ridiculous, it's right-tool-for-the-job that is absolutely the way to think. You have to first understand the problem and then find the appropriate tools, not the other way around and classify tools as good and bad.
When deciding such things regarding databases I tend to start thinking what position the database is in. Most fundamentally, is it a database that holds data central to an organization and the services or functions that organization provides? If so it's more often critical than not, and it more often than not greatly benefits from the flexibility of an RDBMS and the power of SQL.
Facts:
1. SQL is generated very, very often. Be it using concatenating, using sprintf, or an ORM generating a query for its purposes.
2. The programming language generating the SQL can express the same intentions and ideas as SQL, and most probably does it better in the give situation (as the language is very consciously chosen, whereas SQL is often something you just have to deal with).
3. Generating SQL is fairly non-trivial (but looks trivial).
4. SQL has a multitude of dialects and per-database specific quirks.
Now, as a programmer, I ask: why is it so hard to have a programmatical interface, filling the same spot as SQL does, but programmatically?
I'm not saying we should rethink the RDBMS ideology. I just want to be able to query the database using the language I use, not some minilanguage I have to learn how to deal with aside from my main programming language.
Which, by the way, is why I even use ORMs. Not really because I think mapping objects to database rows is a honking great idea (because it just isn't, it doesn't fit), but because it relieves me of the pain of generating SQL.
Let's have an example: you have a number of primary keys you need to constrain a query by. These are integers in the programming language, and they are in a list. Using Python:
>>> sql = "select foo from bar where id in ("
>>> for id in ids: sql += str(id) + ", "
>>> sql = sql[:-2] + ")" # Strip trailing comma+space
Or the somewhat convoluted:
>>> sql = "select foo from bar where id in (" + ", ".join(map(str, ids)) + ")"
See my point? Why can't I just do something like:
>>> q = db["bar"].query("foo")
>>> q.constrain(db["bar"].id.in(ids))
(Disclaimer: making up such an interface on the spot isn't really easy, but doable)
@Ludvig: Again, you're missing the point. The point is the right tool for the right job. If you don't need a RDBMS don't use one. The point is to know when to use tool A or B. Saying "tool A sucks" is really just ignorant.
And, just as a note, every ORM is re-inventing the query logic thus making their own DSL so there's really nothing to gain from a ORM in that sense.
Well, speaking as someone new to programming( outside of javascript, etc. ), I am finding SQL quite hard to grasp. Sure, the syntax looks easy but I am struggling with the set theory mindset to get the data I want from more than one or two tables.
Many people will take the easier path of working through an ORM interface if given a choice. Me? I want to learn and understand SQL better( the theory, that is ) but haven't found good information. It's either way too simple, i.e., CRUD examples on one table, or way too complex for where I am currently at( lots of Relational Algebra and Set theory ).
In short, NO TO SQL is either intellectual laziness or people simply don't have the skill and time to learn it.
@Wandering Fool:
You have the right attitude. First learn SQL and then you'll have the knowledge to choose a full blown RDBMS when you need it and to avoid it when not needed.
