Object/Relational Mapping is the Vietnam of Computer Science

ruby-talk
1

I have searched around, but I very rarely find any mention of Ruby
with OO databases. YAML might work as a database, but I am hoping for
something more like db4o.com's GPL database engine.

Does anyone attempt Ruby with something like db4o.com's oo database engine?

I personally think that relational storage is evil. It was built in a
time where computers were much slower and much dumber, but we have not
gotten any smarter. For transactional databases, it attempted to
optimize speed and CRUD functions. For datawarehousing and business
intelligence, relational databaes serve no purpose. Has anyone dealt
with relational star and constellation schemas for datawarehouses? An
oo structure would suit business intelligence software much better.
Ruby on Rails only masks an underlying problem.

Reference that inspired the subject's title:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
http://www.odbms.org/download/031.01%20Neward%20The%20Vietnam%20of%20Computer%20Science%20June%202006.PDF
(pdf from odbms.org)
Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.

2

You could describe ORM as masking a problem or you could call it interfacing smartly.
The problem with OO databases is that they're notoriously difficult to create and use. Perhaps not so much when only one process uses it, but quite a mess when you have many queries.
I would argue that part of the problem is SQL being very unlike any non-database programming language. Building a database from the ground up, in an OOP language like Ruby is a fascinating idea but not for the squeamish or subgenius. Perhaps one of Matsumoto-san's coworkers, or Mr. DeNatale (a big Smalltalker) could address the concept better.

···

On Mar 21, 2007, at 12:29 AM, Demetrius Gallitzin wrote:

I have searched around, but I very rarely find any mention of Ruby
with OO databases. YAML might work as a database, but I am hoping for
something more like db4o.com's GPL database engine.

Does anyone attempt Ruby with something like db4o.com's oo database engine?

I personally think that relational storage is evil. It was built in a
time where computers were much slower and much dumber, but we have not
gotten any smarter. For transactional databases, it attempted to
optimize speed and CRUD functions. For datawarehousing and business
intelligence, relational databaes serve no purpose. Has anyone dealt
with relational star and constellation schemas for datawarehouses? An
oo structure would suit business intelligence software much better.
Ruby on Rails only masks an underlying problem.

Reference that inspired the subject's title:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
http://www.odbms.org/download/031.01%20Neward%20The%20Vietnam%20of%20Computer%20Science%20June%202006.PDF
(pdf from odbms.org)
Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.

3

I have searched around, but I very rarely find any mention of Ruby
with OO databases. YAML might work as a database, but I am hoping for
something more like db4o.com's GPL database engine.

That's usually because OO databases aren't worth the code they're
written in for most purposes. I've written about this extensively and
recently; I suggest you search for it.

Does anyone attempt Ruby with something like db4o.com's oo database
engine?

Someone probably has, although it's likely a waste of time.

I personally think that relational storage is evil.

Then you're either ignorant or a fool. I hope it's just the former,
because ignorance can be removed with proper education. Relational
databases are a more natural and flexible way of storing data that has
value beyond a single program than any hierarchical database will ever
be (and both OO and XML databases are hierarchical databases, make no
mistake about it!).

Object databases are fixed to a single representation of data; in
reality, there are many ways to view data and so a far more flexible
storage format is useful and necessary. Only people who don't understand
data modelling (and *as such* also don't understand object modelling)
would dismiss everything that Codd taught about data, relations, and
relational algebra (set theory, basically), no matter how badly the
current crop of SQL databases actually implement what he outlined.

It was built in a time where computers were much slower and much
dumber, but we have not gotten any smarter.

You're incorrect on both your history and your assessment.

For transactional databases, it attempted to optimize speed and CRUD
functions.

Again, this is incorrect. Relational algera are about set operations on
data. SQL models this badly, but it allows for better data combination
than any single OO model will ever allow.

For datawarehousing and business intelligence, relational databaes
serve no purpose. Has anyone dealt with relational star and
constellation schemas for datawarehouses? An oo structure would suit
business intelligence software much better.

This is completely incorrect. A single given application or query may
work better with a particular object model, but the whole set of
applications that may run on databases are far better served by flexible
models. If I can only access orders through customers, then I have
exponentially increased the amount of work I must perform to find out
which customers have ordered a particular line item.

Ruby on Rails only masks an underlying problem.

This is correct, but only to the extent that Rails protects people from
proper data modelling experience. Integration databases (cf Fowler) may
be out of favour in Rails (in favour of application databases) but that
doesn't mean that an application database may not be used in an
integration fashion in the future as people find it necessary to do
analysis on what is in the application database.

Reference that inspired the subject's title:
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

I don't see any value in this article at all, having worked in the real
world with such problems. The solution is to have something that parses
your DDL or database structure and generates your statically typed
language, or work with a smarter language, like Ruby and a smart ORM
mapper if you want automatic mapping (such as ActiveRecord or Og).
Sometimes, you don't and a custom approach is better.

An OO database is almost never the answer to anything. An XML database
is even less likely to be an answer.

-austin

···

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

4

If you're interested I have written a Ruby OODB which uses an RDBMS as
a storage back-end. It's called "Normal Ivy" or just "Norma" for
short. It's just a prototype, at this point, which I wrote to ensure
my idea would work. It does. But I haven't the time to polish it into
a solid project. Of course, it will never be as efficient as a
straight RDBMS, but it would certainly work well for many database
needs. And since it uses a relational database on the back-end, many
of Austin's criticisms can be countered through the use of VIEWS.

T.

···

On Mar 20, 11:29 am, "Demetrius Gallitzin" <gallit...@gmail.com> wrote:

I have searched around, but I very rarely find any mention of Ruby
with OO databases. YAML might work as a database, but I am hoping for
something more like db4o.com's GPL database engine.

Does anyone attempt Ruby with something like db4o.com's oo database engine?

I personally think that relational storage is evil. It was built in a
time where computers were much slower and much dumber, but we have not
gotten any smarter. For transactional databases, it attempted to
optimize speed and CRUD functions. For datawarehousing and business
intelligence, relational databaes serve no purpose. Has anyone dealt
with relational star and constellation schemas for datawarehouses? An
oo structure would suit business intelligence software much better.
Ruby on Rails only masks an underlying problem.

Reference that inspired the subject's title:http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science...http://www.odbms.org/download/031.01%20Neward%20The%20Vietnam%20of%20\.\.\.
(pdf from odbms.org)
Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.

5

This is the droid your looking for:

  http://en.wikipedia.org/wiki/F-logic

T.

6

I am interested in several things.

1) Enterprise integration. Trying to put two relational database
applications together costs as much effort as building one relational
database application. This falls under the work of William McCarthy
(Ph.D.), REA modeling, and Pavel Hruby (Ph.D) pattern-based enterprise
structures {now sold to Microsoft}. Putting data into normalized form
seems to put things into unique patterns that are painful to integrate
(with someone else's project). I look at two ERD diagrams for two
applications, and then I'm told to make them work nicely together.

2) Business Analysis (OLAP and Data Mining) -- Decision support is
interested in analyzing rather than processing data. Normalized data,
to me, seems all about processing data. As the purpose of data
analysis is to examine and uncover the redundancies in data, the
uniqueness constraints placed on the relational model by the
normalization process are not desirable for decision support (Roiger
and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page
182). To me, it means that transaction databases in normalized form
aren't structured well for OLAP or Data Mining type functions.

When you have business models and you're forced to think in terms of
Codd's normalized form, it seems to kill the agile environment. I
think in business terms, and then have to restructure the data into
something foreign to the business....and a layer of maintainability
and complexity above the business itself?

Even if OO databases are flawed, I'd rather be able to think OO, store
OO, and model things as OO. Yeah, maybe a Smalltalk guy can help. :slight_smile:

···

On 3/21/07, Austin Ziegler <halostatue@gmail.com> wrote:

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
> I have searched around, but I very rarely find any mention of Ruby
> with OO databases. YAML might work as a database, but I am hoping for
> something more like db4o.com's GPL database engine.

That's usually because OO databases aren't worth the code they're
written in for most purposes. I've written about this extensively and
recently; I suggest you search for it.

> Does anyone attempt Ruby with something like db4o.com's oo database
> engine?

Someone probably has, although it's likely a waste of time.

> I personally think that relational storage is evil.

Then you're either ignorant or a fool. I hope it's just the former,
because ignorance can be removed with proper education. Relational
databases are a more natural and flexible way of storing data that has
value beyond a single program than any hierarchical database will ever
be (and both OO and XML databases are hierarchical databases, make no
mistake about it!).

Object databases are fixed to a single representation of data; in
reality, there are many ways to view data and so a far more flexible
storage format is useful and necessary. Only people who don't understand
data modelling (and *as such* also don't understand object modelling)
would dismiss everything that Codd taught about data, relations, and
relational algebra (set theory, basically), no matter how badly the
current crop of SQL databases actually implement what he outlined.

> It was built in a time where computers were much slower and much
> dumber, but we have not gotten any smarter.

You're incorrect on both your history and your assessment.

> For transactional databases, it attempted to optimize speed and CRUD
> functions.

Again, this is incorrect. Relational algera are about set operations on
data. SQL models this badly, but it allows for better data combination
than any single OO model will ever allow.

> For datawarehousing and business intelligence, relational databaes
> serve no purpose. Has anyone dealt with relational star and
> constellation schemas for datawarehouses? An oo structure would suit
> business intelligence software much better.

This is completely incorrect. A single given application or query may
work better with a particular object model, but the whole set of
applications that may run on databases are far better served by flexible
models. If I can only access orders through customers, then I have
exponentially increased the amount of work I must perform to find out
which customers have ordered a particular line item.

> Ruby on Rails only masks an underlying problem.

This is correct, but only to the extent that Rails protects people from
proper data modelling experience. Integration databases (cf Fowler) may
be out of favour in Rails (in favour of application databases) but that
doesn't mean that an application database may not be used in an
integration fashion in the future as people find it necessary to do
analysis on what is in the application database.

> Reference that inspired the subject's title:
> http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

I don't see any value in this article at all, having worked in the real
world with such problems. The solution is to have something that parses
your DDL or database structure and generates your statically typed
language, or work with a smarter language, like Ruby and a smart ORM
mapper if you want automatic mapping (such as ActiveRecord or Og).
Sometimes, you don't and a custom approach is better.

An OO database is almost never the answer to anything. An XML database
is even less likely to be an answer.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

7

has anybody used CACHE with ruby... it the best of both worlds and
knocks the pants
in performance off most relationals and it's reliable.... i am really
curious...
is it USA thing (against OO databases) because European Trade Schools
CACHE is required learning... i've bought the only English translated
text book
authored by all German Professors... OO db design has to be in the
database for better design thoroughness just as it accepted elsewhere in
computer science. To topdown OO unit test the whole system and not just
the ruby front end is better and more consisent....

···

--
Posted via http://www.ruby-forum.com/.

8

Anyone have any comments / experience with "associative" databases like:
    http://www.associativesolutions.com/relavance.php
    http://www.lazysoft.com/technology_sentences.htm

···

On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:

That's usually because OO databases aren't worth the code they're
written in for most purposes. I've written about this extensively and
recently; I suggest you search for it.

> I personally think that relational storage is evil.

Then you're either ignorant or a fool. I hope it's just the former,
because ignorance can be removed with proper education. Relational
databases are a more natural and flexible way of storing data that has
value beyond a single program than any hierarchical database will ever
be (and both OO and XML databases are hierarchical databases, make no
mistake about it!).

9

Just some random thoughts I had while reading this thread...

I'm curious as to why query language development got hung up on SQL.
I've read a little bit about Tutorial D. Is SQL simply
another example of pre-mature standardization?

What would a Ruby interface to the underlying database engine (indexed
tables) look like? Could it get closer to Tutorial D by bypassing the
standard technique of 'marshaling' requests into SQL statements? Is
the impedance mismatch between Ruby (or any other OO language) and
Codd's relational algebra too great to cross smoothly?

Gary Wright

···

On Mar 20, 2007, at 1:47 PM, Austin Ziegler wrote:

Again, this is incorrect. Relational algera are about set operations on
data. SQL models this badly, but it allows for better data combination
than any single OO model will ever allow.

10

That may be because SQL is not a programming language although it is often mistaken for one. SQL, more precisely the query part of it, *describes* data sets via set operations.

Although there are declarative languages around (IIRC Prolog is one of them) most programming languages are procedural (even OO languages) and so people tend to expect SQL to be similar.

Kind regards

  robert

···

On 20.03.2007 17:55, John Joyce wrote:

I would argue that part of the problem is SQL being very unlike any non-database programming language.

11

Ok. I can stand the SQL love-in no longer. :slight_smile:

Anyone who's actually used db4o:

* Knows it's a perfectly viable solution for the majority of
applications out today as they don't approach it's limits performance,
or storage wise
* Knows it's a simpler database to develop for than generating reams
of mapping files or accepting the limitations of a system like
ActiveRecord
* Knows the *data* is safe because the database is open-source,
exports *very* easily, and no one is about to timebomb the frameworks
* Knows that for many common scenarios the performance will wipe the
floor with many popular RDBMS's

Oh, and "toy" comments are tired. Most developers would probably still
call Ruby a "toy" language. That doesn't mean they know something you
don't. More than likely they're just uninformed and biased. I'd hope
we could do better.

12

1) Enterprise integration. Trying to put two relational database
applications together costs as much effort as building one relational
database application. This falls under the work of William McCarthy
(Ph.D.), REA modeling, and Pavel Hruby (Ph.D) pattern-based enterprise
structures {now sold to Microsoft}. Putting data into normalized form
seems to put things into unique patterns that are painful to integrate
(with someone else's project). I look at two ERD diagrams for two
applications, and then I'm told to make them work nicely together.

Then you're integrating them wrong. If you can't integrate two
databases, integrate two applications through application interfaces.
See the writings of Fowler and, to some degree, of DHH. Sometimes it's
useful to even take an approach where a "third" application is created
(single sign-on, for example). This is not something that is helped
*in the least* with OO databases. Repeat after me: OO databases aren't
a solution to anything but a single problem.

2) Business Analysis (OLAP and Data Mining) -- Decision support is
interested in analyzing rather than processing data. Normalized data,
to me, seems all about processing data. As the purpose of data
analysis is to examine and uncover the redundancies in data, the
uniqueness constraints placed on the relational model by the
normalization process are not desirable for decision support (Roiger
and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page
182). To me, it means that transaction databases in normalized form
aren't structured well for OLAP or Data Mining type functions.

Again, your understanding is wrong. Normalized data is about data
representation. There's *nothing* wrong with the relational model for
decision support or business analysis. There may be problems with the
implementations of SQL databases, but set operations still apply to
business analysis -- and OO databases *still* hurt here because
they're only capable of asking a single question. DSS is all about
asking *lots* of questions in *lots* of different ways to uncover yet
other questions.

When you have business models and you're forced to think in terms of
Codd's normalized form, it seems to kill the agile environment. I
think in business terms, and then have to restructure the data into
something foreign to the business....and a layer of maintainability
and complexity above the business itself?

I think that's a lack of imagination. When I was doing significant
database work, I also thought in business terms. The team that had the
problems with their database were the fools who thought that the
database could be modelled based on the object model. They didn't
think beyond their UI object model, which wasn't the *only* model
necessary in the application (it was a billing application).

Even if OO databases are flawed, I'd rather be able to think OO, store
OO, and model things as OO. Yeah, maybe a Smalltalk guy can help. :slight_smile:

OO databases aren't flawed. They're disastrous.

-austin

···

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

13

I'd never heard of these. The marketing speak sounds like hooey, and
Fabian Pascal quite agrees. Fabian Pascal is, if you will, the Richard
Dawkins of databases. He knows what the hell he's talking about, but
he's an abrasive man who often hurts his own points by his
abrasiveness. Here's three articles:

   http://www.dbdebunk.com/page/page/622443.htm
   http://www.dbdebunk.com/page/page/622368.htm
   http://www.dbdebunk.com/page/page/3278346.htm

I suspect that these are to be heavily avoided in favour of properly
educating oneself about relational data models.

-austin

···

On 3/20/07, brabuhr@gmail.com <brabuhr@gmail.com> wrote:

On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
> That's usually because OO databases aren't worth the code they're
> written in for most purposes. I've written about this extensively and
> recently; I suggest you search for it.
>
> > I personally think that relational storage is evil.
>
> Then you're either ignorant or a fool. I hope it's just the former,
> because ignorance can be removed with proper education. Relational
> databases are a more natural and flexible way of storing data that has
> value beyond a single program than any hierarchical database will ever
> be (and both OO and XML databases are hierarchical databases, make no
> mistake about it!).

Anyone have any comments / experience with "associative" databases like:
    http://www.associativesolutions.com/relavance.php
    http://www.lazysoft.com/technology_sentences.htm

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

14

There's QUEL, too:

    http://www.vldb.org/conf/1987/P083.PDF

···

On Wed, Mar 21, 2007 at 04:17:55AM +0900, Gary Wright wrote:

Just some random thoughts I had while reading this thread...

I'm curious as to why query language development got hung up on SQL.
I've read a little bit about Tutorial D. Is SQL simply
another example of pre-mature standardization?

--
Jos Backus
jos at catnook.com

15

Demetrius,

Response below...

I am interested in several things.

<snip>

2) Business Analysis (OLAP and Data Mining) -- Decision support is
interested in analyzing rather than processing data. Normalized data,
to me, seems all about processing data. As the purpose of data
analysis is to examine and uncover the redundancies in data, the
uniqueness constraints placed on the relational model by the
normalization process are not desirable for decision support (Roiger
and Michael Geatz, _Data Mining: A Tutorial-Based Primer_ 2003, page
182). To me, it means that transaction databases in normalized form
aren't structured well for OLAP or Data Mining type functions.

<snip>

I have been working on the ActiveWarehouse project, which is a plugin
for Rails designed to make it easier to develop data warehouses on
Rails. As such I've spent the last 6 months research data warehouse
techniques and technologies and have become quite interested as well.
We use a denormalized dimensional model for our data warehouse, which
is one way to develop a data warehouse, and it is working out quite
well. With larger databases though, especially with both large facts
and large dimensions, query response time degrades fairly quickly. In
response to this I (and others in the AW development team) have been
playing around with implementing alternate cube storage and query
systems. One of the most promising is the Dwarf algorithm
(http://citeseer.ist.psu.edu/sismanis02dwarf.html by Sismanis et. al)
which I've been reading about for about 2 weeks now.

Anyhow, I recommend checking out the current trunk of ActiveWarehouse
( http://rubyforge.org/scm/?group_id=2435 ) to see if there is
anything that piques your interest. We have also developed an ETL tool
as well as some other Rails enhancements as well.

V/r
Anthony Eden

···

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:

--
Cell: 808 782-5046
Current Location: Melbourne, FL

16

has anybody used CACHE with ruby... it the best of both worlds and
knocks the pants in performance off most relationals and it's
reliable.... i am really curious...

Cache isn't the best both worlds; its marketing materials are completely
unintelligible and useless nonsense. There is no such thing, as Fabian
Pascal makes clear, that is "post-relational." SQL databases are a
different matter, but Cache is an object database, which means that like
*every other* object database, it has to do really nasty things to query
in ways that don't fit your object model.

Anyone who bets their company on something which locks your data into a
single query path and isn't readily adaptable deserves to lose that
company. SQL databases are much more adaptable than object databases
will ever be.

Object models are good for *single* applications. They are awful for
dealing with a business as a whole.

is it USA thing (against OO databases) because European Trade Schools
CACHE is required learning... i've bought the only English translated
text book authored by all German Professors...

Trade schools don't teach fundamentals. They teach the market line, and
a whole bunch of schools (including some universities) do exactly the
same thing in the U.S. and Canada.

SQL databases aren't perfect, but they are by and large far more
sensible than an object database will ever be if you *ever* need to
access the data in your database in a different way.

Data is king. Applications are pawns.

OO db design has to be in the database for better design thoroughness
just as it accepted elsewhere in computer science. To topdown OO unit
test the whole system and not just the ruby front end is better and
more consisent....

This is incorrect in so many ways that it's not even worth addressing
most of it. If you don't know proper data modelling, you will *never* be
a good object modeller. If you don't understand the relational data
model, you will *never* be a good object modeller.

Period.

-austin

···

On 3/20/07, Dave Rose <bitdoger2@yahoo.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

17

> Again, this is incorrect. Relational algera are about set
> operations on
> data. SQL models this badly, but it allows for better data combination
> than any single OO model will ever allow.
Just some random thoughts I had while reading this thread...

I'm curious as to why query language development got hung up on SQL.
I've read a little bit about Tutorial D. Is SQL simply
another example of pre-mature standardization?

Possibly. I haven't actually read Tutorial D.

What would a Ruby interface to the underlying database engine (indexed
tables) look like? Could it get closer to Tutorial D by bypassing the
standard technique of 'marshaling' requests into SQL statements? Is
the impedance mismatch between Ruby (or any other OO language) and
Codd's relational algebra too great to cross smoothly?

Again, possibly to either one. I don't honestly know. What I do know
is that people are looking for solutions in the wrong side. If you
have a object/relational impedance mismatch, fix your object model.

-austin

···

On 3/20/07, Gary Wright <gwtmp01@mac.com> wrote:

On Mar 20, 2007, at 1:47 PM, Austin Ziegler wrote:

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

18

IANADBA, but FWIW, here's one idea for dealing with the O-R impedance
mismatch: model the queries, not the tables.

i.e. Create an API that makes it easy to perform relational database
operations from an OO language, rather than trying to make a bunch of
square data structures look like a big triangular one. Instead of
writing a code generator that churns out custom classes to represent a
database's tables, and then trying to shoehorn useful behaviours into
that, define a set of standard classes and methods that represent the
various database elements - table, query, result set, etc. - and the
operations you'd perform on them - join, select, dump, etc. This might
give users a basic syntax like:

d = database('My DB')
t = d.table(:foo) + d.table(:bar)
q = t[field(:size) > 100]
r = q.get(:name, :color)
r.each { |name, color| puts "#{name} likes #{color}" }

which could optionally be dressed up with a bit of db-specific
syntactic sugar if desired, allowing users to write more concise
expressions such as 'd.foo + d.bar', 't[it.size > 100]', etc.

It's an approach I used a couple years back when writing an Apple
event bridge for Python. (Apple event-based IPC is an unusual mix of
RPC and simple first-class queries with hybrid relational+object
semantics.) While the resulting API may feel a little less OO-like
than other Python-AE bridges that tried to put a strictly OO face on
everything, its query-centric design made it significantly easier to
expose the full range of AE functionality and created fewer hidden
gotchas and compatibility problems. Admittedly, the full relational
database model is a bit more complicated than the Apple Event Object
Model, but given the issues with the traditional ORM approach, a query-
centric approach could be worth a look.

has

···

On 20 Mar, 19:17, Gary Wright <gwtm...@mac.com> wrote:

What would a Ruby interface to the underlying database engine (indexed
tables) look like? [...] Is
the impedance mismatch between Ruby (or any other OO language) and
Codd's relational algebra too great to cross smoothly?

--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html

19

From memory, and as far I've understood it: Sometime during the early
80s there was a rush to get relational databases out there, with
several vendors producing databases and wanting an interoperable query
language. As a result of some sort of differences, two different
groups were formed, both creating their own attempt at a standard
query language. Over time, a bunch of rivalry formed between the
groups, and each of the languages they developed had advantages in
some areas and disadvantages in others, so it wasn't possible to pick
a single "winner", and everything kept bickering back and forth.
Prestige entered, and none of the groups were politically able to give
in to the other.

Along came SQL, which was a toy language made by a single developer to
just show have SOMETHING. It was worse than either of the proposals
from the other groups, from a usability point of view (though with a
couple of extra features I don't remember what was that were useful),
and it was a possible political compromise. So, by shooting down BOTH
groups for something that was worse, a solution was possible. Thus,
we standardized on SQL.

Take with a grain of salt - this is based on renderings of history
I've read on the net, and reproduced from my spotty memory. Yet it's
a nice story that fits very well with my feeling about SQL ("Nobody
could really have meant that language SERIOUSLY, could they?")

Eivind.

···

On 3/20/07, Gary Wright <gwtmp01@mac.com> wrote:

I'm curious as to why query language development got hung up on SQL.
I've read a little bit about Tutorial D. Is SQL simply
another example of pre-mature standardization?

20

Ok, if you say so. Let's call it a describing language, but operations like AUTO INCREMENT seem an awful lot like programming. I guess we have to say Ruby is not a programming language either. It is a scripting language.
hmm...
many sources do describe (no pun intended) SQL as a declarative programming language. It isn't 'Turing complete' because it can't create an infinite loop. Big deal.
That's academic nitpicking.

···

On Mar 22, 2007, at 12:20 AM, Robert Klemme wrote:

On 20.03.2007 17:55, John Joyce wrote:

I would argue that part of the problem is SQL being very unlike any non-database programming language.

That may be because SQL is not a programming language although it is often mistaken for one. SQL, more precisely the query part of it, *describes* data sets via set operations.

Although there are declarative languages around (IIRC Prolog is one of them) most programming languages are procedural (even OO languages) and so people tend to expect SQL to be similar.

Kind regards

  robert