8 ms·

In defence of SQL

125 points by seldo 16y ago

DjDarkman 16y ago
Very good article, I myself have found the "NoSQL" label pointless, when you label something you normally tell what it is, instead of what it's not.
- cheald 16y ago
  "NoSQL" is generally understood to mean "Not Only SQL", not "SQL is evil, begone foul beast".
  - ergo98 16y ago
    >"NoSQL" is generally understood to mean "Not Only SQL" I think that that is a bit of convenient revisionism as it becomes clear that the Emperor is wearing no clothes. There absolutely was a very antagonistic, "this changes EVERYTHING" philosophy behind the movement called NoSQL, and the name is not accidental. Perhaps it was just a bit of trolling to get attention, but in no way was it a live and let live initiative (data tactics that are now bound in "NoSQL" long existed in computer science, since before the days of SQL. They just didn't feel the need to make it a comfortable community of evangelists). It was a "that was yesterday and this is today". Of course things have changed. A bit of realism entered the mindset, so now it's more of a "Heh heh...no bad blood right? We're all good, eh?"
    - mathias_10gen 16y ago
      Actually the name was very much accidental. Read this post by the guy who coined the term: http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.ht... "it was one of 3 or 4 suggestions that I spouted off in the span of like 45 seconds, without thinking."
      - ergo98 16y ago
        >Actually the name was very much accidental. Spur of the moment isn't really accidental, any more than Mel Gibson accidentally said the N-word. There's a bit of a history and a thought process that leads to such a decision.
  - mistermann 16y ago
    I disagree that this is the "general understanding".of the term No SQL.
  - sbov 16y ago
    That would be NOSQL, not NoSQL
jbarciauskas 16y ago
This article reiterates a fundamental point that object stores quite clearly present less friction during development than relational stores. This is plainly true: your domain object is meant to model the domain, and if you can store it directly that is the best you can hope for. There's a reason there's a whole topic of study and research called "Object-relational impedence mismatch" (http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...) However I think ORMs are too quickly dismissed. In the simplest case, an ORM can appear to be a key-value store at the API level. Of course that is a gross abuse of a relational store, but there's no reason it can't be done. Additionally, the author fails to note that an intelligent ORM can provide a caching layer that improves performance over raw SQL. A more detailed examination of the various patterns to resolve the impedence mismatch, such as active record versus data mapper, ORM caching strategies, and how those compare to a key-value store solution, I think would be a valuable topic of discussion.
- seldo 16y ago
  If the ORM layer is providing a caching layer on top of the RDBMS, that caching layer is effectively a non-relational store for the data. If that works better, why not use it as the primary store?
  - jbarciauskas 16y ago
    Not necessarily - you could store a resultset based on the query and parameters, and if the same query and parameters come within a certain amount of time, you return the whole resultset from the cache. In this scenario, the resultset could contain a filtered list, aggregate functions, etc, that are more difficult to replicate in a key-value store.
    - gaius 16y ago
      That is exactly what Oracle Coherence (nee Tangosol) does.
  - Aaronontheweb 16y ago
RyanMcGreal 16y ago
>It triumphed over other query languages not because it was particularly great (though it was easier to read), but because it was standard. Isn't that a tautology?
- DrJokepu 16y ago
  Not all standards are popular. Microsoft's OOXML, for example, is technically an ECMA and ISO standard but I wouldn't call it exactly popular (even though it's widely used due to Office's market position). Because being a standard does not always imply popularity, the statement is not a tautology.
- btilly 16y ago
  No. Standard just meant that it worked in lots of different places. It didn't mean that it was the only option, first option, or best option. But, by being standard, it became a lowest common denominator that people largely stuck to. The links at http://en.wikipedia.org/wiki/Query_language http://en.wikipedia.org/wiki/Query_language include many of the competitors to SQL. In particular look at Datalog, ERROL, ISBL, and QUEL.
kunley 16y ago
This article has its amount of religious bias and wishful thinking. The author tries to establish his base on a fact that SQL is all about relational algebra and it's the right paradigm to query your data. While I agree with the latter, the author (and lots of other people) seems to forget that SQL is a dumbed-down-aimed-to-mediocre-programmers contraption inspired by relational algebra, but not really properly relational! It's really far from what Codd had in mind. If you read the history of early SQL dialects and DB2 vs Oracle competition it's clear that SQL was marketed as a language everyone can program in (thus the stupid imitation of a natural language) -- we know in XXI century that this is a bs... I'd say that SQL is a COBOL of relational algebra...
- Devilboy 16y ago
  Are there any (more suitable) alternatives to SQL?
  - silentbicycle 16y ago
    The K/Q people (http://kx.com/ http://kx.com/) have one interesting interpretation. It's quite expensive for production use* and uses an APL dialect as a query language, which tends to scare away a lot of developers. I'm utterly fascinated with it, albeit from a distance. (J is cool, too, but doesn't come bundled with a high-end in-memory database.) * I've heard it can run $60k/CPU. It's designed for realtime stock data mining (https://cs1.cs.nyu.edu/cs/faculty/shasha/papers/hpts.pdf https://cs1.cs.nyu.edu/cs/faculty/shasha/papers/hpts.pdf), so they get away with it.
    - mistermann 16y ago
      Can you give us some syntax examples?
      - Devilboy 16y ago
        If it's anything like APL you probably don't want to see it...
      - 16y ago
rlpb 16y ago
SQL always seemed to me to be the way it is in order to lend itself to optimisation at the database end. It is easy to look at any SQL query (that doesn't use subselects) and see how the DB engine can efficiently execute it by walking down the appropriate indexes. Try doing that with an ORM or a key/value store.
- jbarciauskas 16y ago
  Can you elaborate the issues an ORM has in dealing with indexes? An ORM can be made aware of indexes via, e.g., annotations or other declarative syntax, and prefer those when joining and filtering, and will probably be more consistent about it than a human developer.
  - rlpb 16y ago
    I didn't mean that ORMs have problems with indexes; just with efficiency: because you can tell the SQL engine what you want done instead of having to bring the data to the code (in particular when iteration can be folded into the query).
    - jbarciauskas 16y ago
      Yes; but even this only goes so far. Execution plans change based on statistics collected by the query optimizer. SQL was invented because query optimizers do a better job than humans. The same is commonly true for ORMs.
JoelMcCracken 16y ago
I don't believe that there really are all of these developers around who lack knowledge of SQL. I learned SQL while I was learning to program. My very first (real?) program was a php hit counter that wrote to a hits.txt on the server. My second one was a guestbook that used mysql. My third one was a basic hierarchical forum. I wasn't a wizard, I was just a kid reading a book, bored at the Pennsylvania Farm Show. Thus, I have spent my fair share of time working with sql queries in php code. Guess what? The SQL queries weren't very hard at all. However, SQL Queries had almost nothing to do with actual using SQL itself. 90% of the code written in such a project is guaranteed to be cruft code surrounding the sql queries. Special cases abound. The difference between "column = $val" and "column is null" is so painful that I just can't imagine going through that anymore. And that's just the first example! What does "" mean if you save it in a db column? Should you save it as a null value, or as a string with zero characters? I just don't care about this at all, and you'd have to be a damned fool to think that I would ever willingly go back to doing that bollocks. I already have my in-memory data structure laid out. ORM lets me keep from worrying about it it again (at least not nearly to the detail I would with SQL). With an ORM, 90% of the database code that I used to have to deal with is simply a non issue.
- seldo 16y ago
  I think you are misunderstanding the article; it's not that object models for data are bad, it's that mapping them to a relational store is inefficient and pointless. The point against ORMs is not that they have inferior APIs -- in fact I say how bad SQL is. The point is that they wrap quite nice APIs around an inappropriate data store. If you have an object-like in-memory data structure, why not use an object store and have it in your data as well? The relational nature of your store is working against you. If your ORM exists to keep 90% of the database code hidden, why not dispense with the RDBMS entirely and lose that useless 90%?
  - mistermann 16y ago
    Maybe because it makes that 90% legacy code useable?
- silentbicycle 16y ago
ignu 16y ago
"The birth of ORM lies in the fact that SQL is ugly and intimidating" The notion that people steer away from SQL because it is intimidating is absurdly ignorant. The communities that embrace ORMs and NoSQL are the ones who are learning and creating new things all the time. No one's first language is Ruby, they didn't learn node.js in college, they didn't take an (N)Hibernate certification course. They learn in their free time! Meanwhile, if you were good in SQL 12 years ago then you still are today! Smarter people than me have written on these subjects, but for me, the answer is simple. As Fowler says, the most pervasive smell in software is duplication. If I litter my code with all the CRUD SQL (even worse with sprocs that contain column sizes) then my software is quite brittle.
- ora600 16y ago
  If you little all your code with CRUD, your code is horrible indeed. If I hard code filenames all over my code, I also have horrible code. This doesn't mean that files and file names are a problem or that they caused duplication. The normal (I hope) practice is to this in terms of transactions or activities and create functions that wrap those activities. SQL should only live within those functions that provide a logical interface to the DB. Its called TAPI or XAPI (transaction API). Think of it as your own domain specific ORM.
  - gnaritas 16y ago
    > SQL should only live within those functions that provide a logical interface to the DB. Its called TAPI or XAPI (transaction API). Think of it as your own domain specific ORM. Which is generally repetitive and full of duplication, exactly the thing that drives people to use ORM's in the first place. It doesn't matter that it's isolated into a separate layer, it's still more manual work than an ORM.
    - ora600 16y ago
      It is more work than ORM, but if efficient access to data is an important part of your application, it seems to be extra work that brings benefits. At least that has been my experience. I'm not clear on why this layer has to be repetitive and full of duplication.
derefr 16y ago
These arguments make me feel like DBMS technology is insufficiently distinguishable from magic. Databases do two things: they persist data, and they answer queries about data. Neither of those requirements put any restrictions on how they serialize data. Relational storage, object storage, document-based storage, key-value storage, graph-based storage, etc.—it all just seems like different optimizations on the same "real" data, something that should be abstracted away from the database administrator entirely. Why can't we just have a database that gets fed a normalized, relational-algebra-style model of the data, but then profiles the kinds of queries fed to it, and the kinds of data given, and builds whatever kind of denormalized tables/indexes/k-v stores are optimal for your usage patterns, using a Relational, or Object DB, or Graph DB, etc. engine when each is appropriate (perhaps firing them off in parallel and returning whichever answer comes first, killing the other threads)? Is this something anyone is working on?
- seldo 16y ago
  If you can build this, please, please let me buy it. Or preferably invest in it.
- randallsquared 16y ago
  This sounds suspiciously like a sufficiently smart compiler.
  - derefr 16y ago
    I was mostly thinking of the profile-driven optimization of the HotSpot JVM—something that was repeatedly called a Sufficiently Smart Compiler, until it happened to actually work.
- panic 16y ago
  Apple's Core Foundation data structures do this sort of "usage-based implementation selection," though in a much simpler context: (see e.g. http://ridiculousfish.com/blog/archives/2005/12/23/array/ http://ridiculousfish.com/blog/archives/2005/12/23/array/). I'm not sure why this technique isn't more widespread.
- deleted 16y ago
forkandwait 16y ago
In defense of SQL syntax, I think that, in its very constrained domain, it models table / set operations with the best balance of expressivenes, readability, and generality today. At least compared to any other syntax I have seen, including ORM's. We take our old friends for granted until they are gone, and I have had to work with a number of data environments without SQL and its lack was sorely missed. The SAS community was overjoyed at the addition of PROC SQL for this reason, and the goofiness one has to do in R/ SPLUS is quite unpleasant.
- ora600 16y ago
  Even in its own domain, SQL sacrificed parsing for "user friendly" English-like appearance. SQL error messages are very unhelpful in every DB. You can't easily debug misbehaving queries and there are no tools to help. There is even a lack of indentation standard. Fixing very long queries that fetch the wrong results is something I've been doing daily for the past 10 years of my life. It is not easy, and I believe the language is to blame for a large part of the difficulty. In some aspects of doing unexpected things with no warning - it is worse than C.
  - jerf 16y ago
    Further: SQL is not composable. If I have a fragment of SQL in my hand, there is no reasonable way to insert that into a larger expression. You can further tell this is a problem by the way any nontrivial SQL function degenerates into an enormous hellstorm of SQL that any Haskell programmer will see as full of redundancy. This is because SQL is almost immune to abstraction. (I have to specify the "Haskell programmer" bit because of the characteristics of this sort of language is that working in it directly for a long time causes you to think natively in that language and thereby miss the opportunities for abstraction that you no longer see. FWIW, Erlang also bothers me this way.) Yes, the "bad programmer" issue is in play too, but as a good programmer who has tried to write good stored procedures and has experience in numerous other languages I can not help but notice how much SQL fights me on this front. SQL is very difficult to debug in general, which combines rather poorly with the previous characteristic. Perhaps there are nonstandard extensions in Oracle that make it easier but there's nothing I know of in the core language. SQL has fooled people into thinking it is equivalent to the Relational Model, when in fact as kunley points out elsewhere it is merely inspired by it. SQL dates from the 1970s and it shows. There are syntax quirks around every corner. The behavior of NULL is sensible, but it is merely one of several sensible choices and there are reasons why the SQL choice is not the one that has "won". Why is "value IN ()" a syntax error? It's perfectly reasonable. What's with the syntactic drama around subselects, which ought to be a core part of the better language that we really ought to be using? (A language in which the equivalent is probably going to be so simple we won't even believe people had a special syntax for it.) What's with the rigid specification of the order of GROUP BY and ORDER BY and everything else, when those should simply be instances of some sort of combinator that applies in order, in a sensible manner. Why is SELECT used both for data queries and aggregate queries when in fact the two operations are so different they should have entirely different keywords? Why is it so hard to mix an aggregate and non-aggregate query together when it's obvious to me exactly what I want? Why can't my columns contain tables themselves, recursively? The fact that there are databases that can do this proves it's not impossible. SQL needs to be replaced by a combinator-based language that backs to a richer data store that is more sensible, both from a relational model point of view and from a recursive point of view. LINQ points the way, but still is hobbled by LINQ-to-SQL being the flagship LINQ product. (And I don't think it's complete as-is.)
gfodor 16y ago
I think he's got it backwards. He says SQL is a great language in front of a crappy model, the relational model. I think SQL is simply a limited language in front of a great model. The NoSQL folks are throwing out both, so I guess that's "the only way to be sure." Going to be fun seeing them re-invent the wheel for the next 5 years. What we need is a more elegant, flexible language instead of SQL for data retrieval. SQL++, since the relational model is sound. Beyond that, we need a more intelligent data store that will be able to translate a fully normalized schema into a high performance, distributed, persistent representation that is queryable by this language. There's no reason in theory this can't happen, its just hard. To think that dropping us down to GET and PUT operations is the answer is just saying "we give up."
- sofuture 16y ago
  That's an overly simplistic framing of 'NoSQL'. Despite every piece of FUD to the contrary, 'NoSQL' is a stupid name for a set of tools designed to solve an entirely different set of problems. I don't want some data in a relational model. Yes, I could put it there, but I would be doing so solely so that it fits in the relational model. Which is pretty pointless. The fact that the relational model is "sound" doesn't mean that everything belongs in it. Plus, I'm not holding my breath waiting for an "intelligent data store that will be able to translate a fully normalized schema into a high performance, distributed, persistent representation that is queryable by this language". That's the description a mythical database panacea that solves all problems with no downsides. The continual pitting of NoSQL vs SQL is a gross mis-characterization perpetuated out of holy-war fervor, yet based on few facts or even understanding of the differences.
  - moron4hire 16y ago
    Well, when the name is "NoSQL", I think it rather much invites being pitted against its namesake.
    - wlievens 16y ago
      It's not a name everyone in the field is happy with, IIRC.
didtrade 16y ago
<a href="http://www.didtrade.com/>www.didtrade.com http://www.didtrade.com/>www.didtrade.co... Online sell fashion goods,Accept PayPal.cheap replica fashion goods for sale from china free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-suit free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica t-shirts free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-coat free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-pants free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-tops free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children shoes free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica children-boot free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica UGG boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Edhardy boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica LV boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica DG boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Gucci boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica chanel boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica fendi boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Tou`s boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Versace boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica coach boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica juicy boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Burberry boots</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Justin boots</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Dior boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Puma boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica DB bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Burberry bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Suitcase free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica gucci bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Fendi bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Versace bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Prada bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Hermes_7*star free shipping</a>
nlawalker 16y ago
>> The birth of ORM lies in the fact that SQL is ugly and intimidating I disagree. In my opinion, the birth of ORM lies in the fact that a lot of people want to work on problems that have almost nothing to do with SQL but need persistence. They want to spend time working with objects in their domain model and just have persistence that works. So if that's the case, why did ORM even appear? Why didn't everyone just spend time figuring out "NoSQL"/key-value stores/object stores and move away from RDBMS? 1) SQL and relational data stores, as the author himself points out, are trustworthy and standard. People may not like working with them or be intimidated by them, but most people can at least figure out simple joins and things. The relational model may not be the best answer for some things, but it at least gets the job done. 2) Just because I want to work with my domain objects in my application, and just because I'm short-sighted and all I care about at the moment is enabling a business idea or solving an interesting problem with my app, doesn't mean that I won't want to "get answers" from my data in the future. Maybe it won't be me - maybe it'll be another group in my company with more RDBMS knowledge than I have that's interested in data-mining my store, and because I've used an RDBMS, it will work extremely well. I don't think developers are scared of SQL, I think they just don't care about working with it because it doesn't have much to do with what they're interestd in. Maybe ORM isn't a perfect solution, but it lets me have my cake (persistence that gels with my domain model) and eat it too (a relational backend when we need BI and reporting).
- mistermann 16y ago
  I agree. The OP seems to fall into the camp that, if ORM can't replicate everything that you would do in native SQL, then therefore ORM is bad. Which is absolute nonsense of course. I just don't see how the pure SQL people and ORM people are philosophical opponents, other than how ORM tools make dealing with SQL (which is an awesome, proven technology) so much easier, I suppose it could theoretically be a threat to their livelihood. The way I see it, they are partners in the same cause. I'm the same as you, I write applications that need to store and interact with data. The difference between using an ORM or not is like light and day, and for me, this constitutes 90% of my work. Certainly, there are situations where it is just common sense to drop down to raw SQL (and if your ORM doesn't support this, you are screwed), but people like the OP seem to subscribe to the "throw the baby out with the bathwater" philosophy of life....if you can find a single problem with a solution, throw the whole thing out. This is one of those arguments that will never, ever go away. I used to be passionate about the subject, but I don't care much anymore. The anti-ORM people will continue to say it doesn't work (ever), while the pragmatists will continue to use ORM because it does work, and for the edge cases, they will drop down into pure SQL, which most developers know very intimately anyways. On a related topic, how many DBA's have you met that understand SQL, query plans, etc deeply, and have a strong knowledge of database system tables (as well as you do as a developer?) Most DBA's I've met basically follow: http://en.wikipedia.org/wiki/Argument_from_authority http://en.wikipedia.org/wiki/Argument_from_authority
ifesdjeen 16y ago
Well, it's all happening now. First step towards that which I noticed is Moneta (Ruby gem), that is giving you some abstraction over key value stores. I don't think that it's a whole lot of performance overhead and it does let you switch when you realize it's time to. Overall, you may also want to use orm for sakes of interchangeability of your SQL as well, and it certainly gives you advantages. Im working on a project that involves no orm and uses oracle as a primary data store. Though I don't want to install oracle On my machine but repository idea built-in to project doesn't let me use postgre for development. And yet schema creation involves varchar2 that's simply inaccessible in postgre. Its quite easy to fix but I'd expect to have some kind of a fallback.... In any case, it's a good point that key-value storages are not for every problem, but that's quite obvious. someone said that every time you say "nosql", a kitten dies. so, careful there.
jasonkester 16y ago
I've never understood why programmers don't love SQL the language. It's the closest thing you can get to the silly voice interface they use in Sci-Fi: "Computer, give me a list of orders for red sweaters, but skip ones from customers who signed up more than 3 months ago" ... and it will figure out how to get you that list. And the syntax is so simple that you can do pretty much everything you'd ever want with six keywords. The query to get the list above is actually shorter than its English language description. Whenever I see some new ORM come out with its own way of asking for records from a database, a little question mark pops up over my head. Why would you do that? Did you really spend time building something to make your problem harder? Your code less elegant? Why why why? The only thing I can imagine is that people simply don't bother to learn SQL before deciding they don't like it. Too bad too, because writing queries is one of the most enjoyable bits of the software development game.
- pilif 16y ago
  Agreed. Personally, I really like SQL and whenever possible I'm going as much straight SQL skipping strange abstraction in ORM layers. Performance wise too, nothing beats hand-optimizing queries rather than hoping that the ORM of your choice doesn't decide that the particular method of retrieving the total value of a specific order will need one query per line item plus manually calculating the total.
- sjs 16y ago
  Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. [tangent] That's part of the attraction to NoSQL as well. You just serialize your objects to JSON or something else (probably already being done if you target the web). It's simple. Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and you probably want a layer that serializes/deserializes your objects as well. Once you've written that a few times it's boring so you abstract it. ORMs are pretty much inevitable when writing the common web app. ORMs should borrow good things from SQL, like LINQ. Mainstream languages are better now than when SQL was created. I mean, it's not the exact syntax you like right? I prefer writing code rather than preparing and parsing strings. Plus if you ever decide to swap out the backend it's far easier when things are loosely coupled. SQL is akin to JS in the browser in that you need a library to abstract away the implementation differences or you'll be tightly coupled to a specific one. Maybe you don't need to run on all backends simultaneously but options are always nice. It all depends what the task is anyway though.
alrex021 16y ago
> Awkward it may be, but SQL is a lot more succint and readable than multiple lines of API calls or crazy, math-like relational algebra languages. I'd have to totally agree with this. SQL also achieves higher level of abstraction than any of the above. Perhaps, as the author said, there is a chance that SQL (or subset of it) will be used as the query language for No SQL-type back-ends.
niels 16y ago
The NoSQL datastores are aimed at solving scaling issues. The current relational databases are a pain to scale. It's not about hating SQL.
thomasfl 16y ago
If you know just a tiny bit of relation algebra, then sql is not hard at all. I love ActiveRecord, since it makes you mix the DSL and SQL. Hibernate is impressive, but sometimes i miss SQL, and get's frustrated with it's HQL.

125 points by seldo 16y ago

Very good article, I myself have found the "NoSQL" label pointless, when you label something you normally tell what it is, instead of what it's not.

cheald 16y ago
"NoSQL" is generally understood to mean "Not Only SQL", not "SQL is evil, begone foul beast".
- ergo98 16y ago
  >"NoSQL" is generally understood to mean "Not Only SQL" I think that that is a bit of convenient revisionism as it becomes clear that the Emperor is wearing no clothes. There absolutely was a very antagonistic, "this changes EVERYTHING" philosophy behind the movement called NoSQL, and the name is not accidental. Perhaps it was just a bit of trolling to get attention, but in no way was it a live and let live initiative (data tactics that are now bound in "NoSQL" long existed in computer science, since before the days of SQL. They just didn't feel the need to make it a comfortable community of evangelists). It was a "that was yesterday and this is today". Of course things have changed. A bit of realism entered the mindset, so now it's more of a "Heh heh...no bad blood right? We're all good, eh?"
  - mathias_10gen 16y ago
    Actually the name was very much accidental. Read this post by the guy who coined the term: http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.ht... "it was one of 3 or 4 suggestions that I spouted off in the span of like 45 seconds, without thinking."
    - ergo98 16y ago
      >Actually the name was very much accidental. Spur of the moment isn't really accidental, any more than Mel Gibson accidentally said the N-word. There's a bit of a history and a thought process that leads to such a decision.
- mistermann 16y ago
  I disagree that this is the "general understanding".of the term No SQL.
- sbov 16y ago
  That would be NOSQL, not NoSQL

jbarciauskas 16y ago

This article reiterates a fundamental point that object stores quite clearly present less friction during development than relational stores. This is plainly true: your domain object is meant to model the domain, and if you can store it directly that is the best you can hope for. There's a reason there's a whole topic of study and research called "Object-relational impedence mismatch" (http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...) However I think ORMs are too quickly dismissed. In the simplest case, an ORM can appear to be a key-value store at the API level. Of course that is a gross abuse of a relational store, but there's no reason it can't be done. Additionally, the author fails to note that an intelligent ORM can provide a caching layer that improves performance over raw SQL. A more detailed examination of the various patterns to resolve the impedence mismatch, such as active record versus data mapper, ORM caching strategies, and how those compare to a key-value store solution, I think would be a valuable topic of discussion.

seldo 16y ago
If the ORM layer is providing a caching layer on top of the RDBMS, that caching layer is effectively a non-relational store for the data. If that works better, why not use it as the primary store?
- jbarciauskas 16y ago
  Not necessarily - you could store a resultset based on the query and parameters, and if the same query and parameters come within a certain amount of time, you return the whole resultset from the cache. In this scenario, the resultset could contain a filtered list, aggregate functions, etc, that are more difficult to replicate in a key-value store.
  - gaius 16y ago
    That is exactly what Oracle Coherence (nee Tangosol) does.
- Aaronontheweb 16y ago

RyanMcGreal 16y ago

>It triumphed over other query languages not because it was particularly great (though it was easier to read), but because it was standard. Isn't that a tautology?

DrJokepu 16y ago
Not all standards are popular. Microsoft's OOXML, for example, is technically an ECMA and ISO standard but I wouldn't call it exactly popular (even though it's widely used due to Office's market position). Because being a standard does not always imply popularity, the statement is not a tautology.
btilly 16y ago
No. Standard just meant that it worked in lots of different places. It didn't mean that it was the only option, first option, or best option. But, by being standard, it became a lowest common denominator that people largely stuck to. The links at http://en.wikipedia.org/wiki/Query_language http://en.wikipedia.org/wiki/Query_language include many of the competitors to SQL. In particular look at Datalog, ERROL, ISBL, and QUEL.

kunley 16y ago

This article has its amount of religious bias and wishful thinking. The author tries to establish his base on a fact that SQL is all about relational algebra and it's the right paradigm to query your data. While I agree with the latter, the author (and lots of other people) seems to forget that SQL is a dumbed-down-aimed-to-mediocre-programmers contraption inspired by relational algebra, but not really properly relational! It's really far from what Codd had in mind. If you read the history of early SQL dialects and DB2 vs Oracle competition it's clear that SQL was marketed as a language everyone can program in (thus the stupid imitation of a natural language) -- we know in XXI century that this is a bs... I'd say that SQL is a COBOL of relational algebra...

Devilboy 16y ago
Are there any (more suitable) alternatives to SQL?
- silentbicycle 16y ago
  The K/Q people (http://kx.com/ http://kx.com/) have one interesting interpretation. It's quite expensive for production use* and uses an APL dialect as a query language, which tends to scare away a lot of developers. I'm utterly fascinated with it, albeit from a distance. (J is cool, too, but doesn't come bundled with a high-end in-memory database.) * I've heard it can run $60k/CPU. It's designed for realtime stock data mining (https://cs1.cs.nyu.edu/cs/faculty/shasha/papers/hpts.pdf https://cs1.cs.nyu.edu/cs/faculty/shasha/papers/hpts.pdf), so they get away with it.
  - mistermann 16y ago
    Can you give us some syntax examples?
    - Devilboy 16y ago
      If it's anything like APL you probably don't want to see it...
    - 16y ago

rlpb 16y ago

SQL always seemed to me to be the way it is in order to lend itself to optimisation at the database end. It is easy to look at any SQL query (that doesn't use subselects) and see how the DB engine can efficiently execute it by walking down the appropriate indexes. Try doing that with an ORM or a key/value store.

jbarciauskas 16y ago
Can you elaborate the issues an ORM has in dealing with indexes? An ORM can be made aware of indexes via, e.g., annotations or other declarative syntax, and prefer those when joining and filtering, and will probably be more consistent about it than a human developer.
- rlpb 16y ago
  I didn't mean that ORMs have problems with indexes; just with efficiency: because you can tell the SQL engine what you want done instead of having to bring the data to the code (in particular when iteration can be folded into the query).
  - jbarciauskas 16y ago
    Yes; but even this only goes so far. Execution plans change based on statistics collected by the query optimizer. SQL was invented because query optimizers do a better job than humans. The same is commonly true for ORMs.

JoelMcCracken 16y ago

I don't believe that there really are all of these developers around who lack knowledge of SQL. I learned SQL while I was learning to program. My very first (real?) program was a php hit counter that wrote to a hits.txt on the server. My second one was a guestbook that used mysql. My third one was a basic hierarchical forum. I wasn't a wizard, I was just a kid reading a book, bored at the Pennsylvania Farm Show. Thus, I have spent my fair share of time working with sql queries in php code. Guess what? The SQL queries weren't very hard at all. However, SQL Queries had almost nothing to do with actual using SQL itself. 90% of the code written in such a project is guaranteed to be cruft code surrounding the sql queries. Special cases abound. The difference between "column = $val" and "column is null" is so painful that I just can't imagine going through that anymore. And that's just the first example! What does "" mean if you save it in a db column? Should you save it as a null value, or as a string with zero characters? I just don't care about this at all, and you'd have to be a damned fool to think that I would ever willingly go back to doing that bollocks. I already have my in-memory data structure laid out. ORM lets me keep from worrying about it it again (at least not nearly to the detail I would with SQL). With an ORM, 90% of the database code that I used to have to deal with is simply a non issue.

seldo 16y ago
I think you are misunderstanding the article; it's not that object models for data are bad, it's that mapping them to a relational store is inefficient and pointless. The point against ORMs is not that they have inferior APIs -- in fact I say how bad SQL is. The point is that they wrap quite nice APIs around an inappropriate data store. If you have an object-like in-memory data structure, why not use an object store and have it in your data as well? The relational nature of your store is working against you. If your ORM exists to keep 90% of the database code hidden, why not dispense with the RDBMS entirely and lose that useless 90%?
- mistermann 16y ago
  Maybe because it makes that 90% legacy code useable?
silentbicycle 16y ago

ignu 16y ago

"The birth of ORM lies in the fact that SQL is ugly and intimidating" The notion that people steer away from SQL because it is intimidating is absurdly ignorant. The communities that embrace ORMs and NoSQL are the ones who are learning and creating new things all the time. No one's first language is Ruby, they didn't learn node.js in college, they didn't take an (N)Hibernate certification course. They learn in their free time! Meanwhile, if you were good in SQL 12 years ago then you still are today! Smarter people than me have written on these subjects, but for me, the answer is simple. As Fowler says, the most pervasive smell in software is duplication. If I litter my code with all the CRUD SQL (even worse with sprocs that contain column sizes) then my software is quite brittle.

ora600 16y ago
If you little all your code with CRUD, your code is horrible indeed. If I hard code filenames all over my code, I also have horrible code. This doesn't mean that files and file names are a problem or that they caused duplication. The normal (I hope) practice is to this in terms of transactions or activities and create functions that wrap those activities. SQL should only live within those functions that provide a logical interface to the DB. Its called TAPI or XAPI (transaction API). Think of it as your own domain specific ORM.
- gnaritas 16y ago
  > SQL should only live within those functions that provide a logical interface to the DB. Its called TAPI or XAPI (transaction API). Think of it as your own domain specific ORM. Which is generally repetitive and full of duplication, exactly the thing that drives people to use ORM's in the first place. It doesn't matter that it's isolated into a separate layer, it's still more manual work than an ORM.
  - ora600 16y ago
    It is more work than ORM, but if efficient access to data is an important part of your application, it seems to be extra work that brings benefits. At least that has been my experience. I'm not clear on why this layer has to be repetitive and full of duplication.

derefr 16y ago

These arguments make me feel like DBMS technology is insufficiently distinguishable from magic. Databases do two things: they persist data, and they answer queries about data. Neither of those requirements put any restrictions on how they serialize data. Relational storage, object storage, document-based storage, key-value storage, graph-based storage, etc.—it all just seems like different optimizations on the same "real" data, something that should be abstracted away from the database administrator entirely. Why can't we just have a database that gets fed a normalized, relational-algebra-style model of the data, but then profiles the kinds of queries fed to it, and the kinds of data given, and builds whatever kind of denormalized tables/indexes/k-v stores are optimal for your usage patterns, using a Relational, or Object DB, or Graph DB, etc. engine when each is appropriate (perhaps firing them off in parallel and returning whichever answer comes first, killing the other threads)? Is this something anyone is working on?

seldo 16y ago
If you can build this, please, please let me buy it. Or preferably invest in it.
randallsquared 16y ago
This sounds suspiciously like a sufficiently smart compiler.
- derefr 16y ago
  I was mostly thinking of the profile-driven optimization of the HotSpot JVM—something that was repeatedly called a Sufficiently Smart Compiler, until it happened to actually work.
panic 16y ago
Apple's Core Foundation data structures do this sort of "usage-based implementation selection," though in a much simpler context: (see e.g. http://ridiculousfish.com/blog/archives/2005/12/23/array/ http://ridiculousfish.com/blog/archives/2005/12/23/array/). I'm not sure why this technique isn't more widespread.
deleted 16y ago

forkandwait 16y ago

In defense of SQL syntax, I think that, in its very constrained domain, it models table / set operations with the best balance of expressivenes, readability, and generality today. At least compared to any other syntax I have seen, including ORM's. We take our old friends for granted until they are gone, and I have had to work with a number of data environments without SQL and its lack was sorely missed. The SAS community was overjoyed at the addition of PROC SQL for this reason, and the goofiness one has to do in R/ SPLUS is quite unpleasant.

ora600 16y ago
Even in its own domain, SQL sacrificed parsing for "user friendly" English-like appearance. SQL error messages are very unhelpful in every DB. You can't easily debug misbehaving queries and there are no tools to help. There is even a lack of indentation standard. Fixing very long queries that fetch the wrong results is something I've been doing daily for the past 10 years of my life. It is not easy, and I believe the language is to blame for a large part of the difficulty. In some aspects of doing unexpected things with no warning - it is worse than C.
- jerf 16y ago
  Further: SQL is not composable. If I have a fragment of SQL in my hand, there is no reasonable way to insert that into a larger expression. You can further tell this is a problem by the way any nontrivial SQL function degenerates into an enormous hellstorm of SQL that any Haskell programmer will see as full of redundancy. This is because SQL is almost immune to abstraction. (I have to specify the "Haskell programmer" bit because of the characteristics of this sort of language is that working in it directly for a long time causes you to think natively in that language and thereby miss the opportunities for abstraction that you no longer see. FWIW, Erlang also bothers me this way.) Yes, the "bad programmer" issue is in play too, but as a good programmer who has tried to write good stored procedures and has experience in numerous other languages I can not help but notice how much SQL fights me on this front. SQL is very difficult to debug in general, which combines rather poorly with the previous characteristic. Perhaps there are nonstandard extensions in Oracle that make it easier but there's nothing I know of in the core language. SQL has fooled people into thinking it is equivalent to the Relational Model, when in fact as kunley points out elsewhere it is merely inspired by it. SQL dates from the 1970s and it shows. There are syntax quirks around every corner. The behavior of NULL is sensible, but it is merely one of several sensible choices and there are reasons why the SQL choice is not the one that has "won". Why is "value IN ()" a syntax error? It's perfectly reasonable. What's with the syntactic drama around subselects, which ought to be a core part of the better language that we really ought to be using? (A language in which the equivalent is probably going to be so simple we won't even believe people had a special syntax for it.) What's with the rigid specification of the order of GROUP BY and ORDER BY and everything else, when those should simply be instances of some sort of combinator that applies in order, in a sensible manner. Why is SELECT used both for data queries and aggregate queries when in fact the two operations are so different they should have entirely different keywords? Why is it so hard to mix an aggregate and non-aggregate query together when it's obvious to me exactly what I want? Why can't my columns contain tables themselves, recursively? The fact that there are databases that can do this proves it's not impossible. SQL needs to be replaced by a combinator-based language that backs to a richer data store that is more sensible, both from a relational model point of view and from a recursive point of view. LINQ points the way, but still is hobbled by LINQ-to-SQL being the flagship LINQ product. (And I don't think it's complete as-is.)

gfodor 16y ago

I think he's got it backwards. He says SQL is a great language in front of a crappy model, the relational model. I think SQL is simply a limited language in front of a great model. The NoSQL folks are throwing out both, so I guess that's "the only way to be sure." Going to be fun seeing them re-invent the wheel for the next 5 years. What we need is a more elegant, flexible language instead of SQL for data retrieval. SQL++, since the relational model is sound. Beyond that, we need a more intelligent data store that will be able to translate a fully normalized schema into a high performance, distributed, persistent representation that is queryable by this language. There's no reason in theory this can't happen, its just hard. To think that dropping us down to GET and PUT operations is the answer is just saying "we give up."

sofuture 16y ago
That's an overly simplistic framing of 'NoSQL'. Despite every piece of FUD to the contrary, 'NoSQL' is a stupid name for a set of tools designed to solve an entirely different set of problems. I don't want some data in a relational model. Yes, I could put it there, but I would be doing so solely so that it fits in the relational model. Which is pretty pointless. The fact that the relational model is "sound" doesn't mean that everything belongs in it. Plus, I'm not holding my breath waiting for an "intelligent data store that will be able to translate a fully normalized schema into a high performance, distributed, persistent representation that is queryable by this language". That's the description a mythical database panacea that solves all problems with no downsides. The continual pitting of NoSQL vs SQL is a gross mis-characterization perpetuated out of holy-war fervor, yet based on few facts or even understanding of the differences.
- moron4hire 16y ago
  Well, when the name is "NoSQL", I think it rather much invites being pitted against its namesake.
  - wlievens 16y ago
    It's not a name everyone in the field is happy with, IIRC.

didtrade 16y ago

<a href="http://www.didtrade.com/>www.didtrade.com http://www.didtrade.com/>www.didtrade.co... Online sell fashion goods,Accept PayPal.cheap replica fashion goods for sale from china free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-suit free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica t-shirts free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-coat free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-pants free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children-tops free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Children shoes free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica children-boot free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica UGG boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Edhardy boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica LV boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica DG boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Gucci boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica chanel boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica fendi boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Tou`s boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Versace boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica coach boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica juicy boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Burberry boots</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Justin boots</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Dior boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Puma boots free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica DB bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Burberry bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Suitcase free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica gucci bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Fendi bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Versace bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Prada bag free shipping</a> <a href="http://www.didtrade.com/>Replica http://www.didtrade.com/>Replica Hermes_7*star free shipping</a>

nlawalker 16y ago

>> The birth of ORM lies in the fact that SQL is ugly and intimidating I disagree. In my opinion, the birth of ORM lies in the fact that a lot of people want to work on problems that have almost nothing to do with SQL but need persistence. They want to spend time working with objects in their domain model and just have persistence that works. So if that's the case, why did ORM even appear? Why didn't everyone just spend time figuring out "NoSQL"/key-value stores/object stores and move away from RDBMS? 1) SQL and relational data stores, as the author himself points out, are trustworthy and standard. People may not like working with them or be intimidated by them, but most people can at least figure out simple joins and things. The relational model may not be the best answer for some things, but it at least gets the job done. 2) Just because I want to work with my domain objects in my application, and just because I'm short-sighted and all I care about at the moment is enabling a business idea or solving an interesting problem with my app, doesn't mean that I won't want to "get answers" from my data in the future. Maybe it won't be me - maybe it'll be another group in my company with more RDBMS knowledge than I have that's interested in data-mining my store, and because I've used an RDBMS, it will work extremely well. I don't think developers are scared of SQL, I think they just don't care about working with it because it doesn't have much to do with what they're interestd in. Maybe ORM isn't a perfect solution, but it lets me have my cake (persistence that gels with my domain model) and eat it too (a relational backend when we need BI and reporting).

mistermann 16y ago
I agree. The OP seems to fall into the camp that, if ORM can't replicate everything that you would do in native SQL, then therefore ORM is bad. Which is absolute nonsense of course. I just don't see how the pure SQL people and ORM people are philosophical opponents, other than how ORM tools make dealing with SQL (which is an awesome, proven technology) so much easier, I suppose it could theoretically be a threat to their livelihood. The way I see it, they are partners in the same cause. I'm the same as you, I write applications that need to store and interact with data. The difference between using an ORM or not is like light and day, and for me, this constitutes 90% of my work. Certainly, there are situations where it is just common sense to drop down to raw SQL (and if your ORM doesn't support this, you are screwed), but people like the OP seem to subscribe to the "throw the baby out with the bathwater" philosophy of life....if you can find a single problem with a solution, throw the whole thing out. This is one of those arguments that will never, ever go away. I used to be passionate about the subject, but I don't care much anymore. The anti-ORM people will continue to say it doesn't work (ever), while the pragmatists will continue to use ORM because it does work, and for the edge cases, they will drop down into pure SQL, which most developers know very intimately anyways. On a related topic, how many DBA's have you met that understand SQL, query plans, etc deeply, and have a strong knowledge of database system tables (as well as you do as a developer?) Most DBA's I've met basically follow: http://en.wikipedia.org/wiki/Argument_from_authority http://en.wikipedia.org/wiki/Argument_from_authority

ifesdjeen 16y ago

Well, it's all happening now. First step towards that which I noticed is Moneta (Ruby gem), that is giving you some abstraction over key value stores. I don't think that it's a whole lot of performance overhead and it does let you switch when you realize it's time to. Overall, you may also want to use orm for sakes of interchangeability of your SQL as well, and it certainly gives you advantages. Im working on a project that involves no orm and uses oracle as a primary data store. Though I don't want to install oracle On my machine but repository idea built-in to project doesn't let me use postgre for development. And yet schema creation involves varchar2 that's simply inaccessible in postgre. Its quite easy to fix but I'd expect to have some kind of a fallback.... In any case, it's a good point that key-value storages are not for every problem, but that's quite obvious. someone said that every time you say "nosql", a kitten dies. so, careful there.

jasonkester 16y ago

I've never understood why programmers don't love SQL the language. It's the closest thing you can get to the silly voice interface they use in Sci-Fi: "Computer, give me a list of orders for red sweaters, but skip ones from customers who signed up more than 3 months ago" ... and it will figure out how to get you that list. And the syntax is so simple that you can do pretty much everything you'd ever want with six keywords. The query to get the list above is actually shorter than its English language description. Whenever I see some new ORM come out with its own way of asking for records from a database, a little question mark pops up over my head. Why would you do that? Did you really spend time building something to make your problem harder? Your code less elegant? Why why why? The only thing I can imagine is that people simply don't bother to learn SQL before deciding they don't like it. Too bad too, because writing queries is one of the most enjoyable bits of the software development game.

pilif 16y ago
Agreed. Personally, I really like SQL and whenever possible I'm going as much straight SQL skipping strange abstraction in ORM layers. Performance wise too, nothing beats hand-optimizing queries rather than hoping that the ORM of your choice doesn't decide that the particular method of retrieving the total value of a specific order will need one query per line item plus manually calculating the total.
sjs 16y ago
Part of the attraction to ORMs is that you just define your classes and essentially freeze-dry and thaw objects with a couple of lines of code. [tangent] That's part of the attraction to NoSQL as well. You just serialize your objects to JSON or something else (probably already being done if you target the web). It's simple. Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and you probably want a layer that serializes/deserializes your objects as well. Once you've written that a few times it's boring so you abstract it. ORMs are pretty much inevitable when writing the common web app. ORMs should borrow good things from SQL, like LINQ. Mainstream languages are better now than when SQL was created. I mean, it's not the exact syntax you like right? I prefer writing code rather than preparing and parsing strings. Plus if you ever decide to swap out the backend it's far easier when things are loosely coupled. SQL is akin to JS in the browser in that you need a library to abstract away the implementation differences or you'll be tightly coupled to a specific one. Maybe you don't need to run on all backends simultaneously but options are always nice. It all depends what the task is anyway though.

alrex021 16y ago

> Awkward it may be, but SQL is a lot more succint and readable than multiple lines of API calls or crazy, math-like relational algebra languages. I'd have to totally agree with this. SQL also achieves higher level of abstraction than any of the above. Perhaps, as the author said, there is a chance that SQL (or subset of it) will be used as the query language for No SQL-type back-ends.

niels 16y ago

The NoSQL datastores are aimed at solving scaling issues. The current relational databases are a pain to scale. It's not about hating SQL.

thomasfl 16y ago

If you know just a tiny bit of relation algebra, then sql is not hard at all. I love ActiveRecord, since it makes you mix the DSL and SQL. Hibernate is impressive, but sometimes i miss SQL, and get's frustrated with it's HQL.