Object/Relational Mapping is the Vietnam of Computer Science

  • Thread starter Demetrius Gallitzin
  • Start date
D

Demetrius Gallitzin

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 Neward The Vietnam of Computer Science June 2006.PDF
(pdf from odbms.org)
Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.
 
J

John Joyce

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.
 
A

Austin Ziegler

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.

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
 
D

Demetrius Gallitzin

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. :)
 
D

Dave Rose

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....
 
B

brabuhr

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.


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
 
A

Austin Ziegler

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. :)

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

-austin
 
A

Austin Ziegler

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

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
 
G

Gary Wright

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?

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
 
M

Mark Volkmann

He knows what the hell he's talking about, but
he's an abrasive man who often hurts his own points by his
abrasiveness.

Hmm ... this reminds me of somebody else (Austin) whose views I
usually agree with. ;-)
 
T

Trans

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/...ms.org/download/031.01 Neward The Vietnam of ...
(pdf from odbms.org)
Disclaimer: I am unaffiliated with Ted Neward, db4o, odbms.org, etc. etc.

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.
 
A

Anthony Eden

Demetrius,

Response below...

I am interested in several things.
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
 
A

Austin Ziegler

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
 
A

Austin Ziegler

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
 
A

Austin Ziegler

Hmm ... this reminds me of somebody else (Austin) whose views I
usually agree with. ;-)

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."

-austin
 
G

gregarican

Possibly. I haven't actually read Tutorial D.


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

I've worked with SQL databases for at least 12 years now. As an admin,
a report writer, a data analyst, you name it. The past 5 years I've
tried to become more of a developer and have approached both OO and
non-OO languages. I can agree with your assertions. Having checked out
strict OO languages like the various Smalltalks and their accompanying
OO databases I wound up loving the languages, with their elegance and
their power. But when I started looking at testing out the OO
databases they hook into I gave up with a bad taste in my mouth. They
were such a PITA to even install and configure, let along start
implementing as the back end of an application. The logic behind them
just didn't make sense. I would spend hours trying to model something
and just scrap it and spend a few minutes cranking out some SQL
statements to post against a relational database. Sure you can use
objects to solve problems constructing a user interface application.
But the underlying data itself is a different story. Perhaps there are
other OO databases out there that might shed some light I haven't seen
yet. But after years of working with databases I haven't discovered
anything that beats SQL.
 
H

has

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?

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
 
G

gregarican

I've worked with SQL databases for at least 12 years now. As an admin,
a report writer, a data analyst, you name it. The past 5 years I've
tried to become more of a developer and have approached both OO and
non-OO languages. I can agree with your assertions. Having checked out
strict OO languages like the various Smalltalks and their accompanying
OO databases I wound up loving the languages, with their elegance and
their power. But when I started looking at testing out the OO
databases they hook into I gave up with a bad taste in my mouth. They
were such a PITA to even install and configure, let along start
implementing as the back end of an application. The logic behind them
just didn't make sense. I would spend hours trying to model something
and just scrap it and spend a few minutes cranking out some SQL
statements to post against a relational database. Sure you can use
objects to solve problems constructing a user interface application.
But the underlying data itself is a different story. Perhaps there are
other OO databases out there that might shed some light I haven't seen
yet. But after years of working with databases I haven't discovered
anything that beats SQL.- Hide quoted text -

- Show quoted text -

The other thing about this thread is the subject. Awesome title.
Perhaps Angelina Jolie and Brad Pitt might look into adopting a data
member :)
 
J

John Joyce

Well, perhaps it is object orientation for object orientation's sake?
Sometimes a program doesn't need objects either.
Functional, procedural programming is sometimes the way to go.
OOP helps organize code and reuse features, as well as protect data.
But inside, even OOP is really procedural stuff that is just highly
organized.
At some level it is still procedural, to the machine.

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?

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top