Object/Relational Mapping is the Vietnam of Computer Science

[Trans]

Like Pascal, I have little patience for people who speak out of
ignorance, especially when they say stupid things like "I think
relational databases are evil."

Oh, like you've never said anything "stupid" before. Ha!

T.

 

[Alex Young]

Like Pascal, I have little patience for people who speak out of
ignorance, especially when they say stupid things like "I think
relational databases are evil."

Having read Pascal's articles (and a few posts by some notable others on
comp.databases.theory), I'd say you're remarkably mild and restrained...

 

[Eivind Eklund]

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?

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.

 

[John Joyce]

Reality was uglier than that. More comparable to the browser wars and
implementations of html of the 90's.
But worse.
All the database makers had their own ways of doing things. SQL was a
pseudo-standard middle between systems that always offered their own
proprietary things as well. Like html and C/C++ and JavaScript and
everything else out there, vendors slowly merged toward more fully
supporting a standard by customer demand. You don't think Microsoft
was the first to think up the idea of using proprietary things to
lock in customers, do you?
Databases were the original home of neckties running IT.
Everyone was calling their SQL the real one, but none were the same.
(still aren't really) because they don't want you to jump ship so
easily! Long term licensing revenues with low support costs.

 

[Robert Klemme]

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

 

[Kyle Schmitt]

I hate to say this, but 10 seconds of fact checking says shenanigans.

http://en.wikipedia.org/wiki/Sql
Summary,
It wasn't some toy language, it was a research paper by a Dr Codd
working for IBM.
In the 70s IBM made a relational database system and based the
language off of Dr Codd's paper, the language was called "Structured
English Query Language", later shortened for copyright/trademark
reasons

Read the article for the rest.

--Kyle

 

[John Joyce]

Ok, I read it. But never call wikipedia fact-checking!

 

[Robert Klemme]

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.

That sounds interesting. Thanks!

My general assumption so far was that every DWH is different and you
need to create custom solutions for specific applications - just to cope
with the exceptional data volume. But then again, maybe most DWH's
aren't that big and can be tackled with a more standardized solution.

Kind regards

robert

 

[John Joyce]

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.

 

[Olivier Renaud]

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.

And I thought SQL could be classified as a functionnal programming language.
But yes, "describing language" seems to be an appropriate definition.

 

[David Morton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Data is king. Applications are pawns.
-austin

You know, that is a profound statement.


- --
David Morton
Maia Mailguard - http://www.maiamailguard.com
Morton Software Design and Consulting - http://www.dgrmm.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGAWr0Uy30ODPkzl0RAk6kAJ49IfzXcB2qCLRdp3gbHB87RWPECgCgpReL
LSYpqahSMJxD0rD50UJYcSo=
=/Y5y
-----END PGP SIGNATURE-----

 

[I. P.]

John Joyce DE I. P.

JJ> Ok, I read it. But never call wikipedia fact-checking!
History of System R/SQL:
http://www.mcjones.org/System_R/SQL_Reunion_95/index.html

 

[Chad Perrin]

yet. But after years of working with databases I haven't discovered
anything that beats SQL.

I tend to find that the DBI interfaces for languages like Perl and Ruby
are usually a better choice when you have the option, if only because
SQL syntax sucks -- but an SQL-based relational database does seem to be
what works in 98% of cases.

 

[Rick DeNatale]

Ok, I read it. But never call wikipedia fact-checking!

Well, for what it's worth, as someone who toiled at IBM from 1974 to
2005, that wikipedia article jibes with my memories.

But then what do I know?

 

[Chad Perrin]

Ok, I read it. But never call wikipedia fact-checking!

That's only slightly disingenuous. I'd put it this way:

"Never call a general resource 'fact-checking', regardless of the
specific example of a general resource."

If you want to check facts, you need to go after the specific,
stand-alone, specialized resources. Always check with primary sources,
or be aware you could be wrong. It doesn't matter whether it's Google,
Wikipedia, Britannica, the OED for etymology, or Ask Chad -- general
resources are not authoritative primary sources on specifics (generally
speaking, har har).

Sorry. I just tend to get my back up a little when someone singles out
a specific general resource, as though the problem isn't endemic to
general resources in general, almost tautologically.

 

[Chad Perrin]

You know, that is a profound statement.

It's not a new idea to me, but it's an excellent formulation of the
idea.

Austin -- is that original? Should we call it Ziegler's Law?

 

[Chad Perrin]

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.

That's certainly *a* reason for the difference, but not *the* reason.
There's also the simple fact that SQL is just kind of broken by design.

 

[Chad Perrin]

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.

If you want a "real programming language" version of SQL, just use
PL/SQL with Oracle. Ew.

 

[Chad Perrin]

And I thought SQL could be classified as a functionnal programming language.
But yes, "describing language" seems to be an appropriate definition.

Technically, it's a "query language". Why come up with more names for
it?

 

[Austin Ziegler]

It's not a new idea to me, but it's an excellent formulation of the
idea.

Austin -- is that original? Should we call it Ziegler's Law?

As you said, the idea isn't original, but as far as I know, the
formulation is unique to me and this particular conversation. I'm
somewhat flattered to have the suggestion, but something like "the
Rule of Data" is probably better

-austin