More Rails Wisdom
Rails ActiveRecord blatantly ignores a huge percentage of RDBMS capabilities. Therefore, since AR doesn't care about SQL, neither should you ! SQL is just another annoyance like manual garbage collection, eventually we wont need it.
Did I misinterpret something ?
No really, SQL is so difficult, lets just do away with it. Just store everything in RAM. Since of course nobody ever thought of this before.
I propose that Rails drop all SQL support right now, and just replace everything with a big in-memory hashmap that writes to files. Hey, we can even use this thing ! Rumor has it that DBM was invented during the after sessions of RailsConf 2005 anyway, after years of everyone being forced to toil away using SQL just because nothing else was available.
If the current Rails groupthink is that SQL/RBDMS is just a big hack, they should abandon it, and show us what better solution they come up with. The rest of the world knows that language-specific OODBMS is a pretty tired old idea.
Andreas Krey:
"Did I misinterpret something?"
Yep. SQL isn't RDBMS. Unfortunately the only existing SQL is somewhat like XML: Utterly unsuitable for most places where it is used but the only thing everybody seems to be able agree to. It's not only that worse is better but also that the worse will never allow the better to rise. The only way I can imagine this to happen is a hybrid that can be used via SQL but also allows programmatical access via language objects.
It will no longer be language-specific OODBMS, but VM-specific (JVM/CLR), by the way.
27 May 2007, 5:51 amzzzeek:
It’s not only that worse is better but also that the worse will never allow the better to rise.
Support this statement. SQL is not without its problems. But I would posit that it is an excellent platform for storing and managing raw data, most importantly in a simple and language / platform / architecture agnostic way, not to mention that decades of work have gone into making it scale. When you start all over again with a relational engine hardcoded to a particular programming language (VM is a slight improvement but not by much) and an overly-high level idea of how stored entities should look (such as through over-engineered type systems or tuple structures), concessions are made from the start in favor of immediate perceived convenience.
If you want to plug another agnostic relational language, be my guest. I've no problem with attempts to improve upon relational querying languages as long as they don't become "we have to express an object model directly, optimized/hardwired to pet programming language X's idea of what objects are".
My primary beef with the "SQL is bad" crowd, which of course do not include the folks I linked to above, is that a lot of them just don't know SQL very well, and they rely on the inadequacy of ORMs like ActiveRecord to make the argument that SQL and relational DB's overall are the problem (DHH was mentioned in one of those posts as preferring plain file-based hashes. Theres nothing wrong with file-based hashes, but they are not enough for most situations). IMHO, a large chunk of this particular crowd has little direct experience with SQL other than graphical tool access with the occasional hand-written query. So they seek to throw the whole thing out in favor of the "bag of objects" type of solution.
27 May 2007, 11:00 amAndreas Krey:
Well, for that crowd, SQL isn't actually bad. They want to express themselves im Ruby and not in structured queries, thus SQL isn't what they really want. They sometimes need to access existing data, and they always need persistence, and 'SQL databases' are the only generally accepted way of doing so. And then it's not easy to implement any persistence correctly, let alone performantly, in ruby, or both. Good situation for getting grumpy people.
My personal gripe with SQL is that it is not a good match to any programming language, and that performance actually dictates to take some severe shortcuts which makes the whole transaction model a bit moot. I need to cache in the applications, and need to take care that other interactions with the database do not break the assumptions with which I do cache.
Currently I have a case where for each new data item I want to insert I need to take a few other rows, recalculate values, and insert the new data, and insert or update a summary row. If I wouldn't cache, I'd need to fetch, compute, and reinsert. It would be much more efficient to do the process completely within the database, but it is quite hard to do the computation in SQL, and it kills the database performance (we tried). Instead we cache the data, and the input processing isn't ACID anymore.
I think Sybase did something in that direction by allowing Java within the SQL server but that does not open up the ways the data can get into the server in the first place, or how you can communicate with the outside.
I'd personally like to have some more-or-less object oriented programming capability within the database, plus a proper RPC mechanisms into it.
And I don't think that the ORMs are to blame. I would rather write depbudget = emp.getdepartmemt ().getbudget () than think up the query, wrangle with the host parameter interface of the day, and catch the case that the result set contains more than one row or column.
But the same goes for within the database. Why can't I say emp->dep instead of (SELECT dep FROM emps WHERE id = emp)? It seems that SQL focuses a bit much on dealing with whole tables and makes it hard to work with single values or rows.
The world has evolved a bit since SQL was invented, but obviously not enough to let it make place for something better, be that SQL with better integration with the (OO) world, some OODBMS, or something in between. The (ok, my) problems are not with the relational model per se. But hand-coded sql for the simple stuff is almost as out as hand-managed memory.
Possibly using SQL for the nonsimple stuff is going to be a lost art as is using s-exprs for structured data.
27 May 2007, 4:59 pmzzzeek:
Currently I have a case where for each new data item I want to insert I need to take a few other rows, recalculate values, and insert the new data, and insert or update a summary row. If I wouldn’t cache, I’d need to fetch, compute, and reinsert. It would be much more efficient to do the process completely within the database, but it is quite hard to do the computation in SQL, and it kills the database performance (we tried). Instead we cache the data, and the input processing isn’t ACID anymore.
I assume you mean by its not ACID that the data you're operating upon, because its cached, was fetched outside of the scope of the transaction. Why not refresh those rows which are needed within the transaction ? Also the reason you need to cache is just because there is a process boundary by which the data is being fetched; any DBMS, OO or not, would have this issue once you move to a distributed model...and its not a general-case solution to require that the entire datastore is just always "in-process" with all business / application logic (the advantages to being "in-process" is a major reason why people are attracted to various in-memory OODBMS solutions in the short term).
And I don’t think that the ORMs are to blame. I would rather write depbudget = emp.getdepartmemt ().getbudget () than think up the query, wrangle with the host parameter interface of the day, and catch the case that the result set contains more than one row or column.
Oh I'm definitely pro-ORM. Being pro-ORM implies being pro-SQL. The philosophy of Object databases are specifically a rejection of ORM.
Possibly using SQL for the nonsimple stuff is going to be a lost art
Yes. Which is why I'd rather the Rails narrative stop picking on SQL, rather than water it down with "you dont need composite primary keys" first, then dishing out hacked up solutions like piggy backing, until finally concluding "well, SQL just sucks".
27 May 2007, 5:26 pmAndreas Krey:
And a big thank for the link to the third manifesto. Turns out that I have one of Date's book sitting on the shelf.
28 May 2007, 7:16 amMartijn Faassen:
Heh, if this is what Giles Bowkett wants (other Rails fans too?), I would like to welcome him to the future: Zope. We've been using an object database for the good part of a decade. No object relational mapper necessary. Just objects. It's transactional. It's clusterable. Welcome to the future.
There are pros and cons to both object databases and relational databases. This is why we're supporting SQLAlchemy in Zope as well.
30 May 2007, 7:18 am