From: Erik Hollensbe <erik@...>
Date: 2008-09-28T13:10:58+09:00
Subject: Re: How to make Ruby _THE_ scripting language of choice, fold in SQLite

John Carter wrote:
> Sure we have adapters that provide access from Ruby to SQL databases,
> but at some primitive level... the query is written as a string, the
> string is fed to a SQL interpreter, the query is optimized by the SQL
> engine and the results returned.

I think the fundamental problem with changing this (and this applies to 
most of the arguments I've seen in this thread) is that if you put the 
burden of getting the data to disk on ruby's doorstep, you're begging 
for incompatibility with other implementations (not everyone is going 
to, or should have to, use ruby for everything).

The alternative is that ruby generates some kind of intermediate 
language that's sent to the database... We *already* have this, SQL. SQL 
has fundamental problems that are largely borne by the competition in 
RDBMSs out there, but it works, it's not *that* hard to generate and 
it's *nice* to ensure your database interface isn't causing you trouble. 
Anyone that's attempted to write bindings against libdb[2-4]? will 
understand that very well. Additionally, while many think of ORMs when 
tackling this problem, there are plenty of (perhaps advanced) reasons to 
skip the ORM and write the query manually. Not everything in a database 
is or even can be represented by the relationships that most ORMs 
provide, and "not everything" gets considerably larger in size when 
performance is an issue.

I guess what I'm saying is, the problems really don't surround the 
relationship between ruby and sql, or even ruby and the database, as 
much as they involve the inherent inability of SQL to handle new 
features and remain compatible with the specification that defines it. 
It's probably better handled there.
-- 
Posted via http://www.ruby-forum.com/.