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.

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

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 * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

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

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 * http://www.halostatue.ca/feed/
>                * austin@zieglers.ca
>
>

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

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

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
> 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
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

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

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
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

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.

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:43 PM, Austin Ziegler wrote:

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

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.

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 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?
 
There's QUEL, too:

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

-- 
Jos Backus
jos at catnook.com

Demetrius,

Response below...

On 3/20/07, Demetrius Gallitzin <gallitzin@gmail.com> wrote:
> 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

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

On 3/20/07, Dave Rose <bitdoger2@yahoo.com> wrote:
> 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
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/20/07, Gary Wright <gwtmp01@mac.com> wrote:
>
> 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.
> 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
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/20/07, Mark Volkmann <mark@ociweb.com> wrote:
> On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote:
> > 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. ;-)

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
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On Mar 20, 8:52 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
> On 3/20/07, Gary Wright <gwtm...@mac.com> wrote:
>
>
>
> > 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.
> > 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
> --
> Austin Ziegler * halosta...@gmail.com *http://www.halostatue.ca/
>                * aus...@halostatue.ca *http://www.halostatue.ca/feed/
>                * aus...@zieglers.ca

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.

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?

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
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html

On Mar 20, 9:44 pm, "gregarican" <greg.kuj...@gmail.com> wrote:
> On Mar 20, 8:52 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
>
>
>
>
>
> > On 3/20/07, Gary Wright <gwtm...@mac.com> wrote:
>
> > > 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.
> > > 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
> > --
> > Austin Ziegler * halosta...@gmail.com *http://www.halostatue.ca/
> >                * aus...@halostatue.ca *http://www.halostatue.ca/feed/
> >                * aus...@zieglers.ca
>
> 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 :-)

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.

On Mar 21, 2007, at 10:50 AM, has wrote:

> 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?
>
> 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
> --
> http://appscript.sourceforge.net
> http://rb-appscript.rubyforge.org
> http://appscript.sourceforge.net/objc-appscript.html
>
>

On Mar 20, 8:53 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
> On 3/20/07, Mark Volkmann <m...@ociweb.com> wrote:
>
> > On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote:
> > > 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. ;-)
>
> 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.

Austin Ziegler wrote:
> On 3/20/07, Mark Volkmann <mark@ociweb.com> wrote:
>> On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote:
>> > 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. ;-)
> 
> 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...

-- 
Alex

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?

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.

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.
On Mar 21, 2007, at 11:44 PM, Eivind Eklund wrote:

> 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?
>
> 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 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

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

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

On Mar 22, 2007, at 12:37 AM, Kyle Schmitt wrote:

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

On 20.03.2007 21:35, Anthony Eden wrote:
> 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

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
>

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

-- 
Olivier Renaud

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

Austin Ziegler wrote:
> 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-----

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

-- 
I. P.     2007-03-21T21:04

On Wed, Mar 21, 2007 at 10:45:13AM +0900, gregarican wrote:
> 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.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent:  a Signify v1.14 production from http://www.debian.org/

On 3/21/07, John Joyce <dangerwillrobinsondanger@gmail.com> wrote:
> 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?

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Thu, Mar 22, 2007 at 12:47:50AM +0900, John Joyce wrote:
> 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.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham

On Thu, Mar 22, 2007 at 02:27:27AM +0900, David Morton wrote:
> Austin Ziegler wrote:
> > Data is king. Applications are pawns.
> > -austin
> 
> 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?

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell
him you disagree and he turns away. Show him facts and figures and he
questions your sources. Appeal to logic and he fails to see your point."

On Thu, Mar 22, 2007 at 12:20:05AM +0900, 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.

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.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts." - Paul Graham

On Thu, Mar 22, 2007 at 01:01:14AM +0900, John Joyce wrote:
> 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.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky

On Thu, Mar 22, 2007 at 01:29:18AM +0900, Olivier Renaud wrote:
> 
> 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?

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Brian K. Reid: "In computer science, we stand on each other's feet."

On 3/21/07, Chad Perrin <perrin@apotheon.com> wrote:
> On Thu, Mar 22, 2007 at 02:27:27AM +0900, David Morton wrote:
> > Austin Ziegler wrote:
> > > Data is king. Applications are pawns.
> > 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?

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
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/21/07, Chad Perrin <perrin@apotheon.com> wrote:
> On Thu, Mar 22, 2007 at 01:01:14AM +0900, John Joyce wrote:
> > 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.

Which is a better language than most people think. What's interesting
is that it isn't a version of SQL, but a version of Ada (or Modula 2?)
with SQL cursors as a native data type and built-in recognition of
existing database data types and SQL statements. It's closer to Pro*C
(C/C++ with embedded SQL) than a programming language version of SQL.

It's still saddled with the limitations of SQL.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On Mar 21, 1:43 pm, "Austin Ziegler" <halosta...@gmail.com> wrote:
> On 3/21/07, Chad Perrin <per...@apotheon.com> wrote:
>
> > On Thu, Mar 22, 2007 at 02:27:27AM +0900, David Morton wrote:
> > > Austin Ziegler wrote:
> > > > Data is king. Applications are pawns.
> > > 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?
>
> 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 ;)

Given that "Data is King", I particularly like the (non-sexual) double-
entendre of "Rule of Data".  :)

On Thu, Mar 22, 2007 at 04:43:23AM +0900, Austin Ziegler wrote:
> On 3/21/07, Chad Perrin <perrin@apotheon.com> wrote:
> >On Thu, Mar 22, 2007 at 02:27:27AM +0900, David Morton wrote:
> >> Austin Ziegler wrote:
> >> > Data is king. Applications are pawns.
> >> 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?
> 
> 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 ;)

I'm inclined, then, to go with Ziegler's Rule of Data, or something
along those lines.  It's a good'un.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham

On Thu, Mar 22, 2007 at 04:46:51AM +0900, Austin Ziegler wrote:
> On 3/21/07, Chad Perrin <perrin@apotheon.com> wrote:
> >On Thu, Mar 22, 2007 at 01:01:14AM +0900, John Joyce wrote:
> >> 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.
> 
> Which is a better language than most people think. What's interesting
> is that it isn't a version of SQL, but a version of Ada (or Modula 2?)
> with SQL cursors as a native data type and built-in recognition of
> existing database data types and SQL statements. It's closer to Pro*C
> (C/C++ with embedded SQL) than a programming language version of SQL.
> 
> It's still saddled with the limitations of SQL.

That's really the major problem I have with it -- the limitations of
SQL, thanks to including SQL.

Another way of looking at it is that it's just SQL with Ada-inspired
sugar.  While I haven't until now run across the description of it from
the other direction (that it's Ada with embedded SQL), I still think
that calling it SQL with Ada-inspired sugar better encompasses my
distaste for it.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The ability to quote is a serviceable
substitute for wit." - W. Somerset Maugham

On Thu, 22 Mar 2007, Phrogz wrote:

> Given that "Data is King", I particularly like the (non-sexual) double-
> entendre of "Rule of Data".  :)

one of the great things about this

-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama

On 3/21/07, James Moore <jamesthepiper@gmail.com> wrote:
> On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
>> Data is king. Applications are pawns.
> Data is a dead fish. Applications are knowing how to fish. There are
> minor edge cases where data is more important ("feed me now or I die
> of starvation"), but in the grand scheme of things data is
> insignificant compared to the applications that produce and transform
> it.

Thank ghu I don't have to do business with you, because I wouldn't trust
your programs to work with my most important assets. I assure you that
my data is far more important than the applications which do something
with the data. The applications increase value, but they NEVER provide
value. It's the data.

* What's the most valuable thing that Amazon has? It isn't the programs;
  those are constantly updated and occasionally replaced. It's the
  customer DATA that they've amassed.
* What's the biggest worry intelligent people have about Google? It
  isn't the programs, it's the amount of DATA that Google contains about
  people.
* What have a number of commercial firms found themselves in trouble for
  in the alst eighteen months? Losing personal DATA about their
  customers.
* What do hackers and phishers want from you? Your personal DATA. They
  don't really give a damn about your programs.

Scientists are worried about losing data from older sources, not the
programs. Data, once available, can be squished and manipulated and
dealt with in many dozens of different ways -- and often MUST be.

I can work with my pictures in iPhoto or LightRoom with no problems. The
pictures are more important than which program I use to edit them. I can
play my MP3s with any of a dozen different programs; the songs are more
important than which program I use.

I reiterate: Data is king. Applications are pawns. You can squawk all
kinds of ways to next Tuesday that this isn't true or that it's "minor
edge cases", but in reality it's just the opposite -- and ALWAYS WILL
BE. The application is more important than the data in the most rare of
cases. This is where a lot of OO-heads screw up. They think that the
application is far more important than the data. This is never true. The
application is, for the most part, a footnote to the data. Businesses
don't care *that* much when they lose an application. They care
*significantly* when they lose data.

> We use relational databases as object stores because they're cheap and
> easily available, not because they're good for the task.

No, that's why we use SQL databases. The reason that we don't use object
databases is that they're not cheap, they're not easily available, and
they're disastrous for your DATA because they completely lock you into a
single view of that data. Which matters a LOT more than any pissant
little program ever will.

Please. Try a little harder next time before you try analogies that
don't hold up to even the barest of comparisons.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On Thu, 22 Mar 2007, James Moore wrote:

> On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
>> 
>> Data is king. Applications are pawns.
>> 
>
> Data is a dead fish.  Applications are knowing how to fish.  There are minor
> edge cases where data is more important ("feed me now or I die of
> starvation"), but in the grand scheme of things data is insignificant
> compared to the applications that produce and transform it.
>
> We use relational databases as object stores because they're cheap and
> easily available, not because they're good for the task.

here at the national geophysical data ceter

   http://ngdc.noaa.gov/

we say that data is useless, only the combination of applications and human
reasoning can turn it into __information__.  so, with that in mind, i'd say
that data and applications are useless and that it's only by combining the two
using logic (aka business rules) that anything meaningful arises.

cast in point : we've 260tb of 'data' sitting in our mass storage device.
less than 0.01% ever comes back out.  that small percentage is massaged into
meaningful __information__ via complex application and human logic though and
it's those kernels we're interested in.

2 cts.

-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama

On 3/21/07, Michael Bevilacqua-Linn <michael.bevilacqualinn@gmail.com> wrote:
> On 3/21/07, James Moore <jamesthepiper@gmail.com> wrote:
>> We use relational databases as object stores because they're cheap
>> and easily available, not because they're good for the task.
> Really? What's better?

I've debunked Mr Moore's base premise in a separate post, but as far as
simply storing data -- not ensuring transactional integrity or any
number of other things that database management systems provide you --
absolutely nothing beats flat files on the filesystem where the
filesystem provides your indexing and can perform amazingly quickly as
long as you're working with fixed data.

The problem, of course, is that filesystems are hierarchical in nature
and if your data -- or at least your indexing scheme(s) can't be
represented hierarchically, you're toast.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/21/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Thu, 22 Mar 2007, James Moore wrote:
> > On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
> >> Data is king. Applications are pawns.
> > Data is a dead fish.  Applications are knowing how to fish.  There are minor
> > edge cases where data is more important ("feed me now or I die of
> > starvation"), but in the grand scheme of things data is insignificant
> > compared to the applications that produce and transform it.
> > We use relational databases as object stores because they're cheap and
> > easily available, not because they're good for the task.
> here at the national geophysical data ceter
>
>    http://ngdc.noaa.gov/
>
> we say that data is useless, only the combination of applications and human
> reasoning can turn it into __information__.  so, with that in mind, i'd say
> that data and applications are useless and that it's only by combining the two
> using logic (aka business rules) that anything meaningful arises.

I have to disagree with you, Ara. If you start with a set of data and
your business rules, you can reformulate the applications to derive
*value* from the set of data. On the other hand, if you have a set of
applications that implement your business rules and no data ... you
can't derive value at all.

Without data, you absolutely cannot do anything. If customers have to,
they can buy or write new programs to work with their data. They can
almost *never* recover lost data.

Case in point: Alaska Revenue just had to spend $200,000 in overtime
to rescan paper data that had been lost from their online system and
the backup was unreadable.

> cast in point : we've 260tb of 'data' sitting in our mass storage device.
> less than 0.01% ever comes back out.  that small percentage is massaged into
> meaningful __information__ via complex application and human logic though and
> it's those kernels we're interested in.

Right, but if you needed to, you could easily (fsvo easily) rewrite
the complex application; it would be far harder to try to recreate the
data -- especially the historical data you have from satellite
imagery. It's not as if you can rewind the clock seven days to get a
satellite image you lost a week ago.

You are right that programs help you derive *value* from the data, but
programs are far more easily replaced than data.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Chad Perrin wrote:
> On Thu, Mar 22, 2007 at 01:29:18AM +0900, Olivier Renaud wrote:
>> 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?

It's not a name, but a description. "describing" language is
not the standard term - Olivier means SQL is a "declarative"
language. But even that's only true of the standard, the actual
implementations have procedural features as well.

On Thu, 22 Mar 2007, Austin Ziegler wrote:

> I have to disagree with you, Ara. If you start with a set of data and your
> business rules, you can reformulate the applications to derive *value* from
> the set of data. On the other hand, if you have a set of applications that
> implement your business rules and no data ... you can't derive value at all.
>
> Without data, you absolutely cannot do anything. If customers have to, they
> can buy or write new programs to work with their data. They can almost
> *never* recover lost data.
>
> Case in point: Alaska Revenue just had to spend $200,000 in overtime to
> rescan paper data that had been lost from their online system and the backup
> was unreadable.

don't get me wrong - i understand your point.  still, it's not quite so clear
cut imho though.  for instance, we store both raw and derived satellite
products in our mass store.  people tend to consider the raw in just those
terms you are describing - the foundation of it all.  however, as the
developer that manages the system which manages that data i can say that there
are literally dozens of small but critical peices of software which touches
the data before it hits disk.  and this doesn't even take into account the
fact that the data has been stored and replayed from a crappy magnetic tape
which then relayed the stuff to a downlink and then bounces a few hops around
the world to get to us.  in reality the 'raw' data is only as good as the
weakest link in all those applications and hardware bits.

that might seem far fetched, but my experience is that this sort of thinking -
that data is something hard and real - is pervasive in science and nearly
always wrong.  not long ago i go a bunch of data dumped on my lap: hundreds of
cds of ionosounde data from stations all around the world.  in theory the data
should all carry a unique signature and all the code this group used made this
assumption.  of course they were wrong: i wrote a script to scour the data
looking for 'impossible' contradictions.  the results?  thousands of dups and
logical contradictions that they didn't even know about.

i could tell 20 more stories like this.  people think the word 'data' is holy
and that it's somehow different from the data collection sofware and hardware
which collected it.  maybe this is obvious to most people, but it's worth
stating for posterity that the 'data' is often 'crap' because not enough
attention was paid to the software and hardware which collected and verified
it and, in that sense, this whole commentary is a bit circular.

nevertheless i do agree that 'data' is more important when a person is using
the normal divisions we use when thinking about it.  it's just that those
divisions can be artificial sometimes without people being aware of it.

> Right, but if you needed to, you could easily (fsvo easily) rewrite the
> complex application; it would be far harder to try to recreate the data --
> especially the historical data you have from satellite imagery. It's not as
> if you can rewind the clock seven days to get a satellite image you lost a
> week ago.

this is true of course.

> You are right that programs help you derive *value* from the data, but
> programs are far more easily replaced than data.

it depends on the collection method - but that is nearly always true too.

cheers.

-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama

>
>
>Please. Try a little harder next time before you try analogies that
>don't hold up to even the barest of comparisons.

Yes, 100% agree with Austin..
Without DATA there is no need for Applications !.. DATA are 'fact' and its 
sensitive and mostly very hard to recreate (if at all) unlike Apps.

Let me focus back into scripting now... This is clear enough to anyone.. ;-)

Regards,
Jimmy  

Chad Perrin wrote:
> That's really the major problem I have with it -- the limitations of
> SQL, thanks to including SQL.

The "limitations" of SQL stem from it being a true child
of the 1970's, but also from the relational model it adopts,
and from the requirements of transactional processing. This
last one is the most intractable and the least-commonly
understood. It's easy to pile criticisms on SQL, but it's
funny how the people who do it almost *never* seem to have
a deep understanding of the amazingly complex field of
transactional processing.

Object databases are even more fraught with problems arising
from the model they espouse than relational ones. I could go
on for a week about this, but suffice it to say that generally,
by trying to force persistence into an object model, they've
lost the plot regarding transactional behaviour, despite some
well-meaning attempts and even partial successes.

The right answer is more subtle and simpler than either, and
it's fact-oriented databases. I'll be having more to say about
that as my ActiveFacts project progresses.

Clifford Heath.

On Mar 20, 2007, at 17:53 , Austin Ziegler wrote:

> On 3/20/07, Mark Volkmann <mark@ociweb.com> wrote:
>> On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote:
>> > 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. ;-)
>
> 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."

And what about those of use who don't speak out of ignorance and  
STILL don't like relational DBs??? Or would you just assume we're  
ignorant too???

And I thought I wouldn't touch this topic with a 10 foot pole... I  
generally won't touch a thread that is one of your hot topics because  
it just isn't worth it (see your comment about Pascal above). You  
entered this thread as abusively as you could, pretty much on par  
with all your other hot topic threads. I think you do a lot of good  
work, but this regrettably makes pretty much most of it unapproachable.

On 3/21/07, Chad Perrin <perrin@apotheon.com> wrote:
> On Thu, Mar 22, 2007 at 12:47:50AM +0900, John Joyce wrote:
> > 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.

I'm in total agreement.  But it does seem like the Wikipedia is a
favorite whipping-boy these days.

A week or so ago a columnist in the local paper*, wrote a piece about
his experience with the accuracy of wikipedia.  It seems that he
anonymously inserted** a bunch of imaginative junk in the article
about himself in wikipedia***.

He went on an on about how long such stuff can live on in WP, but the
upshot of the column was that someone discovered his fanciful 'spam'
and deleted it.

All in all the self-policing of the wikipedia seems to work a lot
better than it's press would have one believe, and there's some
evidence that the wikipedia is just as, if not more, reliable on
average than more 'respectable' and often more dated sources, like the
Britannica which has been on an intermittent vendetta against it.

Not to belittle the point that it's certainly not a primary source and
shouldn't be considered as such, any more than the other references
cited.

* I can't recall his name, and I don't know if he's syndicated or how widely.

** He wasn't clear if the article in question even existed before he got there.

** Which of course violated the wikipedia policy of not posting
directly about yourself.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Gary Wright 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?

There's a different kind of 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?

Not with a fact-based model. ConQuer, though it's not
yet been realized commercially, is the absolute bees
knees - a raw beginner can compose queries that would
make a seasoned DBA quake. See www.orm.net for more...

On Thu, 22 Mar 2007, Jimmy George wrote:

>
>> 
>> 
>> Please. Try a little harder next time before you try analogies that
>> don't hold up to even the barest of comparisons.
>
> Yes, 100% agree with Austin..  Without DATA there is no need for
> Applications !.. DATA are 'fact' and its sensitive and mostly very hard to
> recreate (if at all) unlike Apps.

can you give an example of some data which were not processed by at least one
peice of software, hardware, or meatware (people) before they were stored?

it's quite dangerous to assume those links are error free because it looses
sight of the fact that data are merely representations of facts, not facts
themselves.

-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama

On Thu, Mar 22, 2007 at 07:05:07AM +0900, Rick DeNatale wrote:
> 
> All in all the self-policing of the wikipedia seems to work a lot
> better than it's press would have one believe, and there's some
> evidence that the wikipedia is just as, if not more, reliable on
> average than more 'respectable' and often more dated sources, like the
> Britannica which has been on an intermittent vendetta against it.
> 
> Not to belittle the point that it's certainly not a primary source and
> shouldn't be considered as such, any more than the other references
> cited.

I agree with that assessment 100% -- and not just because I was the
Wikimedia Foundation's first-ever paid employee.

I guess maybe I should have mentioned that disclaimer earlier.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
This sig for rent:  a Signify v1.14 production from http://www.debian.org/

On Thu, Mar 22, 2007 at 07:10:05AM +0900, Clifford Heath wrote:
> Gary Wright 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?
> 
> There's a different kind of standardization?

There are at least four types of standardization:

  1. premature standardization
  2. post-obsolescence standardization
  3. theoretically optimal standardization, which may or may not be real
  4. Microsoft standardization, which is anti-standardization with a bow

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell
him you disagree and he turns away. Show him facts and figures and he
questions your sources. Appeal to logic and he fails to see your point."

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

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.

On Thu, Mar 22, 2007 at 05:40:05AM +0900, James Moore wrote:
> On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
> >
> >Data is king. Applications are pawns.
> >
> 
> Data is a dead fish.  Applications are knowing how to fish.  There are minor
> edge cases where data is more important ("feed me now or I die of
> starvation"), but in the grand scheme of things data is insignificant
> compared to the applications that produce and transform it.
> 
> We use relational databases as object stores because they're cheap and
> easily available, not because they're good for the task.

Except in cases of catch-and-release sport fishing, fishing is about the
fish.  If data's the fish and applications are fishing, data is *still*
king.

Now . . . having someone hand you munged data is not as valuable as
being able to do it yourself, so applications are important.
Ultimately, however, it's the data that matters, and applications should
be designed accordingly.  What good is fishing in a lake with no fish?

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);

On Thu, Mar 22, 2007 at 07:17:29AM +0900, ara.t.howard@noaa.gov wrote:
> 
> can you give an example of some data which were not processed by at least 
> one
> peice of software, hardware, or meatware (people) before they were stored?

Wait -- we're talking about human beings as "applications" now!?

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

On Thu, Mar 22, 2007 at 06:53:54AM +0900, ara.t.howard@noaa.gov wrote:
> 
> don't get me wrong - i understand your point.  still, it's not quite so 
> clear
> cut imho though.  for instance, we store both raw and derived satellite
> products in our mass store.  people tend to consider the raw in just those
> terms you are describing - the foundation of it all.  however, as the
> developer that manages the system which manages that data i can say that 
> there
> are literally dozens of small but critical peices of software which touches
> the data before it hits disk.  and this doesn't even take into account the
> fact that the data has been stored and replayed from a crappy magnetic tape
> which then relayed the stuff to a downlink and then bounces a few hops 
> around
> the world to get to us.  in reality the 'raw' data is only as good as the
> weakest link in all those applications and hardware bits.

The software that collects the data in the first place is only
collecting data.  Data exists everywhere around us, waiting to be
collected, collated, stored, and transformed into information.  We care
about the information that comes out, and that depends on the data that
goes in.  We'd rather not have to do everything between the two with
rulers, pencils, and our gray matter, so we use applications -- but it's
still about the data, ultimately.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors.  A program
is what you give the audience." - Larry Wall

On 21.03.2007 23:22, Sam Smoot wrote:
> Ok. I can stand the SQL love-in no longer. :)
> 
> 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

How does it do schema migration?  Do you have experience with that?

Kind regards

	robert

On 3/21/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
> On Mar 20, 2007, at 17:53 , Austin Ziegler wrote:
> > On 3/20/07, Mark Volkmann <mark@ociweb.com> wrote:
> >> On Mar 20, 2007, at 1:43 PM, Austin Ziegler wrote:
> >> > 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. ;-)
> > 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."
> And what about those of use who don't speak out of ignorance and
> STILL don't like relational DBs??? Or would you just assume we're
> ignorant too???

I don't particularly like SQL databases. I just won't pretend -- like
some people, which may or may not include yourself; I don't know since
you've never made a statement on it, certainly not as stupid as
"relational databases are evil" -- that object databases or xml
databases or anything else like that is a good thing.

> And I thought I wouldn't touch this topic with a 10 foot pole... I
> generally won't touch a thread that is one of your hot topics because
> it just isn't worth it (see your comment about Pascal above). You
> entered this thread as abusively as you could, pretty much on par
> with all your other hot topic threads. I think you do a lot of good
> work, but this regrettably makes pretty much most of it unapproachable.

Ryan, that's really rich. I strongly suggest you look over your own
contributions and harsh stances before you try to pull this particular
stunt. I choose my battles carefully, and I don't tend to talk about
stuff in harsh terms that I don't have extensive experience with. I
know you do the same, but you'd really best look at how you're
perceived before trying to tell me that my work is unapproachable for
doing exactly what you do.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Sam Smoot wrote:
> * Knows the *data* is safe because the database is open-source,

How does that help ensure *no* committed transaction is lost when
someone trips over the power cord?

>
>can you give an example of some data which were not processed by at least one
>peice of software, hardware, or meatware (people) before they were stored?

So now you list these broad array and include "people" in it too!!.. Now 
that's too far ..LOL!.
How can you compare data and people ?.. Its not like Data and Apps.. So yr 
arg is not valid comparison..
In System Analysis & Design you can see a lot of raw data.. You can see 
what it means if you learn SAD/SAM.


>it's quite dangerous to assume those links are error free because it looses
>sight of the fact that data are merely representations of facts, not facts
>themselves.
>
>-a
>--
>be kind whenever possible... it is always possible.
>- the dalai lama

Right on this one.. But a data in a raw form does have some kind of fact 
associated with it..
So its not all untrue data !!.. In other words a data can hold facts of un 
true attributes,which makes a "data" that can represent both fact or non 
factual info (meta data)!..




Best Regards,
Jimmy George
Email: WebMaster@CoolShack.com

Please visit my website at : http://coolshack.com

Quote :
"Great knowledge sees all in one. Small knowledge breaks down into the many"

Quote:  "Complete" :
Nature is complete because it does not serve itself.
The sage places himself after and finds himself
before, Ignores his desire and finds himself content.
He is complete because he does not serve himself."     --- From books to 
Taoism..

On Thu, 22 Mar 2007, Chad Perrin wrote:

> On Thu, Mar 22, 2007 at 07:17:29AM +0900, ara.t.howard@noaa.gov wrote:
>>
>> can you give an example of some data which were not processed by at least
>> one
>> peice of software, hardware, or meatware (people) before they were stored?
>
> Wait -- we're talking about human beings as "applications" now!?

heh.  no, not quite ;-)  i'm just pointing out the various steps which take
place before data are stored

   information -> applications -> data -> applications -> hopefully new information

but most people visulalize this like so

   data -> applications -> hopefully new information

and in reality it's something more like

   ... information -> applications -> data -> applications ->
         information -> applications -> data -> applications ->
           information -> applications -> data -> applications ->
             information -> applications -> data -> applications -> ...

it's simply a mistake to consider the data some sort of ultimate 'starting
point' imho.

-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama

On 3/21/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Thu, 22 Mar 2007, Chad Perrin wrote:
> > On Thu, Mar 22, 2007 at 07:17:29AM +0900, ara.t.howard@noaa.gov wrote:
>>> can you give an example of some data which were not processed by at
>>> least one peice of software, hardware, or meatware (people) before
>>> they were stored?
>> Wait -- we're talking about human beings as "applications" now!?
>
> heh. no, not quite ;-)  i'm just pointing out the various steps which
> take place before data are stored
>
>    information -> applications -> data -> applications -> hopefully
>    new information
>
> but most people visulalize this like so
>
>    data -> applications -> hopefully new information
>
> and in reality it's something more like
>
>    ... information -> applications -> data -> applications ->
>          information -> applications -> data -> applications ->
>            information -> applications -> data -> applications ->
>              information -> applications -> data -> applications ->
>              ...
>
> it's simply a mistake to consider the data some sort of ultimate
> 'starting point' imho.

Well, it is (the ultimately starting point), although you may need a
process to collect it in the first place. However, it is, as you said, a
cyclical loop.

To make what you're saying "accurate" is change the word from
"applications" to "processes". Software applications are simply
automating processes.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On Thu, 22 Mar 2007, Austin Ziegler wrote:

>
> Well, it is (the ultimately starting point), although you may need a
> process to collect it in the first place. However, it is, as you said, a
> cyclical loop.
>
> To make what you're saying "accurate" is change the word from
> "applications" to "processes". Software applications are simply
> automating processes.
>

yes - 'process' is a much better word.  and with that i'll bow out of the this
most decidedly OT subject!  ;-)

cheers

-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama

Cache looks to me like Pick rebirthed.
Prime had a version called 'Information'.
A clone of this was ported to Unix & called 'Universe'.
Pretty neat combination of OSystem & Data store.
Which lead to a tight coupling of the Basic used to access the data.

Data is not information until 'viewed'.
(Conversation on quantum similes omitted).

If there is a possibility of inaccuracies being introduced in the
mechanism of viewing, then you'd better have the raw data there for
another view.

Markt

On Mar 21, 2007, at 15:43 , Austin Ziegler wrote:

> I don't particularly like SQL databases. I just won't pretend -- like
> some people, which may or may not include yourself; I don't know since
> you've never made a statement on it, certainly not as stupid as
> "relational databases are evil" -- that object databases or xml
> databases or anything else like that is a good thing.

I actually love OODBs, and having worked for a major vendor in that  
space, would consider myself knowledgeable in that arena.

> Ryan, that's really rich. I strongly suggest you look over your own
> contributions and harsh stances before you try to pull this particular
> stunt. I choose my battles carefully, and I don't tend to talk about
> stuff in harsh terms that I don't have extensive experience with. I
> know you do the same, but you'd really best look at how you're
> perceived before trying to tell me that my work is unapproachable for
> doing exactly what you do.

I hear you and for the most part agree. We're polarizers.

Checking my last 200 mail going to ruby-talk (to sept 2006), I don't  
remember (I'm not about to re-read all of them) a single one of them  
having a directed personal attack. The harshest I've gotten on the  
list in the past year or two centered around one of my favorite gems  
being poisoned, and it still didn't have a personal attack in it. I  
think the second harshest I've gotten centers around writing  
image_science because rmagick/imagemagick sucks (and well, it does).  
I try keep my polarized opinions on my blog, where they belong.

I think the main difference is that I know when to stop. I doubt  
there is a single thread in the past 4 years I've participated in  
with more than say... 5 emails from me (that's a total guess). I see  
at least 10 such threads for you in your last 200 (going back to Oct  
2006--so pretty close to the same posting rate) There'd probably be  
some value in aggregating posts by author and then subject.

So this isn't entirely a pot calling a kettle black.

Ahhhh.... the combination of multi-values & Ruby..... (aroma of caramel...)=

Robert Klemme schrieb:
[...]
> How does it do schema migration?  Do you have experience with that?

look at 
http://developer.db4o.com/ProjectSpaces/view.aspx/Db4o-Out-Of-The-Box_Presentation
the part named "Refactoring and Schema Evolution"
and at http://developer.db4o.com/forums/thread/26997.aspx

I think that covers most cases. There are other ways too, like 
translators and reflectors, but I am not fit in that part.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

On Mar 21, 6:00 pm, Clifford Heath <no.s...@please.net> wrote:
> SamSmootwrote:
> > * Knows the *data* is safe because the database is open-source,
>
> How does that help ensure *no* committed transaction is lost when
> someone trips over the power cord?

Eh? I'm not talking about ACIDity. I'm talking about the horse people
love to beat about loosing your data due to vendor lock-in, completely
ignoring that there's no rational difference with your average RDBMS.

On the subject of ACIDity though, here's a developer press-release on
an older version, along with benchmarks and tests for crash
simulations: http://developer.db4o.com/blogs/product_news/archive/2006/06/02/25420.aspx

Now, could be that you just don't trust them. Ok, but since it's
unlikely you've vetted your RDBMS of choice in the same manner, is
that really fair? (Just an idea, not accusing you of anything; you
very may well have written a suite of tests to verify your RDBMS
acidity. :)

On Mar 21, 5:34 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 21.03.2007 23:22, SamSmootwrote:
>
> > Ok. I can stand the SQL love-in no longer. :)
>
> > 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
>
> How does it do schema migration?  Do you have experience with that?
>
> Kind regards
>
>         robert

My experience with it was in the 4.x line, but I managed it then much
like I do now. If I want to export some data from MySQL, I don't
typically use a sql dump. I drop into irb, and write 3 or 4 lines
using ActiveRecord and FasterCSV. :)

You can replicate with db4o, or I imagine now that they have an
administrative GUI you could probably dump the data through that.

Or do you mean class migrations? To the best of my recollection, that
was one of the advantages of db4o, automatic versioning without any of
the hoops some of the other vendors made you jump through. Don't quote
me on that, but I'm fairly certain there was no assembly/module
registration.

On Thu, Mar 22, 2007 at 09:22:17AM +0900, Daniel N wrote:
> 
> >From my perspective the 'system', or any system desing/analysis, must
> include the people who interact with it.  IMHO a system should model all
> appropriate inputs and outputs to it.  So meatware (love that bit) should
> definitley be a factor since meatware can do some pretty nasty things to
> data without all the validations attached.

I agree -- wetware (aka meatware) is part of the overall system.  That
doesn't mean it goes on the application side of a discussion of
applications vs. data, however.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."

 From my perspective the 'system', or any system desing/analysis, must
>include the people who interact with it.  IMHO a system should model all
>appropriate inputs and outputs to it.  So meatware (love that bit) should
>definitley be a factor since meatware can do some pretty nasty things to
>data without all the validations attached.

Even before meatware can handle anything there MUST exist a DATA. Without 
it there is no processing !.. Just like a raw material for a factory..
Hope this sums it up for now..
Got to get going...  Catch ya later.. ;-)

Best Regards,
Jimmy George
Email: WebMaster@CoolShack.com

Please visit my website at : http://coolshack.com

Quote :
"Great knowledge sees all in one. Small knowledge breaks down into the many"

Quote:  "Complete" :
Nature is complete because it does not serve itself.
The sage places himself after and finds himself
before, Ignores his desire and finds himself content.
He is complete because he does not serve himself."     --- From books to 
Taoism..

Ziegler's Rule of Data is just corollary to the General Law of
Zieglerity:

   I am King, you is pwn3d.

But it can't be right. It contradicts the Special Law:

   I is where IT is at!

All puns intended.

;)

T.

This is the droid your looking for:

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

T.

Austin Ziegler wrote:
...
> Thank ghu I don't have to do business with you, because I wouldn't trust
> your programs to work with my most important assets. I assure you that
> my data is far more important than the applications which do something
> with the data. The applications increase value, but they NEVER provide
> value. It's the data.
> 
> * What's the most valuable thing that Amazon has? It isn't the programs;
>  those are constantly updated and occasionally replaced. It's the
>  customer DATA that they've amassed.
> * What's the biggest worry intelligent people have about Google? It
>  isn't the programs, it's the amount of DATA that Google contains about
>  people.

What is Google's most valuable asset? Not data. They recreate their data 
constantly.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

James Moore wrote:
> On 3/20/07, Austin Ziegler <halostatue@gmail.com> wrote:
>>
>> Data is king. Applications are pawns.
>>
> 
> Data is a dead fish.  Applications are knowing how to fish.

Data is king crab! Applications are prawns! Don't you get it??? 
Crustaceans rulez!

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Sam Smoot wrote:
> On Mar 21, 6:00 pm, Clifford Heath <no.s...@please.net> wrote:
>> SamSmootwrote:
>>> * Knows the *data* is safe because the database is open-source,
>> How does that help ensure *no* committed transaction is lost when
>> someone trips over the power cord?
> Eh? I'm not talking about ACIDity.

I'm sorry, but the possibility of a power fail is an infinitely
greater risk than that I won't be able to use my existing software
and hardware to extract data from the proprietary (or not) storage
format that software might use. You're the one that said "the data
is safe". I beg to differ.

> I'm talking about the horse people
> love to beat about loosing your data due to vendor lock-in

Ok. Perhaps you can explain just how vendor lockin would cause me
to loose (sic) data? I still have the files, and the software, and
the hardware, and backups or redundancy for all. Where's the chance
of loss that's mitigated by having the source code as well?

> On the subject of ACIDity though, here's a developer press-release on
> an older version, along with benchmarks and tests for crash
> simulations: http://developer.db4o.com/blogs/product_news/archive/2006/06/02/25420.aspx
> 
> Now, could be that you just don't trust them.

No, I trust them. I don't, however, trust them as much as tests
that I know have been conducted, using thread-scheduling hooks
to explore very many of the infinite combinatoric paths of such
things, and in the process, do the same "stop the world" recovery
tests. Such exploration takes years, thousands of clients, and
trillions of transactions, before real trust is deserved.

But in any case, it's not my data that's at risk, and it's not me
who needs to be convinced. It's my dozens of customers who are
backing up tens of gigabytes of transaction log every day, from
machines costing hundred of $K, and who are using software that's
doing the same for tens of thousands of other customers for years,
without the vendor being sued our of existence - as happened to
inferior players during the 80's - who need to be convinced.

For better or for worse, and even though they now seem to have
risen above their ignorance, the authors of MySQL, who apparently
didn't know what a transaction is, have unfortunately tarred most
of the open source database world with the same brush. Unfair, but
life is.

Clifford Heath.

On 21.03.2007 17:01, John Joyce wrote:
> 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.

Actually it's not because this fact has indeed practical consequences. 
For example, try to retrieve a tree structure from a table without 
defined depth limit in standard SQL.

Regards

	robert

On 22.03.2007 02:01, Jochen Theodorou wrote:
> Robert Klemme schrieb:
> [...]
>> How does it do schema migration?  Do you have experience with that?
> 
> look at 
> http://developer.db4o.com/ProjectSpaces/view.aspx/Db4o-Out-Of-The-Box_Presentation 
> 
> the part named "Refactoring and Schema Evolution"
> and at http://developer.db4o.com/forums/thread/26997.aspx
> 
> I think that covers most cases. There are other ways too, like 
> translators and reflectors, but I am not fit in that part.

Thanks for the pointer!  It seems at least not too big a pain to do 
although the "simple use the following code to resave all objects with 
UUIDs and VersionNumbers enabled" made me a little nervous. :-)  But if 
UUIDs and VersionNumbers are switched on then that should not be a big 
issue.  Still "ALTER TABLE ADD ( foo VARCHAR2(100) DEFAULT '-' )" feels 
a bit simpler...

Kind regards

	robert

From: Austin Ziegler [mailto:halostatue@gmail.com] :
# Well, it is (the ultimately starting point), although you may need a
# process to collect it in the first place. However, it is, as=20
# you said, a  cyclical loop.

data is it.
data can be King (as you said) and can be a pauper.
data has been around even before we existed. The raw data fr stoneage is =
basically same as today

...but

the processing of data has=20

1 made civilization, consider usa, europe, china, dubai, etc
2 made industrializaton, commerce, agri, you name it
3 made leisure, sports, arts, etc
4 made each one of us unique, consider AZiegler, Ara, YMatz, DBlack, =
etc..

data is _just_ data until one makes *use of it. So until someone makes =
use of it, it is still useless..  Isn't it the reason why there are =
rubyists all around? Is the ruby language data? ;)

kind regards -botp

On 3/22/07, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
> Austin Ziegler wrote:
> > Thank ghu I don't have to do business with you, because I wouldn't trust
> > your programs to work with my most important assets. I assure you that
> > my data is far more important than the applications which do something
> > with the data. The applications increase value, but they NEVER provide
> > value. It's the data.
> >
> > * What's the most valuable thing that Amazon has? It isn't the programs;
> >  those are constantly updated and occasionally replaced. It's the
> >  customer DATA that they've amassed.
> > * What's the biggest worry intelligent people have about Google? It
> >  isn't the programs, it's the amount of DATA that Google contains about
> >  people.
> What is Google's most valuable asset? Not data. They recreate their data
> constantly.

I would (mostly) disagree. Obviously, Google provides value to its
customers/users because of the algorithms it applies to the data it
collects. However, the data Google has is of immense intrinsic value.
Part of the value that Google continually refreshes the data, but
saying that it's "recreated" constantly isn't quite true; it's
partially refreshed constantly. If they lost 20% of their data, it
would take them a *long* time to recreate that 20% because of the
sheer volume -- and some portion of that 20% would be forever lost.

Data matters immensely to Google.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Robert Klemme schrieb:
[...]
> Thanks for the pointer!  It seems at least not too big a pain to do 
> although the "simple use the following code to resave all objects with 
> UUIDs and VersionNumbers enabled" made me a little nervous. :-)  But if 
> UUIDs and VersionNumbers are switched on then that should not be a big 
> issue.  Still "ALTER TABLE ADD ( foo VARCHAR2(100) DEFAULT '-' )" feels 
> a bit simpler...

db4o allows you to add fields to object without UUIDs and 
VersionNumbers. You just change the class and it works. The only two 
things that are working better in a rdbms is updating a large amount of 
data using a single sql command and removing a large amount of rows 
using a single sql command.

That is, because db4o does not have a query mechnism that allows to 
update or to remove without creating the object first. And creating a 
huge amount of needless object means to lose processing power. But I 
also think that if enough customers say they want to have this, then it 
can be put into db4o. It is not a big problem to design it and I think 
adding it to the database is also not too much of a pain. So, I won't 
say it is a general disadvantage of oodbms, it is only one for db4o that 
could be overcome. Ah well, maybe there is already an mechnism for this 
and I just missed that.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

On Mar 21, 11:05 pm, "Trans" <transf...@gmail.com> wrote:
> Ziegler's Rule of Data is just corollary to the General Law of
> Zieglerity:
>
>    I am King, you is pwn3d.
>
> But it can't be right. It contradicts the Special Law:
>
>    I is where IT is at!


Eek! That was supposed to be My Special Law, _MY_ special law, I tell
you!

T/

On 21 Mar 2007, at 21:23, ara.t.howard@noaa.gov wrote:
> here at the national geophysical data ceter
>
>   http://ngdc.noaa.gov/
>
> we say that data is useless, only the combination of applications  
> and human
> reasoning can turn it into __information__.  so, with that in mind,  
> i'd say
> that data and applications are useless and that it's only by  
> combining the two
> using logic (aka business rules) that anything meaningful arises.
>
> cast in point : we've 260tb of 'data' sitting in our mass storage  
> device.
> less than 0.01% ever comes back out.  that small percentage is  
> massaged into
> meaningful __information__ via complex application and human logic  
> though and
> it's those kernels we're interested in.

Having trained as a physicist before entering IT I'd say that's a  
different usage of the word 'data' than in this conversation. I'd  
worry about any data entering one of my relational databases that  
didn't pass the basic criterion of being potentially useful  
information - of course it's not provably useful until someone  
performs a query to extract it, so perhaps we should class it as  
virtual information in its stored form... some kind of superposition  
waiting for human intervention ;p

Anyway, if I have the choice between saving my data and saving my  
code - data will win every time.


Ellie

Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason

On Thu, Mar 22, 2007 at 07:25:09PM +0900, Clifford Heath wrote:
> 
> Ok. Perhaps you can explain just how vendor lockin would cause me
> to loose (sic) data? I still have the files, and the software, and
> the hardware, and backups or redundancy for all. Where's the chance
> of loss that's mitigated by having the source code as well?

One doesn't lose data because of vendor lock-in.  One loses (easy)
access to data because of vendor lock-in (coupled with some form of
vendor lock-out, of course -- data locked into a given format, user
locked out of the software one uses to access it).

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

On Mar 22, 10:23 am, Chad Perrin <per...@apotheon.com> wrote:
> On Thu, Mar 22, 2007 at 07:25:09PM +0900, Clifford Heath wrote:
> One doesn't lose data because of vendor lock-in.  One loses (easy)
> access to data because of vendor lock-in (coupled with some form of
> vendor lock-out, of course -- data locked into a given format, user
> locked out of the software one uses to access it).

That raises a little bit of an existential question/argument:

If my data is changed to gibberish (random byte overwrites), it's
certainly lost. There is no way to recover it.

If my data is strongly encrypted and the original key is lost, is the
data lost? What if it could be recovered by 100 years of parallel
processing by all the computers on the planet brute forcing the key?

If my data is 'encrypted' by a vendor and I lose access to the
software needed to decrypt it, is it lost? It could be recovered if I
somehow force the vendor to give me access to the software, or I break
DMCA and reverse-engineer the format, or...


It appears that being lost is not a binary condition, but instead a
gradient whose value is inversely proportional to the ability to
recover/find the data.

Chad Perrin wrote:
> ...vendor lock-in (coupled with some form of
> vendor lock-out, of course -- data locked into a given format, user
> locked out of the software one uses to access it).

Ok, I can see why you wouldn't want to use software like that.
I certainly wouldn't, and haven't. In fact I don't know any
software like that, except what Microsoft tried with XP, but
even that failed. So it's a bit of a strawman you're knocking
down, aren't you?

On Fri, Mar 23, 2007 at 12:50:04PM +0900, Clifford Heath wrote:
> Chad Perrin wrote:
> >...vendor lock-in (coupled with some form of
> >vendor lock-out, of course -- data locked into a given format, user
> >locked out of the software one uses to access it).
> 
> Ok, I can see why you wouldn't want to use software like that.
> I certainly wouldn't, and haven't. In fact I don't know any
> software like that, except what Microsoft tried with XP, but
> even that failed. So it's a bit of a strawman you're knocking
> down, aren't you?

Only if I was using that statement as a point of argument.  I wasn't,
really -- I just defined vendor lock-in.  I suspect you're making
assumptions about my meaning and intent.

In any case, my usual approach to dealing with the specter of vendor
lock-in is to avoid the vendors' proprietary formats whenever at all
practical.  Sure, I can always use some outside tool to recover that
from which I've been locked out, but I'd rather not have to.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky

Chad Perrin wrote:
> In any case, my usual approach to dealing with the specter of vendor
> lock-in is to avoid the vendors' proprietary formats whenever at all
> practical.

In that case I think we're in violent agreement :-)

On Mar 21, 2007, at 7:29 PM, Ryan Davis wrote:

>
> On Mar 21, 2007, at 15:43 , Austin Ziegler wrote:
>
>> I don't particularly like SQL databases. I just won't pretend -- like
>> some people, which may or may not include yourself; I don't know  
>> since
>> you've never made a statement on it, certainly not as stupid as
>> "relational databases are evil" -- that object databases or xml
>> databases or anything else like that is a good thing.
>
> I actually love OODBs, and having worked for a major vendor in that  
> space, would consider myself knowledgeable in that arena.

Would you care to share any favored links for reading of why OODBs  
are a good thing, for those of us who don't know any better?

James Edward Gray II

On 20 Mar 2007, at 18:23, 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

Well, it looks interesting so far, thanks. Nice to look at something  
new! There's a free book PDF at the second link (here we go...). The  
points that the author makes seem to align with some of my own  
thoughts, so he's either a good salesman, or he's on to something, or  
I've poorly analysed the problems I see around me.

On 20 Mar 2007, at 18:43, Austin Ziegler wrote:

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

Mr. Pascal is really very abrasive!

I've read those three articles now. In general, I'd agree with his  
venting - certainly his criticism of people writing about problems in  
the relation model / confusing logical with physical, and idiot  
marketing speak.

 From the little look I've had, this associative stuff sounds  
interesting though. I suspect that associative's marketers have gone  
out and talked rubbish, and this has obscured any value that might be  
in it.

So I'll go and read more about it now.

Cheers,
	Benj

> > Anyone have any comments / experience with "associative" databases
> > like:
> >    http://www.associativesolutions.com/relavance.php
> >    http://www.lazysoft.com/technology_sentences.htm
>
> Well, it looks interesting so far, thanks. Nice to look at something
> new! There's a free book PDF at the second link (here we go...). The
> points that the author makes seem to align with some of my own
> thoughts, so he's either a good salesman, or he's on to something, or
> I've poorly analysed the problems I see around me.

    "(There aren't many of them out there, only one other 'real'
    implementation of one that I know of exists anywhere, which is
    Sentences by LazySoft. I'll bring it up again, because Relavance
    is not like Sentences for a lot of reasons and I'll get into those a bit
    later.)"

http://davedolan.com/blog/2006/06/28/just-when-things-are-starting-to-solidify-for-me/

On 22 Mar 2007, at 04:03, Joel VanderWerf wrote:

>
> What is Google's most valuable asset? Not data. They recreate their  
> data constantly.

 From what?

Benjohn Barnes wrote:
> 
> On 22 Mar 2007, at 04:03, Joel VanderWerf wrote:
> 
>>
>> What is Google's most valuable asset? Not data. They recreate their 
>> data constantly.
> 
>  From what?
> 

Data. Other people's data. Other people's assets. Good business to be in.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

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

I'm not really qualified to say for sure one way or the other, but I
do know Smalltalk guys love OO DBs, and a friend of mine told me that
some significant trading systems run on Gemstone (an OODB with a
pretty strong historical association with Smalltalk).

This was actually a major interest of mine pretty recently, but I got
wrapped up in a bunch of distractions and real-life stuff. If you
really want to explore OODBs, the thing to do is not use Ruby, as far
as I know, but instead use Squeak Smalltalk, the Seaside web
framework, and Squeak's open source OODB Magma.

-- 
Giles Bowkett
http://www.gilesgoatboy.org
http://gilesbowkett.blogspot.com
http://giles.tumblr.com/

> >> > 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. ;-)
> >
> > 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."
>
> And what about those of use who don't speak out of ignorance and
> STILL don't like relational DBs??? Or would you just assume we're
> ignorant too???
>
> And I thought I wouldn't touch this topic with a 10 foot pole... I
> generally won't touch a thread that is one of your hot topics because
> it just isn't worth it (see your comment about Pascal above). You
> entered this thread as abusively as you could, pretty much on par
> with all your other hot topic threads. I think you do a lot of good
> work, but this regrettably makes pretty much most of it unapproachable.

Unfortunately this is true. Matz is nice so we are nice. Abusiveness
and bad manners are inappropriate.

-- 
Giles Bowkett
http://www.gilesgoatboy.org
http://gilesbowkett.blogspot.com
http://giles.tumblr.com/

martinphillips@ladybridge.com of LadyBridge..... wrote back to me on
the topic of using
OpenQM with Ruby.

OpenQM is a multi-field database based on Pick/Universe/Everyone...
"OpenQM uses the post-relational model in which the First Law of
Normalisation is discarded, allowing multiple values such as a list of
products in an order to be stored together."

He said if Ruby can do cgi-bin, then it can access the OpenQM DB.
Intriguing.
On this page there is a clue to access techniques:
http://www.openqm.com/id57.htm

Q: When you put this against node-xml access, does xml imply it also
discards the First Law?
A: http://www.xml.com/pub/a/2002/11/13/normalizing.html

Markt

> Unfortunately this is true. Matz is nice so we are nice. Abusiveness
> and bad manners are inappropriate.

Maybe so, but IMHO directness is often interpreted as abusiveness or bad 
manners. I personally appreciate Austin's directness, and that of many 
others (although it would probably sting if it were me on the receiving 
end:) Then again, I usually try very hard to do my research before I 
post a (technical) opinion. Sometimes I post in haste and get slammed; I 
usually deserve it.

Some very smart or successful (or both) people were and are considered 
by many to be rude or abusive (for example, Theo de Raadt, Charles 
Babbage, Eric Raymond, Bill Gates, Steve Jobs, and Richard Stallman). 
I'm sure there are many reasons for this; still, one thought is that 
people like these get incredibly frustrated by receiving opinions that 
are not based on much (or any) due diligence, and questions that have 
been asked (and answered) a million times and are usually easy (or at 
least possible) to find using Google. One's patience would imaginably 
wear very thin when the signal to noise ratio of posts or emails is 
regularly low. Then again, sometimes people *are* just plain rude.

Bottom line is, I agree with ESR:

"Much of what looks like rudeness in hacker circles is not intended to 
give offense. Rather, it's the product of the direct, 
cut-through-the-bullshit communications style that is natural to people 
who are more concerned about solving problems than making others feel 
warm and fuzzy."

My 2c.

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

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

Ooooh, Omnicompetent programming, that must be good... Application feature
partitioning... sort of like schema access rights... What a lot of mumbo-
jumbo.

Data is as useful as it is trustworthy and unambiguous. If you build a DBMS
that allows you to stash facts without having to think about what they mean
and under what conditions they mean it, and to avoid constraining them so
only such facts can be stored, it becomes a nice way to build a personal
filofax, or any other system where a human must do all the interpretation,
but it's a completely useless way to build a software application. If a
developer likes such a system and finds it works well, it's because s/he
believes that all constraints on the data structure should be hidden inside
the application code. I think you can make up your own mind about whether
that is smart....

That said, these tools are actually seeking after a holy grail... how to
allow us to store facts in the same structure in which we think of them,
but retain the efficiency and transaction reliability of traditional tools.

A direct approach to this problem is already well-understood in the form
of fact-based modeling. Austin would like it, as it's a hyper-normalised
relational form, yet it can be invisibly mapped to an efficient relational
and transactional storage structure, leaving the queries against the user
friendly fact-based schema. It truly is time that this technology leaves
the academic domain where three decades of work have yielded nothing but a
few CASE tools, and finds its home in the heart of a dynamic development
environment like Ruby... It's because I believe this that I've left my job
of 17 years, in a company I co-founded, to build the ActiveFacts project
for Rubyists everywhere. My last day is Friday :-). Really. I almost can't
believe it myself :-). I've allocated myself 6 weeks full-time to build a
credible first release.

If anyone wants more information on fact-based modelling, take a look at
www.orm.net, http://www.casetalk.com, http://sourceforge.com/projects/orm,
www.objectrolemodeling.com, or some of the other sites they point to. Or
join the new Yahoo information_modeling mailing list. Please Austin, find
the time to look at it. Terry Halpin's book "Information Modeling and
Relational Databases" will be proved to be one of this century's most
influential works.

Clifford Heath.

On 28 Mar 2007, at 09:41, Edwin Fine wrote:
> Bottom line is, I agree with ESR:
>
> "Much of what looks like rudeness in hacker circles is not intended to
> give offense. Rather, it's the product of the direct,
> cut-through-the-bullshit communications style that is natural to  
> people
> who are more concerned about solving problems than making others feel
> warm and fuzzy."

It is possible to be both polite and terse, but the effort required  
is often much higher than that required to do some basic fact- 
checking with Google. Each time someone fires off an ill-considered  
opinion based on fashion, marketing hype or religious predilection  
they're effectively polluting our shared intellectual space, and yet  
somehow it's those who suffer this on a daily basis who're the  
offensive ones...


Ellie

Being and Doing are merely useful abstractions for the 'time'- 
dependent asymmetries of phase space.

On 3/28/07, Giles Bowkett <gilesb@gmail.com> wrote:
> > 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. :)
>
> I'm not really qualified to say for sure one way or the other, but I
> do know Smalltalk guys love OO DBs, and a friend of mine told me that
> some significant trading systems run on Gemstone (an OODB with a
> pretty strong historical association with Smalltalk).

Gemstone is/was basically a Smalltalk dialect with persistent shared objects.

It got some mindshare from Smalltalkers, but then again so did object
relational mappers like Toplink and the database stuff built into
VisualAge.

Although Toplink is known now mostly as a Java thing, it started out
in Smalltalk.  It was originally produced by The Object People, a
Smalltalk-based company in Ottawa. The Top in Toplink is an acronym
for The Object People.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On 3/28/07, Mark T <paradisaeidae@gmail.com> wrote:
> OpenQM is a multi-field database based on Pick/Universe/Everyone...
> "OpenQM uses the post-relational model in which the First Law of
> Normalisation is discarded, allowing multiple values such as a list of
> products in an order to be stored together."

This is complete and utter nonsense. "Post-relational" is a completely
nonsensical term, and the understanding of the first law of
normalisation is incorrect or incomplete or both to be able to say
that.

I wouldn't trust OpenQM for anything given this response you were
given. The list of products in an order are *related* to the order;
how you store those values *physically* is completely irrelevant to
how you model that relationship. There's no such thing as
"post-relational" with a theory of data that is even remotely
comprehensible in any way. "Post-relational" is short for "I don't get
relational theory, therefore, I'm going to try to sound like I know
better than Codd." You don't.

If I'm understanding the physical structure correctly, Oracle offers
something similar; it's called a table column such that you can define
a column in a table as an array or table to tightly tie the data
together in a relationship. Interestingly, Oracle will often store the
table column data *externally* to the container table -- that is,
Oracle will still represent it as a traditional table/related-table
model even though they're allowing the user to do stupid things with
normalisation.

> Q: When you put this against node-xml access, does xml imply it also
> discards the First Law?
> A: http://www.xml.com/pub/a/2002/11/13/normalizing.html

XML as a data storage technique is no more than old-style hierarchical
datastores returned to haunt us. (It does have a couple of techniques
that IMO are mildly interesting, in that you can use XLink and
references to get proper normalization, but vanilla XML is purely
hierarchical.)

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/28/07, Eleanor McHugh <eleanor@games-with-brains.com> wrote:
> On 28 Mar 2007, at 09:41, Edwin Fine wrote:
> > Bottom line is, I agree with ESR:
> > "Much of what looks like rudeness in hacker circles is not intended to
> > give offense. Rather, it's the product of the direct,
> > cut-through-the-bullshit communications style that is natural to
> > people
> > who are more concerned about solving problems than making others feel
> > warm and fuzzy."
> It is possible to be both polite and terse, but the effort required
> is often much higher than that required to do some basic fact-
> checking with Google. Each time someone fires off an ill-considered
> opinion based on fashion, marketing hype or religious predilection
> they're effectively polluting our shared intellectual space, and yet
> somehow it's those who suffer this on a daily basis who're the
> offensive ones...

As the one who has been accused of being excessively abusive in this
thread, I need to point out that I didn't call the author of the
original post an idiot; I said that they were *either* ignorant or an
idiot. One *cannot* rationally say that "I think relational databases
are evil" if you know anything about the theory *unless* you're being
willfully ignorant and/or stupid. As is said above, you're choosing
fashion, hype, or religion over science and knowledge.

There are a lot of things that one can say about SQL databases that
are minimally based on relational theory, most of them pretty darned
awful, but the merest bit of knowledge about data theory precludes you
from suggesting that any of a number of other "database" types are
even viable from that standpoint.

They may *work*, but they don't do so through any rigorous theory or
application of computer science; there's a lot of code out there that
does exactly that, and I've written some of it. (Not for these types
of systems, obviously.) But ultimately, one hits a point where the
lack of theory involved in your data store *will* come to bite you. A
lot of people start looking at other options than SQL databases
precisely because the reality of SQL doesn't match relational algebra
and the relational model. They assume that because database management
system vendors, who are part of the hype machine and are just as
vulnerable to the hype, didn't implement things properly, that the
whole theory is bunk.

Well, it isn't. And most SQL databases are still better structured
than object databases will ever be.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Hi Austin:

I don't know how I happened to recieve this email. But, if I understand the
content properly, I agree. I am an older programmer.

My main occupation is writing a book, "WHAT-AM-I?". I am taking some
of the ideas
developed in the above book to programs that demonstrate the concepts
in software simulations and active displays.

I think that I have a solution to the carrying out of these programs
in Java Applets
plus some old programs in object format from Eric Isaacson's A86 Macro
Assembler.

However, I just learned that I have both Ruby and Python on my new computer (in
addition to Perl and Java). Of these, Perl is the only one that I have
used before. But, I do want the easiest language to work into the HTML
content of the book.

The book is written in HTML and I need to add some action displays
that describe
how my senses (eye, ear, etc) seem to be mechanized.

Could you spare just a moment to give me your opinion on which way to go? I
would really appreciate your opinion.

My previous experience has been in FORTRAN, C, asm, and FORTH.

The book is not finished, but it is out on the web at:

    http://homepage.mac.com/jhmurray/a_html/toc.html

Have a great day!

Joe Murray

On 3/28/07, Austin Ziegler <halostatue@gmail.com> wrote:
> On 3/28/07, Eleanor McHugh <eleanor@games-with-brains.com> wrote:
> > On 28 Mar 2007, at 09:41, Edwin Fine wrote:
> > > Bottom line is, I agree with ESR:
> > > "Much of what looks like rudeness in hacker circles is not intended to
> > > give offense. Rather, it's the product of the direct,
> > > cut-through-the-bullshit communications style that is natural to
> > > people
> > > who are more concerned about solving problems than making others feel
> > > warm and fuzzy."
> > It is possible to be both polite and terse, but the effort required
> > is often much higher than that required to do some basic fact-
> > checking with Google. Each time someone fires off an ill-considered
> > opinion based on fashion, marketing hype or religious predilection
> > they're effectively polluting our shared intellectual space, and yet
> > somehow it's those who suffer this on a daily basis who're the
> > offensive ones...
>
> As the one who has been accused of being excessively abusive in this
> thread, I need to point out that I didn't call the author of the
> original post an idiot; I said that they were *either* ignorant or an
> idiot. One *cannot* rationally say that "I think relational databases
> are evil" if you know anything about the theory *unless* you're being
> willfully ignorant and/or stupid. As is said above, you're choosing
> fashion, hype, or religion over science and knowledge.
>
> There are a lot of things that one can say about SQL databases that
> are minimally based on relational theory, most of them pretty darned
> awful, but the merest bit of knowledge about data theory precludes you
> from suggesting that any of a number of other "database" types are
> even viable from that standpoint.
>
> They may *work*, but they don't do so through any rigorous theory or
> application of computer science; there's a lot of code out there that
> does exactly that, and I've written some of it. (Not for these types
> of systems, obviously.) But ultimately, one hits a point where the
> lack of theory involved in your data store *will* come to bite you. A
> lot of people start looking at other options than SQL databases
> precisely because the reality of SQL doesn't match relational algebra
> and the relational model. They assume that because database management
> system vendors, who are part of the hype machine and are just as
> vulnerable to the hype, didn't implement things properly, that the
> whole theory is bunk.
>
> Well, it isn't. And most SQL databases are still better structured
> than object databases will ever be.
>
> -austin
> --
> Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
>                * austin@halostatue.ca * http://www.halostatue.ca/feed/
>                * austin@zieglers.ca
>
>

Austin Ziegler wrote:
> Well, it isn't. And most SQL databases are still better structured
> than object databases will ever be.

disclaimer: I have plenty of experience with SQL but none at all with 
object databases.

That being said, it seems to me that OODBs are simply an object-based 
implementation of a relational database, as opposed to the current crop 
of SQL databases which are record-based. Otherwise the concepts between 
OODB and SQLDB seem to map 1-to-1. Instead of rows in tables you have 
objects in a graph. Instead of a foreign key you have a direct pointer 
to an object. Instead of an index on a foreign key (Foo#bar) you keep a 
list of references (Bar#foo[]) in the foreign object.

These are physical implementation details, not major conceptual 
differences. And I fail to see how that makes an OODB inherently 
hierarchical. Of course it's possible to make a hierarchical object 
model but that only reveals the incompetence of the designer, not of 
OODBs as a whole.

Please enlighten me. Thank you.

Daniel DeLorme

On 3/28/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
> Austin Ziegler wrote:
> > Well, it isn't. And most SQL databases are still better structured
> > than object databases will ever be.
> disclaimer: I have plenty of experience with SQL but none at all with
> object databases.
>
> That being said, it seems to me that OODBs are simply an object-based
> implementation of a relational database, as opposed to the current crop
> of SQL databases which are record-based. Otherwise the concepts between
> OODB and SQLDB seem to map 1-to-1. Instead of rows in tables you have
> objects in a graph. Instead of a foreign key you have a direct pointer
> to an object. Instead of an index on a foreign key (Foo#bar) you keep a
> list of references (Bar#foo[]) in the foreign object.

There's no theory behind OODBs, much less relational theory. OODBs are
ways to serialize your object graph. The concepts between OODB and
SQLDB barely map at all, except that they both store data; the
concepts between OODB and relational theory are so far apart as to not
even be on the same planet.

You don't normalize data in object databases; there's no reason to do
so. You structure things according to your application's object model
-- and pray to Codd that you never need to access the data in a
different way than your object model.

> These are physical implementation details, not major conceptual
> differences. And I fail to see how that makes an OODB inherently
> hierarchical. Of course it's possible to make a hierarchical object
> model but that only reveals the incompetence of the designer, not of
> OODBs as a whole.

Object graphs are inherently hierarchical, not relational. I suspect
you'll be enlightened even by what's on Wikipedia, flawed as it is. I
strongly recommend you read that and what's on Ward Cunningham's c2
wiki; you'll learn a lot more than I have patience to explain right
now, because OODBs are conceptually no different than hierarchical
databases from the 1970s married to conceptually "hot" object
orientation. Same thing with XML databases.

Hierarchical databases can have value, but rarely as much as their
proponents suppose, and never as much as relational databases.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On Mar 28, 2007, at 7:54 PM, Austin Ziegler wrote:

> There's no theory behind OODBs, much less relational theory. OODBs are
> ways to serialize your object graph.

OK Austin, I'll give you 100% of that statement.  Let's say you are  
completely right.

Who says *that* isn't useful?

Ruby includes Marshal, YAML, and PStore for these uses, right?   
Arguably one of their biggest weaknesses is that they have to restore  
the entire graph before they can do anything with it right?  If an  
OODB can eliminate that one restriction, wouldn't that put it leaps  
and bound ahead of all three of these libraries?

I don't know about you, but I use all three of those a lot.  So it  
seems a simple OODB has some value for me.

James Edward Gray II 
                                   

I don't use: .NET, Major relational products (often).... many other 'things'.

http://www.matisse.com/pdf/product_information/Whitepapers/DotNETarticle.pdf

The idea that 'post-relational' implies a product which is a
'later/better' than relational products is at the least, humorous.
Dick Pick is chuckling.
Some are taking it seriously though: http://www.fit.vutbr.cz/study/courses/PRD/

There are some interesting experience summaries here:
http://www.theserverside.com/news/thread.tss?thread_id=42902

Being lost is beautiful.
As then you can find your way.

Markt

Austin Ziegler wrote:
>> OODB and SQLDB seem to map 1-to-1. Instead of rows in tables you have
>> objects in a graph. Instead of a foreign key you have a direct pointer
>> to an object. Instead of an index on a foreign key (Foo#bar) you keep a
>> list of references (Bar#foo[]) in the foreign object.
> 
> There's no theory behind OODBs, much less relational theory. OODBs are
> ways to serialize your object graph. The concepts between OODB and
> SQLDB barely map at all, except that they both store data; the
> concepts between OODB and relational theory are so far apart as to not
> even be on the same planet.

I see that you barely skimmed over my post and failed to answer any of 
the 3 ways in which I showed how OODBs and SQLDBs are similar. Instead 
you answered with something that boils down to your usual "OODBs are 
evil" mantra. Proof by repeated assertion works in politics, not 
science. (although I'm just a humble engineer; what do I know about 
lofty "science", heh?)

> You don't normalize data in object databases; there's no reason to do
> so. You structure things according to your application's object model
> -- and pray to Codd that you never need to access the data in a
> different way than your object model.

How is a class not normalized? How are instances of a class different 
than rows of a table?

> Object graphs are inherently hierarchical, not relational.

Er... maybe there's a definition of "hierarchical" that I haven't heard 
about. I mean, hierarchical trees are a form of graph but the opposite 
is just not true. I suspect you'll be enlightened even by what's on 
Wikipedia, flawed as it is. :-P
http://en.wikipedia.org/wiki/Graph_%28data_structure%29

Daniel DeLorme

On 3/28/07, James Edward Gray II <james@grayproductions.net> wrote:
> On Mar 28, 2007, at 7:54 PM, Austin Ziegler wrote:
> > There's no theory behind OODBs, much less relational theory. OODBs are
> > ways to serialize your object graph.
> OK Austin, I'll give you 100% of that statement.  Let's say you are
> completely right.
>
> Who says *that* isn't useful?

James, if you look over what I've said in this thread, you'll note
that I have explicitly said that you *can* successfully store your
data. The moment you need to access the data in a different direction,
you're completely screwed.

Heck, I *use* Marshal in PDF::Writer because I *need* to store a
specific object graph and never query the data structures in a
different way.

Persistent data -- especially that which belongs to businesses -- is
often very different, though. Remember the maxim I postulated early in
the thread: data is king. The data you have is far more important than
your program, and OODBs fall down because they typically tie you to a
single object model.

As I was discussing with someone off-list, the data that I need for a
customer report is very different than the data that I need for a
summary of how many customers bought a particular widget and how often
in which locale. Object databases force you to query for a full object
even if you need a tiny portion of that object. In the putative
example I describe above, I only need to know a customer's locale
(state or province, if you prefer) -- but with an object database I
have to restore the entire customer object before I can then whittle
down the data to exactly what I need. Worse, because most people don't
know anything about data modelling (and thus make pretty bad object
modellers, too), there's a good chance that all of my orders are
reachable *through* my customers, meaning that to get to the orders, I
have to query through the customer object in the first place!

Pascal (or Date) had a good definition of the relational data model.
The relational model is tuples and attributes with associations
(relations); yes, I'm paraphrasing here.

> Ruby includes Marshal, YAML, and PStore for these uses, right?
> Arguably one of their biggest weaknesses is that they have to restore
> the entire graph before they can do anything with it right?  If an
> OODB can eliminate that one restriction, wouldn't that put it leaps
> and bound ahead of all three of these libraries?

It'd put it a couple of steps ahead, not leaps and bounds, because
you're still stuck with your single query path. If that's all your
data needs, fine. But *most* data needs much more than that, and it
must be dealt with by more than one application ultimately.

I have said a lot of things about this and how one would work with
both application and integration databases as Martin Fowler has talked
about them (and wrapping the databases in services) -- and that's
often a good thing to deal with, too, but it's sometimes not
applicable.

> I don't know about you, but I use all three of those a lot.  So it
> seems a simple OODB has some value for me.

I rarely use those in real applications. They're good for
checkpointing, as far as I'm concerned, and that's about it. I
certainly wouldn't store a customer's persistent data in them, or in
an OODB. Period.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/28/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
> Austin Ziegler wrote:
> >> OODB and SQLDB seem to map 1-to-1. Instead of rows in tables you have
> >> objects in a graph. Instead of a foreign key you have a direct pointer
> >> to an object. Instead of an index on a foreign key (Foo#bar) you keep a
> >> list of references (Bar#foo[]) in the foreign object.
> >
> > There's no theory behind OODBs, much less relational theory. OODBs are
> > ways to serialize your object graph. The concepts between OODB and
> > SQLDB barely map at all, except that they both store data; the
> > concepts between OODB and relational theory are so far apart as to not
> > even be on the same planet.
> I see that you barely skimmed over my post and failed to answer any of
> the 3 ways in which I showed how OODBs and SQLDBs are similar. Instead
> you answered with something that boils down to your usual "OODBs are
> evil" mantra. Proof by repeated assertion works in politics, not
> science. (although I'm just a humble engineer; what do I know about
> lofty "science", heh?)

Sorry, Daniel, but you didn't show anything. You *claimed* that
they're similar; you conflated things that have no relationship
whatsoever. Foreign keys and object pointers aren't even remotely
related. If modern object databases are beginning to look like
relational databases (which they're not, really) it's because the
practitioners have realised that what they're doing is technical bunk.
You've confused physical implementation similarities (because SQL
database providers are hitting the ODB bong, too) with logical models.

Seriously: read about the relational data model. You won't confuse
object databases and relational databases (even SQL databases!) ever
again.

You're right that object graphs don't *have* to be hierarchical;
object databases are uniformly so, though. I highly recommend you take
the time it requires to study relational theory. I'm not a heavy
practitioner myself, anymore -- I don't do stuff that needs databases
right now.

By the by, I've never said the ODBs are evil. Just stupid and not
based on any viable theory of data modelling, and of limited utility
because of that stupidity. Relational theory, however, provides for
the ability to model anything in data storage *efficiently* (and not
related to the physical models).

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Austin Ziegler wrote:
> Sorry, Daniel, but you didn't show anything. You *claimed* that
> they're similar; you conflated things that have no relationship
> whatsoever.

It might be impudent of me but have you considered that just maybe *you* 
are the one who can't *see* the relationship? But you are right I didn't 
show anything. Just take any ORM layer and the fact that you can 
directly and easily map a SQLDB to an object model is all the proof I 
need that a RDBMS *can* indeed be expressed as an object graph and that 
an OODB can therefore be relational.

> You're right that object graphs don't *have* to be hierarchical;
> object databases are uniformly so, though.

I have trouble believing that *all* of OODB implementers would be so 
stupid as to implement a hierarchical-only structure. If that is indeed 
the case then I can see that a being a complete waste of time.

It's now clear to me that we are arguing about different things; you 
about the (hierarchical) OODBs that you know and I about the 
(relational) OODBs that I can imagine. In the end, I believe OO is more 
about the physical model than the logical model of data.

Darn semantics strike again!

> I highly recommend you take
> the time it requires to study relational theory. I'm not a heavy
> practitioner myself, anymore -- I don't do stuff that needs databases
> right now.

Unfortunately my brain has a strong resistance to jargon-rich 
litterature such as academic papers or legalese. :-(

Daniel

On Thu, 29 Mar 2007, Daniel DeLorme wrote:

> Unfortunately my brain has a strong resistance to jargon-rich litterature 
> such as academic papers or legalese. :-(

http://erlang.org/download/armstrong_thesis_2003.pdf

-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama

On 3/28/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
> Austin Ziegler wrote:
> > Sorry, Daniel, but you didn't show anything. You *claimed* that
> > they're similar; you conflated things that have no relationship
> > whatsoever.
> It might be impudent of me but have you considered that just maybe *you*
> are the one who can't *see* the relationship? But you are right I didn't
> show anything. Just take any ORM layer and the fact that you can
> directly and easily map a SQLDB to an object model is all the proof I
> need that a RDBMS *can* indeed be expressed as an object graph and that
> an OODB can therefore be relational.

Wrong. This is completely backwards. The relational model can
*certainly* model an object graph; an object graph is not thereby
automatically relational. You're assuming that "a therefore b" also
means "b therefore a" and that just ain't the case at all.

Object databases aren't based on relational theory. They *pride*
themselves on being so-called "post-relational"; in reality, they're
not based on any viable theory. They're brute force applications of
fads and prejudices.

> > You're right that object graphs don't *have* to be hierarchical;
> > object databases are uniformly so, though.
> I have trouble believing that *all* of OODB implementers would be so
> stupid as to implement a hierarchical-only structure. If that is indeed
> the case then I can see that a being a complete waste of time.
>
> It's now clear to me that we are arguing about different things; you
> about the (hierarchical) OODBs that you know and I about the
> (relational) OODBs that I can imagine. In the end, I believe OO is more
> about the physical model than the logical model of data.
>
> Darn semantics strike again!

Object database proponents tend to believe that the relational theory
is ... bunk. In return, they offer nothing that hasn't been tried
before and shown wanting.

> > I highly recommend you take
> > the time it requires to study relational theory. I'm not a heavy
> > practitioner myself, anymore -- I don't do stuff that needs databases
> > right now.
> Unfortunately my brain has a strong resistance to jargon-rich
> litterature such as academic papers or legalese. :-(

The basics of it aren't hard; it's set theory with relational algebra.
I'm just not good enough at it to explain it nearly as well as some of
the papers that are out there. If you'd really like, I'll look at
posting some pointers to good explanations of the relational theory of
data on my blog when I have time (I'm in the middle of a QA handoff
right now, so I have little time for serious research). The starting
points I mentioned earlier, though (Wikipedia and the c2 wiki) are
really good and get you ready for understanding much of what Fabian
Pascal and Chris Date say. One of these days I will buy the Third
Manifesto, but right now, I have far too much to do otherwise.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Austin Ziegler wrote:
>> > I highly recommend you take
>> > the time it requires to study relational theory
>> Unfortunately my brain has a strong resistance to jargon-rich
>> litterature such as academic papers or legalese. :-(
> The basics of it aren't hard; it's set theory with relational algebra.
> I'm just not good enough at it to explain it nearly as well as some of
> the papers that are out there.

I'm presenting on this subject this very evening to the Melbourne
Ruby group this very evening. It's a compressed version of a seminar
series I've produced to introduce the basics of information modeling
for relational databases, with tie-ins to object modeling and object
role modeling (which is unrelated to the former, BTW).

I demystify the meaning and key functions of normalization, show the
weaknesses inherent in both the relational and the object oriented
approaches (some of which are common to both), and show how object
role modeling avoids the major weaknesses of both sides, by combining
strong normalisation and constraint capability with efficient and
convenient database access.

I'll be posting my slides and a video of my presentation somewhere
hopefully shortly afterwards, and code will be forthcoming in the
following months.

Clifford Heath.

Austin Ziegler wrote:
>> an OODB can therefore be relational.
> 
> Wrong. This is completely backwards. The relational model can
> *certainly* model an object graph; an object graph is not thereby
> automatically relational. You're assuming that "a therefore b" also
> means "b therefore a" and that just ain't the case at all.

I think *you* have it backwards. All relational models can be expressed 
with an object graph but not all objects graphs can be expressed with a 
relational model. Which is why I said than an OODB *can* be relational, 
not that all OODBs are inherently relational.

> Object database proponents tend to believe that the relational theory
> is ... bunk.

It's not because some OODB proponents are ignorant that it makes OODBs 
an inherently worthless concept. I'd rather base my opinion on my own 
analysis of the potential rather than the claims of the 
proponents/marketers.

> points I mentioned earlier, though (Wikipedia and the c2 wiki) are
> really good and get you ready for understanding much of what Fabian
> Pascal and Chris Date say.

After reading the "Interpretation" part of the wikipedia article I think 
I'm starting to understand your position. You like the elegance of set 
operations, the higher-level abstraction of manipulating relations 
rather than individual rows. Am I right? Well anyway it didn't change my 
opinion. I still believe that:

      tuples of relation == rows of table == instances of class

Daniel

On 29-Mar-2007, at 07:20, Austin Ziegler wrote:

> As I was discussing with someone off-list, the data that I need for a
> customer report is very different than the data that I need for a
> summary of how many customers bought a particular widget and how often
> in which locale.

We do such analyses (a good variety of them) in stock portfolio  
management, several hundred times a day.  The 'anchors' of such  
search are very ad-hoc in practice.

Fund managers, who typically do not have programming skills, sit with  
programmers to interactively build hyper-cubes with arbitrary classes  
-- and their attributes -- as dimensions.  We have several such 'cube  
terminals' open in front of us.  Minute-by-minute decisions are made  
based on analyses of such cubes.  Typical number of individual  
objects read during an analysis ranges between 1.5 and 20 million.   
On our 833 MHz UltraSparc server, most of them take under 10 seconds!

> Object databases force you to query for a full object
> even if you need a tiny portion of that object. In the putative
> example I describe above, I only need to know a customer's locale
> (state or province, if you prefer) -- but with an object database I
> have to restore the entire customer object before I can then whittle
> down the data to exactly what I need.

Not necessary -- partitioning techniques, vertical partitioning in  
particular, have long been (as in, for over twenty years) used in  
some object databases.  In Vision, for instance, an opaque object  
stub is what is returned upon object retrieval.  Which parts of the  
object 'actually' get loaded is dependent upon access; however, the  
developer is unaware of this (the 'opaque' part).

A variety of collection classes (examples include lists, indexed  
lists and time-series collections) are used to model relationships  
between different classes.  Navigation uses the keys of such  
collections.  Back references are established, where needed,  
similarly to foreign keys in RDBMSs.

Over the years of such every-day-hundreds-of-ad-hoc analyses, I have  
not felt constrained to hierarchically navigate anything at all!

One point where I agree with you is that most such systems are vendor- 
specific.  Vision, for instance, provides only one way of accessing  
information -- through a dialect of Smalltalk.

Greetings,
JS

Austin:
> The basics of it aren't hard; it's set theory with relational algebra.
> I'm just not good enough at it to explain it nearly as well as some of
> the papers that are out there. If you'd really like, I'll look at
> posting some pointers to good explanations of the relational theory of
> data on my blog when I have time (I'm in the middle of a QA handoff
> right now, so I have little time for serious research). The starting
> points I mentioned earlier, though (Wikipedia and the c2 wiki) are
> really good and get you ready for understanding much of what Fabian
> Pascal and Chris Date say. One of these days I will buy the Third
> Manifesto, but right now, I have far too much to do otherwise.

I for one would very much appreciate that [1].

I had a dig in Wikipedia, and there are good articles there; they're
about at my level. There are good explainations of the underlying model,
and how you'd use that in simple ways.

Here: http://en.wikipedia.org/wiki/Relational_algebra
also: http://en.wikipedia.org/wiki/Relational_model

I couldn't find anything about databases at http://c2.com; I imagine I'm
looking in the wrong place.

I didn't find anything that made me think: "But of course! I see why
this is the correct way now! Data stored like this has features A, B and
C, and clearly, those provide essential benefits X, Y and Z"

X could be "being able to see my data in any new way that I want in a
new application" and Y might be "being able to guarantee that at a
future time I can respond to new requirements on my model and add new
kinds of information, or merge it with other models". Z might be "being
able to provide queries to others that transparently expand the view of
the world they have", etc. All of these are just example ideas I like at
the moment, but I'd embrace other benefits if I could see they were
obviously much more important.

Cheers, and good luck with the hand off,
  Benjohn

[1] I'd love it if there were knowledge consultants in the world. Just
like I can go to a shop and have someone assist me in buying clothes,
I'd like to be able to go to someone and say "I'd like to know about x",
and they would say "ah perhaps you'd like this, this and this, then",
and I'd say "yes, those sound good, but this isn't quite right", etc. x
could be music, or part of biology, or international relations. And then
I could just drink things up and appreciate everything out there that
interests me.

Daniel DeLorme wrote:
> Austin Ziegler wrote:
>>> an OODB can therefore be relational.
>>
>> Wrong. This is completely backwards. The relational model can
>> *certainly* model an object graph; an object graph is not thereby
>> automatically relational. You're assuming that "a therefore b" also
>> means "b therefore a" and that just ain't the case at all.
> 
> I think *you* have it backwards. All relational models can be expressed 
> with an object graph but not all objects graphs can be expressed with a 
> relational model. 
Have you got an example?

-- 
Alex

On 29 Mar 2007, at 03:56, Daniel DeLorme wrote:
> Austin Ziegler wrote:
>> Sorry, Daniel, but you didn't show anything. You *claimed* that
>> they're similar; you conflated things that have no relationship
>> whatsoever.
>
> It might be impudent of me but have you considered that just maybe  
> *you* are the one who can't *see* the relationship? But you are  
> right I didn't show anything. Just take any ORM layer and the fact  
> that you can directly and easily map a SQLDB to an object model is  
> all the proof I need that a RDBMS *can* indeed be expressed as an  
> object graph and that an OODB can therefore be relational.

No, this demonstrates that an OODB can be implemented in terms of an  
SQLDB. This in no way demonstrates that the converse is true. Much of  
the point of an OODB is to capture a given object hierarchy, which is  
essentially a constrained Entity-Relationship model - the most  
obvious constraint being the relaxation of normalisation conditions.

Personally I want each item of data to occur once - and only once -  
in my database, as that way I can ensure that a single change is  
reflected universally and performed efficiently. I also want the  
flexibility of joins to composite new views of my database based upon  
whatever arbitrary query conditions I need fulfilling, and yet again  
I want that process to be efficient and to guarantee that all data  
returned is universally accurate and consistent at the instant that  
the query is performed. Everything else I can do in software.

My measure of efficiency in this case would be based upon individual  
data store reads, as for any significant data-set that will be the  
primary constraint on my application's performance. Compositing  
objects at run-time will be many orders of magnitude faster than  
loading the data from persistent storage.

> It's now clear to me that we are arguing about different things;  
> you about the (hierarchical) OODBs that you know and I about the  
> (relational) OODBs that I can imagine. In the end, I believe OO is  
> more about the physical model than the logical model of data.

Which is its shortcoming. If you model data based upon a physical  
structure, you then need to optimise your database engine to suit  
that structure. Taking the relational path and putting logical  
structure first leads to an implementation that is optimised for  
general queries, not just the specific queries embodied in a given  
object model.

Think of the relational model as a scientist's take on data, where an  
OODB would be an engineer's.

The scientist is interested in the general properties of data itself,  
with the nature of individual data items being an implementation  
detail - sure they add character to the problem space, but they don't  
really further one's understanding of it's geometric principles. The  
fact that the relational model is a process-oriented implementation  
of Occam's Razor sits well with this view.

The engineer of course is more concerned about getting "this damn  
thing I'm building now" to work and often cuts a few corners where  
theory is concerned. Fine, do that in your software if it makes  
sense, but don't do it with your data model: it's the underpinning of  
not only your application, but of every other application that needs  
access to the same data-space, so generalising the model at a later  
date will be the most expensive change you can make.


Ellie

Being and Doing are merely useful abstractions for the 'time'- 
dependent asymmetries of phase space.

Daniel DeLorme schrieb:
> Austin Ziegler wrote:
>>> an OODB can therefore be relational.
>>
>> Wrong. This is completely backwards. The relational model can
>> *certainly* model an object graph; an object graph is not thereby
>> automatically relational. You're assuming that "a therefore b" also
>> means "b therefore a" and that just ain't the case at all.
> 
> I think *you* have it backwards. All relational models can be expressed 
> with an object graph but not all objects graphs can be expressed with a 
> relational model. Which is why I said than an OODB *can* be relational, 
> not that all OODBs are inherently relational.

I am really for OODBs, but I can't agree with you here. A simple class 
can be seen as a data container. In that regard it is really not more 
than a table with the attributes being the columns and each instance is 
a row. But that is not really an object. That is a data based view on an 
object that every union based type fulfills. It gets really object 
oriented when you add inheritance here. And then the mapping is not so 
direct anymore. (Note: you don't really need classes for this, but I 
will use them for better understanding)

So for example I have class A with an attribute id and a class B with an 
attribute email and a class C that has the parents A and B and has an 
attribute name. Now what do we do? Make a table for A, one for B and one 
for C, or one table for all of them? Even if you simplify this to single 
inheritance, you still have that problem.

When I for example use one table per class and link these tables 
together to represent the inheritance, then I get a massive problem in 
my queries. Because If I query on C I might have to query on A and B as 
well.

When each subclass table contains all data of that class and the super 
classes, then a query on C is done on only one table. But the relation C 
"is a" A is not represented in this. C could be a class completely 
unrelated to A, which means we reduced it to the data holder type again.

It is the same when you store A,B and C in the same table. Only that you 
then need additional logic based on the class for the empty entries.

So I think there is a part of the object system that is equal (bijective 
projection) to a part of the relational system, but in both cases not 
the whole model is covered.

So if your objects can be mapped nicely to an relational database, then 
most possibly you are using a not so object oriented part of your object 
system.

Then two more things...

* OODBs are restricted to one language only:
db4o is an example against it. Not only covers it the Java Platform, it 
covers also the .Net languages. And of course an object stored from .Net 
can be used in the Java Platform as normal object then. You could say 
that .Net and the Java Platform are using more or less the same kind of 
class structure (single inheritance for example), but then it is all a 
question of doing the mapping, or not?

* OODBs don't allow me to access the data in a different way than my 
original object modell:
Well, is there really a limitation that prevents a OODB from saying that 
certain attributes of an class are really the properties of another 
class? This way I don't need to always create a full object.

* OODBs have roots and I have to use these roots to navigate to my real 
object:
db4o for example allows you to query on a per class base, so each 
instance can be root. You need other objects only for joins. see S.O.D.A.

* OODBs are hierarchic:
I think they can be, but they don't have to. There is also for example 
the network model. In fact it might also use parts of the relational 
model. I think the queries used for the OODB are giving a hint how it is 
represented inside, but in general it is an implementation detail. So an 
object graph can be understood as directed graph, and of course I can 
define a a minimal spanning tree on the subgraph that is transitive 
reachable from my selected root. But the root is more or less arbitrary, 
and the graph might not be connected enough for just one tree.

* object-relational databases are OODBs:
As I tried to show with the subclass example there are parts of the 
object model that don't fit so well in the relational model and there 
are parts of the relational model that don't fit so well in the object 
model. So in the end you get only a part of both worlds. Up to you to 
decide if that is good enough

* there are much less tools for OODBs:
that's right, no use to say more.

I also think that the relational algebra is more advanced than 
everything an OODB could provide. I think most OODB queries will for 
example have a problem with operations like getting the maximum/minimum 
of something, or subtracting one attribute from the other and such 
things. So especially in cases of reporting OODBs are not that good, not 
unless you do many of the operations outside the database system.

  bye blackdrag

On 3/29/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
> Austin Ziegler wrote:
> >> an OODB can therefore be relational.
> > Wrong. This is completely backwards. The relational model can
> > *certainly* model an object graph; an object graph is not thereby
> > automatically relational. You're assuming that "a therefore b" also
> > means "b therefore a" and that just ain't the case at all.
> I think *you* have it backwards. All relational models can be expressed
> with an object graph but not all objects graphs can be expressed with a
> relational model. Which is why I said than an OODB *can* be relational,
> not that all OODBs are inherently relational.

Um, no. All object graphs can be modelled in a relational schema (that
is, an instance of the relational model). Some of them aren't
convenient to do, but they can be modelled. Object databases, on the
other hand, reject that theory.

There's nothing that says that an object database couldn't be based on
the relational model. Sadly, object database vendors *pride*
themselves on their relational model ignorance. It's that simple.

> > Object database proponents tend to believe that the relational theory
> > is ... bunk.
> It's not because some OODB proponents are ignorant that it makes OODBs
> an inherently worthless concept. I'd rather base my opinion on my own
> analysis of the potential rather than the claims of the
> proponents/marketers.

The potential of an object layer on top of the relational model is
definitely possible and would be very useful, although you *really*
want to use the proper relational model (e.g., not even what SQL
database vendors are selling these days -- since we're talking
*potential* here). The reason I mentioned "The Third Manifesto" is
that it's an attempt by colleagues of Fabian Pascal (Chris Date and
Hugh Darwen) to deal with this:
http://en.wikipedia.org/wiki/The_Third_Manifesto

Really worthwhile, from everything I hear. I just have too many things
to do to risk being inspired by this thing right now ;)

> > points I mentioned earlier, though (Wikipedia and the c2 wiki) are
> > really good and get you ready for understanding much of what Fabian
> > Pascal and Chris Date say.
> After reading the "Interpretation" part of the wikipedia article I think
> I'm starting to understand your position. You like the elegance of set
> operations, the higher-level abstraction of manipulating relations
> rather than individual rows. Am I right? Well anyway it didn't change my
> opinion. I still believe that:
>
>       tuples of relation == rows of table == instances of class

Sadly, that's not how current object databases work. Additionally, you
generally won't model your classes exactly the same as your relations
as I was mentioning to my off-list correspondent. You should model
your objects on your queries more often than not.

If what you're saying is that there isn't a meaningful
object-relational impedance, I'd agree with you completely. However,
the perception of an object-relational impedance has caused a lot of
people to hare off in directions that don't make any sense whatsoever.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Jochen Theodorou <blackdrag@uni.de> writes:

> So for example I have class A with an attribute id and a class B with
> an attribute email and a class C that has the parents A and B and has
> an attribute name. Now what do we do? Make a table for A, one for B
> and one for C, or one table for all of them? Even if you simplify this
> to single inheritance, you still have that problem.
>
> When I for example use one table per class and link these tables
> together to represent the inheritance, then I get a massive problem in
> my queries. Because If I query on C I might have to query on A and B
> as well.

The inheritance relation of an ER model can be represented in the
table model as views. Depending on the circumstances, it might be
favourable to model the subclasses as distinct tables and the
respective superclasses as views or the other way around.

Either way, queries over the subclasses will query the superclasses, but
that's not different from the OO point of view.

> So if your objects can be mapped nicely to an relational database,
> then most possibly you are using a not so object oriented part of your
> object system.

As Austin already has mentioned, object modeling can be seen as a
special form of ER modeling - which explains the plethora of
dysfunctional and outright ugly object hierarchies one encounters in
software engineering because those people do not understand the
fundamental mathematics.

> * OODBs don't allow me to access the data in a different way than my
> original object modell:
> Well, is there really a limitation that prevents a OODB from saying
> that certain attributes of an class are really the properties of
> another class? This way I don't need to always create a full object.
>
> * OODBs have roots and I have to use these roots to navigate to my
> real object:
> db4o for example allows you to query on a per class base, so each
> instance can be root. You need other objects only for joins. see
> S.O.D.A.

The point is still valid: OODBs are not suited to represent arbitrary
views to the data as long as there isn't a possibility of creating new
object classes based on the query.

> I also think that the relational algebra is more advanced than
> everything an OODB could provide. I think most OODB queries will for
> example have a problem with operations like getting the
> maximum/minimum of something, or subtracting one attribute from the
> other and such things. So especially in cases of reporting OODBs are
> not that good, not unless you do many of the operations outside the
> database system.

While relational databases do have a sound mathematical foundation
in relational algebra and set theory (which faciliates optimising
queries in an efficient way), I haven't seen anything like that for
OODBs.


Sebastian

Sebastian Hanigk schrieb:
> Jochen Theodorou <blackdrag@uni.de> writes:
> 
>> So for example I have class A with an attribute id and a class B with
>> an attribute email and a class C that has the parents A and B and has
>> an attribute name. Now what do we do? Make a table for A, one for B
>> and one for C, or one table for all of them? Even if you simplify this
>> to single inheritance, you still have that problem.
>>
>> When I for example use one table per class and link these tables
>> together to represent the inheritance, then I get a massive problem in
>> my queries. Because If I query on C I might have to query on A and B
>> as well.
> 
> The inheritance relation of an ER model can be represented in the
> table model as views. Depending on the circumstances, it might be
> favourable to model the subclasses as distinct tables and the
> respective superclasses as views or the other way around.
 >
> Either way, queries over the subclasses will query the superclasses, but
> that's not different from the OO point of view.

combining it with a view is surely a good idea. It makes the queries 
more easy. I don't want to say it is different, it is just not as nice 
as with normal tables.

>> So if your objects can be mapped nicely to an relational database,
>> then most possibly you are using a not so object oriented part of your
>> object system.
> 
> As Austin already has mentioned, object modeling can be seen as a
> special form of ER modeling - which explains the plethora of
> dysfunctional and outright ugly object hierarchies one encounters in
> software engineering because those people do not understand the
> fundamental mathematics.

I don't agree with austin and the resulting ugly class hierarchy is 
prove enough for me. Not in all cases of course ;)

>> * OODBs don't allow me to access the data in a different way than my
>> original object modell:
>> Well, is there really a limitation that prevents a OODB from saying
>> that certain attributes of an class are really the properties of
>> another class? This way I don't need to always create a full object.
>>
>> * OODBs have roots and I have to use these roots to navigate to my
>> real object:
>> db4o for example allows you to query on a per class base, so each
>> instance can be root. You need other objects only for joins. see
>> S.O.D.A.
> 
> The point is still valid: OODBs are not suited to represent arbitrary
> views to the data as long as there isn't a possibility of creating new
> object classes based on the query.

ok, let me quote Carl here:
Indeed db4o was intended for one-app-one-schema but there is no reason 
to stop thinking and designing here. Why should it not be possible to 
have "object views" or "class-to-class" mappings if people need that? I 
am sure that we will get to a stage where we will think about ways to 
supply such functionality.

So I am not saying I know a database that can do arbitrary views, but on 
the other hand I don't think OODBs will never be able to do that. Your 
last resort is always a object describing the class and the values to 
form an instance. db4o does already have this. So I think the step to an 
arbitrary view is not out of reach.

>> I also think that the relational algebra is more advanced than
>> everything an OODB could provide. I think most OODB queries will for
>> example have a problem with operations like getting the
>> maximum/minimum of something, or subtracting one attribute from the
>> other and such things. So especially in cases of reporting OODBs are
>> not that good, not unless you do many of the operations outside the
>> database system.
> 
> While relational databases do have a sound mathematical foundation
> in relational algebra and set theory (which faciliates optimising
> queries in an efficient way), I haven't seen anything like that for
> OODBs.

and why is it needed? you can describe objects as sets too, they are 
just more complex. But I am no scientist in that area. In fact I think 
the object model is a higher level of abstraction that allows you to use 
different underlaying techniques, for example a partial relational 
model. And of course you can apply the theories of that area for that 
part of the implementation.

Why not consider OODB mathematics as part of graph theory and others?

bye blackdrag

On 3/29/07, Jochen Theodorou <blackdrag@uni.de> wrote:
> Sebastian Hanigk schrieb:
>> Jochen Theodorou <blackdrag@uni.de> writes:
>>> I also think that the relational algebra is more advanced than
>>> everything an OODB could provide. I think most OODB queries will for
>>> example have a problem with operations like getting the
>>> maximum/minimum of something, or subtracting one attribute from the
>>> other and such things. So especially in cases of reporting OODBs are
>>> not that good, not unless you do many of the operations outside the
>>> database system.
>> While relational databases do have a sound mathematical foundation in
>> relational algebra and set theory (which faciliates optimising
>> queries in an efficient way), I haven't seen anything like that for
>> OODBs.
> and why is it needed? you can describe objects as sets too, they are
> just more complex.

No, they're not (more complex). The *only* thing about objects that
relational theory can't model is operations (e.g., encapsulation). So,
no, objects aren't just "more complex sets."

> But I am no scientist in that area. In fact I think the object model
> is a higher level of abstraction that allows you to use different
> underlaying techniques, for example a partial relational model.

Please, please, *please* read more about relational theory before you
make statements like this, because it's technical nonsense. There *is*
no "object model."

Part of the problem, of course, is that a lot of terms are used and
reused imprecisely.

1. The Relational Model of Data is the combination of set theory and
   relational algebra. There is no corresponding theory or mathematical
   basis for object orientation. That is, there's no "Object Orientation
   Model of Data".

   Object orientation is, in fact, an implementation technique -- a
   refinement of procedural programming that more tightly ties data with
   operations related to that data. That's an important point, too:
   object orientation is about *programming*. It is not about data and
   the storage of data.

2. When *implementing* something, you will model the data. This can be
   your data model that can be extended into an object model for
   programming purposes. These "models" are better considered "schema";
   they describe the layout of the data.

Just because one *can* create something that works without a
mathematical theory behind it does not mean that one *should* do so. One
certainly shouldn't claim that the thing without a mathematical theory
behind it is superior to the thing with -- because that's something you
should be able to demonstrate with, well, another theory. Performance
metrics are not evidence of superiority of concept; just of
implementation.

> And of course you can apply the theories of that area for that part of
> the implementation.
>
> Why not consider OODB mathematics as part of graph theory and others?

There are no OODB mathematics, and that's part of the point that I've
been trying to make. If you can point to OODB mathematics papers and
theories, I'll retract or clarify that statement, but I have a
reasonably high level of confidence that object orientation isn't
expressed in terms of mathematics or theory the way that the relational
model is.

Sure, an object store can be set up to allow for smart loading and such,
but that *doesn't* mean that it's a good idea. It might be the "right
now" idea, but it is something you'll have to pay the piper for using at
some point in the future.

Like it or not.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Austin Ziegler wrote:
> Please, please, *please* read more about relational theory before you
> make statements like this, because it's technical nonsense. There *is*
> no "object model."
Yet. That you know of. Yet. :)

Seriously, the folks in the UK that developed the PI-Calculus have done 
some work in computer-science models of objects, but I don't know enough 
about them to know if they're relevant to this discussion. The one 
reference I have is on the edge of my readability scale -- if I sat down 
with the book and the right programming language, I might be able to 
learn it, but there are other things I'm more interested in doing.

-- 
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

Austin Ziegler schrieb:
[...]
> Please, please, *please* read more about relational theory before you
> make statements like this, because it's technical nonsense. There *is*
> no "object model."

of course there is none as you define it. Who said I am using the same 
definition? Is your definition a common definition for "model" in 
general? If so please point me to a reference. I don't know all the 
correct UK/US terms used for this.

> Part of the problem, of course, is that a lot of terms are used and
> reused imprecisely.
 >
> 1. The Relational Model of Data is the combination of set theory and
>   relational algebra. There is no corresponding theory or mathematical
>   basis for object orientation. That is, there's no "Object Orientation
>   Model of Data".

never said something different, or?

>   Object orientation is, in fact, an implementation technique -- a
>   refinement of procedural programming that more tightly ties data with
>   operations related to that data.

I usually define what should be done and how to change the state, yes. 
How is that related to the problem?

>   That's an important point, too:
>   object orientation is about *programming*. It is not about data and
>   the storage of data.

I agree partially. It is a data structure, it is not more about 
programming as a binary tree is. So it is about structuring your data to 
fit your needs of computation... but that fits so much that is a useless 
statement

> 2. When *implementing* something, you will model the data. This can be
>   your data model that can be extended into an object model for
>   programming purposes. These "models" are better considered "schema";
>   they describe the layout of the data.

What you want to say is, that a schema is no model? Or at last not all 
schemata are models. I think.. I am not sure yet ;)

> Just because one *can* create something that works without a
> mathematical theory behind it does not mean that one *should* do so.

or should not do so.

> One
> certainly shouldn't claim that the thing without a mathematical theory
> behind it is superior to the thing with -- because that's something you
> should be able to demonstrate with, well, another theory. Performance
> metrics are not evidence of superiority of concept; just of
> implementation.

I have never done that. So I guess you don't mean me, because I am well 
aware of the problems of OODBs

>> And of course you can apply the theories of that area for that part of
>> the implementation.
>>
>> Why not consider OODB mathematics as part of graph theory and others?
> 
> There are no OODB mathematics, and that's part of the point that I've
> been trying to make.

ah, yes, ok.

> If you can point to OODB mathematics papers and
> theories, I'll retract or clarify that statement, but I have a
> reasonably high level of confidence that object orientation isn't
> expressed in terms of mathematics or theory the way that the relational
> model is.

ok, see "A Query Algebra for Object-Oriented Databases (1989)" on 
citeseer http://citeseer.ist.psu.edu/shaw89query.html

Found after searching 2 minutes in google. And 1989 isn't very new. The 
papers citing that paper are also quite interesting.

The nice thing in mathematics is, that I can use it to define very much 
things... even if they are useless in the end. I guess you should give 
more constraints.

> Sure, an object store can be set up to allow for smart loading and such,
> but that *doesn't* mean that it's a good idea. It might be the "right
> now" idea, but it is something you'll have to pay the piper for using at
> some point in the future.

depends on my goals, or not?

bye blackdrag

On 3/29/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> Austin Ziegler wrote:
> > Please, please, *please* read more about relational theory before you
> > make statements like this, because it's technical nonsense. There *is*
> > no "object model."
> Yet. That you know of. Yet. :)

Fair enough.

> Seriously, the folks in the UK that developed the PI-Calculus have done
> some work in computer-science models of objects, but I don't know enough
> about them to know if they're relevant to this discussion. The one
> reference I have is on the edge of my readability scale -- if I sat down
> with the book and the right programming language, I might be able to
> learn it, but there are other things I'm more interested in doing.

Do you have a pointer to an abstract?

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/29/07, Jochen Theodorou <blackdrag@uni.de> wrote:
> Austin Ziegler schrieb:
> [...]
> > Please, please, *please* read more about relational theory before you
> > make statements like this, because it's technical nonsense. There *is*
> > no "object model."
> of course there is none as you define it. Who said I am using the same
> definition? Is your definition a common definition for "model" in
> general? If so please point me to a reference. I don't know all the
> correct UK/US terms used for this.

Like I said, "model" is a vague word. When you say "relational model",
the *meaning* is the "Relational Model of Data" (e.g., the theory). At
this point, there's nothing related for an "Object Model of Data".

When one says "object model", one usually means "the hierarchy or
graph of objects that I am using to represent the data and operations
in my implementation." In relational terms, that is a schema.

So, "relational model" and "object model" are two *totally* different
things as they are typically understood as one deals with a concept
and the other deals with a single implementation.

> >   That's an important point, too:
> >   object orientation is about *programming*. It is not about data and
> >   the storage of data.
> I agree partially. It is a data structure, it is not more about
> programming as a binary tree is. So it is about structuring your data to
> fit your needs of computation... but that fits so much that is a useless
> statement

The classic definition of an object is data and the operations that
apply to that data encapsulated in one. I am sure that there are
definitions of OO out there where encapsulation isn't part of it, but
I consider encapsulation probably the defining feature of OO (even
more than inheritance, because there are strong arguments for
composition instead). That's a whole different argument, though, and
most OO systems these days accept encapsulation, inheritance,
polymorphism, and (often) access control (information hiding).

> > 2. When *implementing* something, you will model the data. This can be
> >   your data model that can be extended into an object model for
> >   programming purposes. These "models" are better considered "schema";
> >   they describe the layout of the data.
> What you want to say is, that a schema is no model? Or at last not all
> schemata are models. I think.. I am not sure yet ;)

Just the opposite. An object model is closely related to a data model
(or a database schema, if you prefer). There's no overarching theory
of object modelling (at least not yet, as Ed pointed out), whereas
there *is* an overarching theory of data and relations.

> > Just because one *can* create something that works without a
> > mathematical theory behind it does not mean that one *should* do so.
> or should not do so.

Fair enough, but if one chooses to step away from something that has
theoretical underpinnings, one should at least be prepared to make a
coherent explanation as to why it's better. Otherwise, you're not
doing much better than selling snake oil. I'm sure you've seen
programs by vendors that claim to have better-than-AES encryption
available that absolutely no one in the security industry has
reviewed. Why do we as technical people scoff at them yet swallow the
claims of other vendors (like the OODB or "Post-Relational" folks)
without even thinking?

> > One
> > certainly shouldn't claim that the thing without a mathematical theory
> > behind it is superior to the thing with -- because that's something you
> > should be able to demonstrate with, well, another theory. Performance
> > metrics are not evidence of superiority of concept; just of
> > implementation.
> I have never done that. So I guess you don't mean me, because I am well
> aware of the problems of OODBs

I wasn't referring to you specifically; I was more referring to the
OODB vendors, who have no excuse for their specious claims.

> >> And of course you can apply the theories of that area for that part of
> >> the implementation.
> >> Why not consider OODB mathematics as part of graph theory and others?
> > There are no OODB mathematics, and that's part of the point that I've
> > been trying to make.
> ah, yes, ok.

> > If you can point to OODB mathematics papers and
> > theories, I'll retract or clarify that statement, but I have a
> > reasonably high level of confidence that object orientation isn't
> > expressed in terms of mathematics or theory the way that the relational
> > model is.
> ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
> citeseer http://citeseer.ist.psu.edu/shaw89query.html

I skimmed through this; reading it, it's an attempt to *return* some
level of relational algebra to object databases ... all the way back
in 1989. Sadly, the authors still think that first normal form is an
unnecessary restriction on the logical formation of the data -- and
they have to synthesize first normal form tuples to obtain relational
algebra capabilities in object databases.

I haven't looked further, but it's not quite a positive refutation of
my statement.

> > Sure, an object store can be set up to allow for smart loading and such,
> > but that *doesn't* mean that it's a good idea. It might be the "right
> > now" idea, but it is something you'll have to pay the piper for using at
> > some point in the future.
> depends on my goals, or not?

I've said as much. Right now solutions usually meet one's immediate
goals, but rarely meet long-term goals and often result in increased
costs in the long-term.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Austin Ziegler schrieb:
> On 3/29/07, Jochen Theodorou <blackdrag@uni.de> wrote:
>> Austin Ziegler schrieb:
>> [...]
>> > Please, please, *please* read more about relational theory before you
>> > make statements like this, because it's technical nonsense. There *is*
>> > no "object model."
>> of course there is none as you define it. Who said I am using the same
>> definition? Is your definition a common definition for "model" in
>> general? If so please point me to a reference. I don't know all the
>> correct UK/US terms used for this.
> 
> Like I said, "model" is a vague word. When you say "relational model",
> the *meaning* is the "Relational Model of Data" (e.g., the theory). At
> this point, there's nothing related for an "Object Model of Data".

but the relational algebra is about queries not data in the first place.

> When one says "object model", one usually means "the hierarchy or
> graph of objects that I am using to represent the data and operations
> in my implementation." In relational terms, that is a schema.

the operations are part of the schema?

> So, "relational model" and "object model" are two *totally* different
> things as they are typically understood as one deals with a concept
> and the other deals with a single implementation.

sorry I don't agree with you here. not with the word implementation. I 
see them as orthogonal.

>> >   That's an important point, too:
>> >   object orientation is about *programming*. It is not about data and
>> >   the storage of data.
>> I agree partially. It is a data structure, it is not more about
>> programming as a binary tree is. So it is about structuring your data to
>> fit your needs of computation... but that fits so much that is a useless
>> statement
> 
> The classic definition of an object is data and the operations that
> apply to that data encapsulated in one. I am sure that there are
> definitions of OO out there where encapsulation isn't part of it,

from the view of data the operations are not relevant, or not? I mean 
unless you make them part of the algebra... I think I have seen that 
somewhere.. ah, not sure where, sorry

> but
> I consider encapsulation probably the defining feature of OO (even
> more than inheritance, because there are strong arguments for
> composition instead).

encapsulation in terms of grouping data together? hat is not more a 
definition as a table is.

> That's a whole different argument, though, and
> most OO systems these days accept encapsulation, inheritance,
> polymorphism, and (often) access control (information hiding).

right.

>> > 2. When *implementing* something, you will model the data. This can be
>> >   your data model that can be extended into an object model for
>> >   programming purposes. These "models" are better considered "schema";
>> >   they describe the layout of the data.
>> What you want to say is, that a schema is no model? Or at last not all
>> schemata are models. I think.. I am not sure yet ;)
> 
> Just the opposite. An object model is closely related to a data model
> (or a database schema, if you prefer).  There's no overarching theory
> of object modelling (at least not yet, as Ed pointed out), whereas
> there *is* an overarching theory of data and relations.

data *and* relations, yes. A theory about data only would be useless, or 
not?

>> > Just because one *can* create something that works without a
>> > mathematical theory behind it does not mean that one *should* do so.
>> or should not do so.
> 
> Fair enough, but if one chooses to step away from something that has
> theoretical underpinnings, one should at least be prepared to make a
> coherent explanation as to why it's better.

coherent? "My tests are showing my application is faster with it" or "I 
am faster in prototyping" is for some cases coherent enough.

[...]
>> > One
>> > certainly shouldn't claim that the thing without a mathematical theory
>> > behind it is superior to the thing with -- because that's something you
>> > should be able to demonstrate with, well, another theory. Performance
>> > metrics are not evidence of superiority of concept; just of
>> > implementation.
>> I have never done that. So I guess you don't mean me, because I am well
>> aware of the problems of OODBs
> 
> I wasn't referring to you specifically; I was more referring to the
> OODB vendors, who have no excuse for their specious claims.

and you are not referring to a specific OODB vendor either... just to a 
blurred mass of unknown people. Don't mix the vendor with salesman. Some 
are, but not all.

[...]
>> ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
>> citeseer http://citeseer.ist.psu.edu/shaw89query.html
> 
> I skimmed through this; reading it, it's an attempt to *return* some
> level of relational algebra to object databases ... all the way back
> in 1989.

please read it again. there is no such thing as "returning" there is 
only a thing of mapping one concept to another. Something like a morphism.

> Sadly, the authors still think that first normal form is an
> unnecessary restriction on the logical formation of the data -- and
> they have to synthesize first normal form tuples to obtain relational
> algebra capabilities in object databases.

where?

I have read: "One research direction in the modeling of object-oriented 
is the extension of the relational model to build complex types. Early 
extensions relaxed the first normal form requirement of the relational 
model to allow set valued attributes.

> 
> I haven't looked further, but it's not quite a positive refutation of
> my statement.

you claimed there is no algebra, I proved you wrong. I myself said there 
is much space for nonsense and that without constraints there will never 
be a "solution". So either we talk about such constraints or we end the 
topic. It makes no use to give more and more new papers just that you 
can say that you don't like the opinion of the author."

I guess you mean a different part?

>> > Sure, an object store can be set up to allow for smart loading and 
>> such,
>> > but that *doesn't* mean that it's a good idea. It might be the "right
>> > now" idea, but it is something you'll have to pay the piper for 
>> using at
>> > some point in the future.
>> depends on my goals, or not?
> 
> I've said as much. Right now solutions usually meet one's immediate
> goals, but rarely meet long-term goals and often result in increased
> costs in the long-term.

might be true, but if your boss says that he needs to save money in the 
short term it is a different thing. For example for prototypes, for 
example for small applications, for example for applications that don't 
share data, for example for applications without the need to do reporting.

bye blackdrag

On 3/29/07, Jochen Theodorou <blackdrag@uni.de> wrote:
>> Like I said, "model" is a vague word. When you say "relational
>> model", the *meaning* is the "Relational Model of Data" (e.g., the
>> theory). At this point, there's nothing related for an "Object Model
>> of Data".
> but the relational algebra is about queries not data in the first
> place.

The Relational Model of Data is about how to organise the data in such a
way that relational algebra is able to work. So your statement isn't
really correct. Relational algebra doesn't work without the organisation
of the data into sets of tuples and attributes.

>> When one says "object model", one usually means "the hierarchy or
>> graph of objects that I am using to represent the data and operations
>> in my implementation." In relational terms, that is a schema.
> the operations are part of the schema?

Are you not understanding what I'm saying? I'm making an analogy here,
not a direct correspondence. What people call an "object model" is
similar to a relational schema. When I do my object models, I *start*
with how I need to model my data; then and only then do I start
considering my operations. (I will, of course, have considered the
"pipeline" for processing the data related to the purpose of the program
I'm working on.)

>> So, "relational model" and "object model" are two *totally* different
>> things as they are typically understood as one deals with a concept
>> and the other deals with a single implementation.
> sorry I don't agree with you here. not with the word implementation. I
> see them as orthogonal.

They're not orthogonal, really. A database schema and an object model
are orthogonal, but one deals with a higher level concept than the
other.

>>>> That's an important point, too: object orientation is about
>>>> *programming*. It is not about data and the storage of data.
>>> I agree partially. It is a data structure, it is not more about
>>> programming as a binary tree is. So it is about structuring your
>>> data to fit your needs of computation... but that fits so much that
>>> is a useless statement
>> The classic definition of an object is data and the operations that
>> apply to that data encapsulated in one. I am sure that there are
>> definitions of OO out there where encapsulation isn't part of it,
> from the view of data the operations are not relevant, or not? I mean
> unless you make them part of the algebra... I think I have seen that
> somewhere.. ah, not sure where, sorry

I'd be considered an object apostate by some of the more vehement OOists
out there, mostly because I think that data is far more important than
operations involved and that I consider it a refinement of procedural
programming. Encapsulation is the only thing that seems to be *common*
among the various OO systems I've seen, but I've seen C code that I
would consider programmed in an OO-style even though there's no
encapsulation (as such) in C.

>> but I consider encapsulation probably the defining feature of OO
>> (even more than inheritance, because there are strong arguments for
>> composition instead).
> encapsulation in terms of grouping data together? hat is not more a
> definition as a table is.

I can't parse this; encapsulation is, as I understand it, combining data
and operations.

>>>> 2. When *implementing* something, you will model the data. This can
>>>>    be your data model that can be extended into an object model for
>>>>    programming purposes. These "models" are better considered
>>>>    "schema"; they describe the layout of the data.
>>> What you want to say is, that a schema is no model? Or at last not
>>> all schemata are models. I think.. I am not sure yet ;)

Not at all. I think I've explained it above, but if you still don't
understand, please ask.

>> Just the opposite. An object model is closely related to a data model
>> (or a database schema, if you prefer).  There's no overarching theory
>> of object modelling (at least not yet, as Ed pointed out), whereas
>> there *is* an overarching theory of data and relations.
> data *and* relations, yes. A theory about data only would be useless,
> or not?

This is basic relational theory; please read more on it.

>>>> Just because one *can* create something that works without a
>>>> mathematical theory behind it does not mean that one *should* do so.
>>> or should not do so.
>> Fair enough, but if one chooses to step away from something that has
>> theoretical underpinnings, one should at least be prepared to make a
>> coherent explanation as to why it's better.
> coherent? "My tests are showing my application is faster with it" or "I
> am faster in prototyping" is for some cases coherent enough.

Not at all. Performance is about implementations, not about concepts.

> [...]
>>>> One certainly shouldn't claim that the thing without a mathematical
>>>> theory behind it is superior to the thing with -- because that's
>>>> something you should be able to demonstrate with, well, another
>>>> theory. Performance metrics are not evidence of superiority of
>>>> concept; just of implementation.
>>> I have never done that. So I guess you don't mean me, because I am
>>> well aware of the problems of OODBs
>> I wasn't referring to you specifically; I was more referring to the
>> OODB vendors, who have no excuse for their specious claims.
> and you are not referring to a specific OODB vendor either... just to a
> blurred mass of unknown people. Don't mix the vendor with salesman. Some
> are, but not all.

OO database vendors *as a class* make specious claims, usually about
being "post-relational" and not having coherent explanations for why
abandoning first normal form is a good idea. They can't explain it, so
they have to hype up things to distract others.

> [...]
>>> ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
>>> citeseer http://citeseer.ist.psu.edu/shaw89query.html
>> I skimmed through this; reading it, it's an attempt to *return* some
>> level of relational algebra to object databases ... all the way back
>> in 1989.
> please read it again. there is no such thing as "returning" there is
> only a thing of mapping one concept to another. Something like a
> morphism.

No, it's "returning." I read it thoroughly enough to see that they were
trying to add some level of relational algebra *back* to object
databases because what was happening in object databases was simply not
good enough.

The authors weren't quite clear enough on the concepts (despite having
clearly read C.J. Date, as referenced in the paper) to admit this,
though.

>> Sadly, the authors still think that first normal form is an
>> unnecessary restriction on the logical formation of the data -- and
>> they have to synthesize first normal form tuples to obtain relational
>> algebra capabilities in object databases.
> where?
>
> I have read: "One research direction in the modeling of
> object-oriented is the extension of the relational model to build
> complex types. Early extensions relaxed the first normal form
> requirement of the relational model to allow set valued attributes.

They don't condemn this; first normal form is something that really
makes a lot of sense in data and object modelling. They have to
*synthesize* a first-normal form for their relational algebra to even
*work*!

>> I haven't looked further, but it's not quite a positive refutation of
>> my statement.
> you claimed there is no algebra, I proved you wrong. I myself said
> there is much space for nonsense and that without constraints there
> will never be a "solution". So either we talk about such constraints
> or we end the topic. It makes no use to give more and more new papers
> just that you can say that you don't like the opinion of the author."
>
> I guess you mean a different part?

They added relational algebra to an object database model by
synthesizing a tuple for relational operations. That's an utter failure
to provide an object algebra. Read the paper again: they *clearly* say
they synthesize tuples to layer relational algebra on top of object
databases.

It's not a matter of disagreeing with the authors, it's a matter of
recognising that the paper doesn't really do what you think it does.

>>>> Sure, an object store can be set up to allow for smart loading and
>>>> such, but that *doesn't* mean that it's a good idea. It might be
>>>> the "right now" idea, but it is something you'll have to pay the
>>>> piper for using at some point in the future.
>>> depends on my goals, or not?
>> I've said as much. Right now solutions usually meet one's immediate
>> goals, but rarely meet long-term goals and often result in increased
>> costs in the long-term.
> might be true, but if your boss says that he needs to save money in
> the short term it is a different thing. For example for prototypes,
> for example for small applications, for example for applications that
> don't share data, for example for applications without the need to do
> reporting.

All of these will benefit more from relational databases than object
databases. If they're *that* small, just use a plain-old object store
(like PStore or Madeleine, if you must); don't bother with an object
database -- because you'll spend almost as much time in the short term,
and much more time in the long term, with that as you would with a good
ORM and a good SQL database.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Austin Ziegler wrote:
> On 3/29/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>> Austin Ziegler wrote:
>> > Please, please, *please* read more about relational theory before you
>> > make statements like this, because it's technical nonsense. There *is*
>> > no "object model."
>> Yet. That you know of. Yet. :)
>
> Fair enough.
>
>> Seriously, the folks in the UK that developed the PI-Calculus have done
>> some work in computer-science models of objects, but I don't know enough
>> about them to know if they're relevant to this discussion. The one
>> reference I have is on the edge of my readability scale -- if I sat down
>> with the book and the right programming language, I might be able to
>> learn it, but there are other things I'm more interested in doing.
>
> Do you have a pointer to an abstract?
>
> -austin
Sangiorgi and Walker, _The Pi-Calculus: A Theory of Mobile Processes_, 
Part VII (Objects and PI-Calculus)

This is a book ... a big book with lots of abstract computer science in 
it. The stuff I read for relaxation, because, well, mysteries and 
Westerns bore me. :)


-- 
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
http://borasky-research.blogspot.com/

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

Austin Ziegler schrieb:
> On 3/29/07, Jochen Theodorou <blackdrag@uni.de> wrote:
>>> Like I said, "model" is a vague word. When you say "relational
>>> model", the *meaning* is the "Relational Model of Data" (e.g., the
>>> theory). At this point, there's nothing related for an "Object Model
>>> of Data".
>> but the relational algebra is about queries not data in the first
>> place.
> 
> The Relational Model of Data is about how to organise the data in such a
> way that relational algebra is able to work. So your statement isn't
> really correct. Relational algebra doesn't work without the organisation
> of the data into sets of tuples and attributes.

very right, it is not only the data, it is its organization and the 
relations between them too. Might be that data is king, but only after 
it is transformed with respect to the relational model.

>>> When one says "object model", one usually means "the hierarchy or
>>> graph of objects that I am using to represent the data and operations
>>> in my implementation." In relational terms, that is a schema.
>> the operations are part of the schema?
> 
> Are you not understanding what I'm saying? I'm making an analogy here,
> not a direct correspondence.

then why did you mention the operations at all?

> What people call an "object model" is similar to a relational schema. 

ah, well I used the term different. I used it in the term of... how 
objects are related, behave and what operations can be done with them.

[...]
>>> but I consider encapsulation probably the defining feature of OO
>>> (even more than inheritance, because there are strong arguments for
>>> composition instead).
>> encapsulation in terms of grouping data together? hat is not more a
>> definition as a table is.
> 
> I can't parse this; encapsulation is, as I understand it, combining data
> and operations.

that's how OO defines encapsulation, that is not how encapsulation 
defines OO. At last that is my view on this.

[...]
>>> Just the opposite. An object model is closely related to a data model
>>> (or a database schema, if you prefer).  There's no overarching theory
>>> of object modelling (at least not yet, as Ed pointed out), whereas
>>> there *is* an overarching theory of data and relations.
>> data *and* relations, yes. A theory about data only would be useless,
>> or not?
> 
> This is basic relational theory; please read more on it.

that misses the point. I wanted to say, if you look at the OO world 
without the same relations you use in the relational world, then what is 
it worth? I mean if you take an object and rip off the methods, what is 
left then? A mere data holder, a abstract type. Or not?

>>>>> Just because one *can* create something that works without a
>>>>> mathematical theory behind it does not mean that one *should* do so.
>>>> or should not do so.
>>> Fair enough, but if one chooses to step away from something that has
>>> theoretical underpinnings, one should at least be prepared to make a
>>> coherent explanation as to why it's better.
>> coherent? "My tests are showing my application is faster with it" or "I
>> am faster in prototyping" is for some cases coherent enough.
> 
> Not at all. Performance is about implementations, not about concepts.

If something proves to be better for a certain situation in a pragmatic 
way, then I should really consider to use that.

[...]
> OO database vendors *as a class* make specious claims,

"as a class"... a class without instances?  A singleton then maybe. 
Maybe even a non existing. Sorry, I am no friend of putting a vague 
group people together and claiming that they are doing something bad.

[...]
>>>> ok, see "A Query Algebra for Object-Oriented Databases (1989)" on
>>>> citeseer http://citeseer.ist.psu.edu/shaw89query.html
>>> I skimmed through this; reading it, it's an attempt to *return* some
>>> level of relational algebra to object databases ... all the way back
>>> in 1989.
>> please read it again. there is no such thing as "returning" there is
>> only a thing of mapping one concept to another. Something like a
>> morphism.
> 
> No, it's "returning."

that's no base for discussion. returning or not does not matter.

> I read it thoroughly enough to see that they were
> trying to add some level of relational algebra *back* to object
> databases because what was happening in object databases was simply not
> good enough.

your view.

> The authors weren't quite clear enough on the concepts (despite having
> clearly read C.J. Date, as referenced in the paper) to admit this,
> though.

what concepts? You are not very clear yourself. Basically you are saying 
they have not understood the relational model and OO altogether. I guess 
they are also of your class of OO database vendors.

>>> Sadly, the authors still think that first normal form is an
>>> unnecessary restriction on the logical formation of the data -- and
>>> they have to synthesize first normal form tuples to obtain relational
>>> algebra capabilities in object databases.
>> where?
>>
>> I have read: "One research direction in the modeling of
>> object-oriented is the extension of the relational model to build
>> complex types. Early extensions relaxed the first normal form
>> requirement of the relational model to allow set valued attributes.
> 
> They don't condemn this; first normal form is something that really
> makes a lot of sense in data and object modelling. They have to
> *synthesize* a first-normal form for their relational algebra to even
> *work*!

extend is not really synthesize. And what exactly is so bad about that? 
It is a common thing in mathematics.

>>> I haven't looked further, but it's not quite a positive refutation of
>>> my statement.
>> you claimed there is no algebra, I proved you wrong. I myself said
>> there is much space for nonsense and that without constraints there
>> will never be a "solution". So either we talk about such constraints
>> or we end the topic. It makes no use to give more and more new papers
>> just that you can say that you don't like the opinion of the author."
>>
>> I guess you mean a different part?
> 
> They added relational algebra to an object database model by
> synthesizing a tuple for relational operations. That's an utter failure
> to provide an object algebra.

why? A detailed explanation please.

> Read the paper again: they *clearly* say
> they synthesize tuples to layer relational algebra on top of object
> databases.
 >
> It's not a matter of disagreeing with the authors, it's a matter of
> recognising that the paper doesn't really do what you think it does.

and what do you think that I think it does? That I can't use the 
relational algebra as it is for an object algebra was clear from the 
beginning. But that is not important here. The important thing is how a 
modification I make affects the system as a whole. If it does not 
violate other mathematic axioms then it is normally a valid model.

>>>>> Sure, an object store can be set up to allow for smart loading and
>>>>> such, but that *doesn't* mean that it's a good idea. It might be
>>>>> the "right now" idea, but it is something you'll have to pay the
>>>>> piper for using at some point in the future.
>>>> depends on my goals, or not?
>>> I've said as much. Right now solutions usually meet one's immediate
>>> goals, but rarely meet long-term goals and often result in increased
>>> costs in the long-term.
>> might be true, but if your boss says that he needs to save money in
>> the short term it is a different thing. For example for prototypes,
>> for example for small applications, for example for applications that
>> don't share data, for example for applications without the need to do
>> reporting.
> 
> All of these will benefit more from relational databases than object
> databases.

In what way? Don't come with "in the long term", mantras don't make up 
for reasons.

> If they're *that* small, just use a plain-old object store
> (like PStore or Madeleine, if you must);

small in lines of code possibly yes, that does not mean it does not have 
to query or has to handle data bigger than the available memory

> don't bother with an object database 

what bother? Depends on the database, or not?

> -- because you'll spend almost as much time in the short term,
> and much more time in the long term, with that as you would with a good
> ORM and a good SQL database.

at the moment I can't say that this is true. Maybe the solutions of ORM 
are quite good, but if you take a look in the Java world.. I really 
prefer db4o over Hibernate+HSQLDB or even postgres/mysql/oracle/xy if my 
application is "small".

bye blackdrag

Jochen Theodorou <blackdrag@uni.de> writes:

>> The inheritance relation of an ER model can be represented in the
>> table model as views. Depending on the circumstances, it might be
>> favourable to model the subclasses as distinct tables and the
>> respective superclasses as views or the other way around.
>>
>> Either way, queries over the subclasses will query the superclasses, but
>> that's not different from the OO point of view.
>
> combining it with a view is surely a good idea. It makes the queries
> more easy. I don't want to say it is different, it is just not as nice
> as with normal tables.

The point is not that a view simplifies a query over a given inheritance
relation, a view is the table model implementation of ER-inheritance.

In general - and I have sometimes learned it the hard way - you have to
be very careful about what model one is talking: usually the highest
level is the ER model which will be implemented as a relational model
that will be (or can be) normalised and at last this relational model
will be implemented as a table model.

>> As Austin already has mentioned, object modeling can be seen as a
>> special form of ER modeling - which explains the plethora of
>> dysfunctional and outright ugly object hierarchies one encounters in
>> software engineering because those people do not understand the
>> fundamental mathematics.
>
> I don't agree with austin and the resulting ugly class hierarchy is
> prove enough for me. Not in all cases of course ;)

Ah, I think I have been misunderstood: ugly object models are mostly
produced by »software engineers« who have no knowledge about the
fundamentals of ER modeling.

> Why not consider OODB mathematics as part of graph theory and others?

There is no such thing as OODB mathematics in a usable, formal sense.


Bye!

Sebastian

Sebastian Hanigk schrieb:
[...]
>>> As Austin already has mentioned, object modeling can be seen as a
>>> special form of ER modeling - which explains the plethora of
>>> dysfunctional and outright ugly object hierarchies one encounters in
>>> software engineering because those people do not understand the
>>> fundamental mathematics.
>> I don't agree with austin and the resulting ugly class hierarchy is
>> prove enough for me. Not in all cases of course ;)
> 
> Ah, I think I have been misunderstood: ugly object models are mostly
> produced by »software engineers« who have no knowledge about the
> fundamentals of ER modeling.

ER modeling is good when you want to store your objects in a database in 
the end, but that's all. Nearly any other more formal design method is 
as good as ER.

>> Why not consider OODB mathematics as part of graph theory and others?
> 
> There is no such thing as OODB mathematics in a usable, formal sense.

If I extend the relational algebra for the OO world and if I define all 
the basic functions the relational algebra does have, then I get a 
usable and formal expression. But not all that is usable for a 
mathematician is usable for real life.

bye blackdrag

"Austin Ziegler" <halostatue@gmail.com> writes:

>>> Sadly, the authors still think that first normal form is an
>>> unnecessary restriction on the logical formation of the data -- and
>>> they have to synthesize first normal form tuples to obtain relational
>>> algebra capabilities in object databases.
>> where?
>>
>> I have read: "One research direction in the modeling of
>> object-oriented is the extension of the relational model to build
>> complex types. Early extensions relaxed the first normal form
>> requirement of the relational model to allow set valued attributes.
>
> They don't condemn this; first normal form is something that really
> makes a lot of sense in data and object modelling. They have to
> *synthesize* a first-normal form for their relational algebra to even
> *work*!

Interestingly, it can be shown that the Relational Model still is
perfectly sound even if you remove the first normal-form (as opposed
to all higher normal forms).

> All of these will benefit more from relational databases than object
> databases. If they're *that* small, just use a plain-old object store
> (like PStore or Madeleine, if you must); don't bother with an object
> database -- because you'll spend almost as much time in the short term,
> and much more time in the long term, with that as you would with a good
> ORM and a good SQL database.

The real problem IMO is not that we need a "OODB" or an object
calculus (which would not be very hard to construct, there are lots of
them out there; but they are hardly useful for expressing database
operations).  It's clear to me that a good datastore will be based on
the relational model.

The real problem is it's implementation at the moment, which
constrains the developers a lot.  I argue that the following features
would take a big deal of the pain usually connected with ORM without
changing the validity of the Relational Model.

* Dynamically, strongly typed values.  (Types can be enforced (or even
  ducktyped!) by help of constraints.)

* Dynamically defined relvars.

* Dynamic fields.  (This is, in the end, dynamic relvars and DKNF).

The problem is not the Relational Model, but the current
implementations of it: they live in a world that's very different from
the one of a Ruby program.  Still, I argue that all three above
features are consistent with the Relational Model.

That said, I honestly have no idea how to implement all this
efficiently.  :-(

> -austin
-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

On 3/29/07, benjohn@fysh.org <benjohn@fysh.org> wrote:
> [1] I'd love it if there were knowledge consultants in the world. Just
> like I can go to a shop and have someone assist me in buying clothes,
> I'd like to be able to go to someone and say "I'd like to know about x",
> and they would say "ah perhaps you'd like this, this and this, then",
> and I'd say "yes, those sound good, but this isn't quite right", etc. x
> could be music, or part of biology, or international relations. And then
> I could just drink things up and appreciate everything out there that
> interests me.

They exists, though they have a different title: Librarians.

And yes, I'm fairly much serious.

Eivind.

Christian Neukirchen wrote:
> Interestingly, it can be shown that the Relational Model still is
> perfectly sound even if you remove the first normal-form (as opposed
> to all higher normal forms).

Yes. You just allow relation-valued attributes, and un/nest operators,
and you can easily define !1NF SQL. I have a paper somewhere which
studies this, and I believe it worked quite well. It also happens not
to break relational algebra or calculus at all. But that's not the
problem that needs solving, in fact it makes it slightly worse.

> The real problem IMO is not that we need a "OODB"...
> but they are hardly useful for expressing database
> operations).  It's clear to me that a good datastore will be based on
> the relational model.
> The real problem is its implementation at the moment, which
> constrains the developers a lot.

Yes. Relations are the right way to store data, objects are the
right way to manipulate them, but facts are the right way to conceive
of them, and hence to query them. Both ER and OO schemata are absorptions
of fact-based schemata to suit the physical characteristics of disk
storage and RAM storage/allocation respectively. IOW they're both
derived, to some extent contrived, for different purposes. Neither
can ever be the "one true way".

>   I argue that the following features
> would take a big deal of the pain usually connected with ORM without
> changing the validity of the Relational Model.
> * Dynamically, strongly typed values.  (Types can be enforced (or even
>   ducktyped!) by help of constraints.)
> * Dynamically defined relvars.
> * Dynamic fields.  (This is, in the end, dynamic relvars and DKNF).

What you are describing is a conceptual query language. Look at
ConQuer - not a lot of information about it is available, and
Microsoft owns (but appears not to be progressing) the only
implementation.

> The problem is not the Relational Model, but the current
> implementations of it: they live in a world that's very different from
> the one of a Ruby program.  Still, I argue that all three above
> features are consistent with the Relational Model.

Any absorption (clumping) of a fact-based schema obfuscates the
original intent. Each of the common types of absorption (ER and OO)
has its advocates, as we've seen in this thread. Can you please both
stop throwing rocks at each other and figure out how to get the best
of both worlds?

> That said, I honestly have no idea how to implement all this
> efficiently.  :-(

I do, and I'm working on it. Anyone want to help? Or are you happy
just throwing rocks?

Clifford Heath.

Clifford Heath <no@spam.please.net> writes:

>>   I argue that the following features
>> would take a big deal of the pain usually connected with ORM without
>> changing the validity of the Relational Model.
>> * Dynamically, strongly typed values.  (Types can be enforced (or even
>>   ducktyped!) by help of constraints.)
>> * Dynamically defined relvars.
>> * Dynamic fields.  (This is, in the end, dynamic relvars and DKNF).
>
> What you are describing is a conceptual query language. Look at
> ConQuer - not a lot of information about it is available, and
> Microsoft owns (but appears not to be progressing) the only
> implementation.

I was more thinking along the lines of Datalog.

>> That said, I honestly have no idea how to implement all this
>> efficiently.  :-(
>
> I do, and I'm working on it. Anyone want to help? Or are you happy
> just throwing rocks?

I'd love to have a look.  Where is the code?

> Clifford Heath.
-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

On 3/31/07, Eivind Eklund <eeklund@gmail.com> wrote:
> On 3/29/07, benjohn@fysh.org <benjohn@fysh.org> wrote:
> > [1] I'd love it if there were knowledge consultants in the world. Just
> > like I can go to a shop and have someone assist me in buying clothes,
> > I'd like to be able to go to someone and say "I'd like to know about x",
> > and they would say "ah perhaps you'd like this, this and this, then",
> > and I'd say "yes, those sound good, but this isn't quite right", etc. x
> > could be music, or part of biology, or international relations. And then
> > I could just drink things up and appreciate everything out there that
> > interests me.
> They exists, though they have a different title: Librarians.
>
> And yes, I'm fairly much serious.

And, like other knowledge workers, there are good ones and bad ones.
But yeah, a good reference librarian can be an amazing resource.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

On 3/31/07, Clifford Heath <no@spam.please.net> wrote:

> Yes. Relations are the right way to store data, objects are the
> right way to manipulate them, but facts are the right way to conceive
> of them, and hence to query them. Both ER and OO schemata are absorptions
> of fact-based schemata to suit the physical characteristics of disk
> storage and RAM storage/allocation respectively. IOW they're both
> derived, to some extent contrived, for different purposes. Neither
> can ever be the "one true way".

And there's a fundamental tension between the driving ideas of a
database and object oriented programming.

Databases come from a philosophy of separating data and it's
representation from the programs which operate on it. In the case of
relational databases, that representation is encapsulated behind an
interface defined by SQl.

To many this separation is the sine qua non of what it means to be a database.

On the other hand, Object Oriented Programming comes from the
philosophy that the representation of the data in an object should
only be known by the methods which operate on that object.  Alan Kay's
conception of an object was that it was a tiny completed von Neumann
computer with data and code co-located and encapsulated from the other
objects with which it interacts behind an interface defined by its set
of methods.

From the traditional point of view, one could consider the term Object
Oriented database to by an oxymoron, since the data representation is
not hidden from the objects which represent the data in the database.
These folks might look at OO db systems and see them as  shared
persistent object stores but not a databases.

Of course if you look at an OODB from the point of view of the
interface between client objects and database objects, the OO
encapsulation does provide that separation.  The complaint then is
that the database representation of the persistent objects is not as
portable as a more "standardized" database.  This is often a valid
point, when a requirement exists for interfacing with code outside of
the object system.

ORM approaches like ActiveRecord (and the pattern it's named after)
provide an Object Oriented interface on top of a standard relational
model.  The active record objects provide oo encapsulation between the
DB and the rest of the code, and SQL provides the DB encapsulation
between the active record objects and the actual database engine.  Of
course, the encapsulation of the OO system can be broken because code
other than the active record objects can directly access and alter
their state via SQL, but that's often an requirement, and knowing this
the issue can be dealt with.

It seems to me as if the all out war between the proponents of OO dbs
vs. the relationalists which raged in the mid-1980s to mid-1990s has
toned down quite a bit since then.  Tying this to the title of the
thread, I'd say compare OO DBs and Relational DBs to North and South
Vietnam (in no particular order). For the most part the users of these
technologies are now living in a land where the communist and
capitalist approaches have merged, and things are quite a bit more
peaceful.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On 3/31/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> On 3/31/07, Clifford Heath <no@spam.please.net> wrote:
>> Yes. Relations are the right way to store data, objects are the right
>> way to manipulate them, but facts are the right way to conceive of
>> them, and hence to query them. Both ER and OO schemata are
>> absorptions of fact-based schemata to suit the physical
>> characteristics of disk storage and RAM storage/allocation
>> respectively. IOW they're both derived, to some extent contrived, for
>> different purposes. Neither can ever be the "one true way".
> And there's a fundamental tension between the driving ideas of a
> database and object oriented programming.

I don't think that there's a fundamental tension, but that's just me.

> Databases come from a philosophy of separating data and it's
> representation from the programs which operate on it. In the case of
> relational databases, that representation is encapsulated behind an
> interface defined by SQl.

This is not correct. Fabian Pascal would have a field day with this
statement. Databases come from a formalization of the need to store
data. Hierarchical databases (and, to a degree, object databases) store
the data in the same way that the programs which manipulate the data
represent the data.

Relational databases come from the realisation that more than one
program needs to work with a given set of data, you don't want to store
more than one copy of any given datum, and there should be a formal way
of modelling such things. Thus, you have the Relational Model of Data --
which, as I have mentioned several times, is a model that represents
tuples, attributes, and relations that can be queried using relational
algebra.

Mr Heath's assertion that ER modelling is about physical storage is
completely incorrect; there *is* a physical layer that can be modelled,
but it is *primarily* about the logical layer, and the physical
characteristics DO NOT MATTER at that logical layer. You continue that
false assertion and add another one, suggesting that SQL databases are
relational databases. They are not. They follow *portions* of the
relational model, but do not completely implement relational algebra and
have followed hype and fashions to incorporate more features of
hierarchical and object data modelts because developers are fickle
creatures who aren't given enough time to really understand most of the
technology that they are required to implement or use by people who
understand even less.

SQL is, at best, an approximation of the relational model and it is
generally a failure at that, because SQL doesn't let you think in
logical terms more often than not.

-austin
-- 
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca

Austin Ziegler schrieb:
[...]
> SQL is, at best, an approximation of the relational model and it is
> generally a failure at that, because SQL doesn't let you think in
> logical terms more often than not.

say, is there a better way to make queries? I mean one that is in actual 
use in one of the big databases and that is no sql dialect.

bye blackdrag

Austin Ziegler wrote:
> Relational databases come from the realisation that more than one
> program needs to work with a given set of data, you don't want to store
> more than one copy of any given datum, and there should be a formal way
> of modelling such things. Thus, you have the Relational Model of Data --
> which, as I have mentioned several times, is a model that represents
> tuples, attributes, and relations that can be queried using relational
> algebra.

Yes, thanks for re-iterating that... full support from me.

> Mr Heath's assertion that ER modelling is about physical storage is
> completely incorrect;

Austin, please put the rocks down again, and listen carefully.
You'll see I'm supporting your view, and adding to it. Don't
immediately assume that because I said something you didn't
relate to, that you can't learn something new from someone
who's been doing relational *and* object modeling at both
conceptual and physical levels since you were in short trousers.

But before I show why I'm not incorrect, let me first say that
we have an unavoidable need to work with the physical models
we must create, and that there exist no tools (to my knowledge)
that do enough to alleviate the problems that arise from that.
It's not a problem with the relational model, but it *is* a
problem with our need for physical mappings.

 > there *is* a physical layer that can be modelled,
 > but it is *primarily* about the logical layer, and the physical
 > characteristics DO NOT MATTER at that logical layer.
 > SQL is, at best, an approximation of the relational model

You can spit all you like about how SQL causes these
problems, but it isn't really the cause; rather it's the
absence of a better alternative. Until you can point to
a better alternative, you're fighting a pointless battle
with the practitioners who maintain that relational
databases are hard to work with. You're saying they
shouldn't be hard, and you're right. They're saying they
*are* hard, and they're right. Read on to see why.

Ok, with that out of the way, let me introduce fact-based
modeling, and show how it solves problems that repeatedly
even occur in properly-designed relational databases. Sit
tight, this is going to take a while. I'll try to make it
shorter; please don't pick nits with my shortcuts until
you've seen the whole picture.

Suppose we want build a simple schema to record which types
of beer people like. We can record the following elementary
facts:

Person is known by Name.
Beer is known by BeerName.
Person is fond of Beer.

Here we have two entity types (Person and Beer), and two
things that might be value types (Name and BeerName). Each
entity type has a defined reference mode ("is known by"),
which each form a fact type that's a 1:1 relationship.
Finally we have one fact type, with the reading "is fond of",
in which Person and Beer both play a role.

Now this is enough information for most folk to work out
what's going on, but not yet enough to define a relational
schema; we need to know whether we will record whether a
person may be fond of more than one beer. I'm assuming that
a beer might be liked by more than one person, but lets
assume that my initial fact said "Person has favourite Beer"
instead of "Person is fond of Beer". It's also the case
that a given Person might not like any beer, but let's
assume that we have other reasons to record such a Person.

We can represent this model using the relation:

Person(Name*, BeerName?)

where * means primary key, and ? means null is allowed.

Further normalization requires:

Person(Name*)
FavouriteBeer(Name*, BeerName*)

which avoids the NULL value. Both are valid choices, since
they can be mapped to one another without loss - though the
former is a preferable physical model. Notice how in neither
case did we need a Beer() relation. That's because all fact
roles of Beer have been absorbed into one of the tables you
see. So far so good... until we get a change request.

We have to record all the beers a person likes in priority
order. Now the second form, which wasn't preferred because
of its additional physical cost, is preferable, because we
can simply add a column "priority" to FavouriteBeer, renaming
it PreferredBeers.

All we did was add a fact "Person has Preference for Beer",
and the new constraint allows more than one Beer per Person,
yet all our relational queries are written incorrectly, and
we have to create migration code to construct a new table,
and revisit all our queries to map to the new tables. SQL
helps a little by allowing us to construct views, but the
views can't hide the fact that the Person table no longer
has a BeerName attribute.

The story goes on... now change things so that a Name
is made up of a FamilyName and a GivenName, and again so
that FamilyName is the primary key of a Family entity which
has a functionally dependent attribute MedicareNumber. You
can't avoid such schema migrations, and you can't avoid
the fact that you must create an efficient physical schema
each time, so you wind up in a constant tradeoff between
keeping your schema clean and refactoring your queries.

Notice that I've said *nothing* here about SQL that isn't
true of any effective relational system in existence. The
need to store more than one fact per tuple (for performance
reasons) is the cause. It's these *compound facts* that
create the schema evolution problems that SQL suffers from,
yet compounding is unavoidable for performance reasons.
Hence my comments about disk storage, which I stand by.

The only solution is a system that enables us to completely
hide the physical layer from the user (from the queries),
and that's what fact-based modeling can do. The details of
how are contained in Terry Halpin's book "Information
Modeling and Relational Databases", and are implemented in
at least four significant database design tools, three of
which he designed (the other is CaseTalk, www.casetalk.com).
The most recent is an open source plugin for Visual Studio
called NORMA, which is available as a CTP as the "orm"
project at <http://sourceforge.net/projects/orm/>. Talk
about an iceberg in hell! This thing is already *way* cool.
I'm visiting the team (which Terry leads) for two days in
May before the Rails conference.

A fact-based model is still relational, and still has all
the benefits of being built on first order logic and the
predicate calculus, yet it's also intrinsically different
from what has come to be commonly known as "the relational
model".

In particular, all relevant join paths are known in the
schema or can be added without breaking it. So I can say
the conceptual query:

Person(Name@) who
    has more than 4 Preference
    for Beer(BeerName@)

where the @ sign says that I want this as part of my result
set, and this will return the names and preferred beers
(without priority details) of all beer connoisseurs. Leave
off the @ sign from Person(Name) and you just get the beer
names without repetition.

I didn't need to say JOIN or WHERE anywhere there, so it
was easy to write (also easy to build with a graphical
tool), and extensive study has shown that such queries are
highly resistant to being broken as the schema grows.

The result set is not in first normal form, BTW. It's a
tree, or in more complex cases, a graph. It starts to look
very like a de-serialized collection of objects (what I call
a fact constellation, because it selects a meaningful group
of stars from a starry sky of facts), and that's how
programmers need it to be - it immediately addresses O/RM
requirements with no further work.

This is what relational databases *should* be like, but
aren't. A raw beginner can use a graphical query builder
(like the one in InfoModeler - Google that) that would make
an experienced DBA quake in their boots. Such queries aren't
hard to translate to SQL against the underlying physical
model, as long as you preserve the derivations by which
the physical schema was created. I've written Ruby code that
already handles some cases.

The remaining problem is that the existing tools are only
design tools, that generate database schemata and static
data layers. What's needed in addition is a flexible runtime
and query processor, written in a dynamic language, and it's
to create such an animal that I registered the ActiveFacts
project on RubyForge. There's no content there yet (sorry
Christian), but if anyone who's willing to do the background
study, they're welcome to help out. I hang out on the new
Yahoo group "information_modeling", and need folk to discuss
ActiveFacts with while I develop it to the point where I have
enough on which to base collaboration.

I plan to post a significant literature review there sometime
soon, to help people to get started. It's somewhat a pity
that Terry named his method Object Role Modeling, even though
neither the word "Object" nor the acronym "ORM" had been used
as they do now... but if we agree to call it fact-based
modeling or information modeling I think we can avoid
confusion. A good overview of Object Role Modeling is at
<http://msdn2.microsoft.com/en-us/library/aa290383(VS.71).aspx>

Clifford Heath.

At 1:30 PM +0900 4/1/07, Clifford Heath wrote:
> The only solution is a system that enables us to completely
> hide the physical layer from the user (from the queries),
> and that's what fact-based modeling can do. The details of
> how are contained in Terry Halpin's book "Information
> Modeling and Relational Databases", and are implemented in
> at least four significant database design tools, three of
> which he designed (the other is CaseTalk, www.casetalk.com).
> The most recent is an open source plugin for Visual Studio
> called NORMA, which is available as a CTP as the "orm"
> project at <http://sourceforge.net/projects/orm/>. Talk
> about an iceberg in hell! This thing is already *way* cool.
> I'm visiting the team (which Terry leads) for two days in
> May before the Rails conference.

I'm a big fan of ORM2 (The current name for the ORM effort).
I'm not a database wonk, but I play around a lot with graph-
based data structures, and ORM2 fits my needs very well.  I
would like to mention 2.5 other technologies that I'm hoping
to tie together with ORM2, Ruby, and Rails.

  *  Conceptual Graphs (Dr. John Sowa, et al)

     Although CGs use a different notation than ORM2, both
     systems describe hypergraphs (graphs in which edges
     may have more than two endpoints: "John took the train
     to Chicago").  While ORM2 maps nicely into relational
     DBs, CG maps nicely into predicate calculus.

  *  Ruby Graph Library   (RGL; Horst Duchene)
     GRAph Theory in Ruby (GRATR; Shawn Garbett)

     The basic idea in RGL and GRATR is a mapping between
     graph nodes and objects.  This lets you, for example,
     ask a node about its neighbors, forward messages to
     them, etc.

It seems to me (SciFi alert) that it should be possible to:

  *  extend RGL/GRATR to have both nodes and edges as objects,
     such that you can ask an edge about the objects it links

  *  back the resulting graph by an ORM2-style database (this
     would let me ask cross-graph questions such as "which As
     have a B relationship with Cs").

  *  send links (predicates) to a KR system (e.g., PowerLoom)

In fact, I've been musing about how close Active Record is to
being able to support a subset of this scheme.  Consequently,
I found your posting _quite_ interesting.


One problem I see with using AR join tables for relationships
is that there seems to be a presumption that there is only a
single reason why a set of tables would be joined.  So, "Rich
drives a Camry" and "Rich owns a Camry" live in cars_people.

My working plan is to use a "type" field (ala STI) in each
join table to disambiguate these cases.  Not pretty, however.
The discussion in

http://wiki.rubyonrails.org/rails/pages/ManytoManyPolymorphicAssociations

hints at some of the difficulties with this approach.

Another problem is that (apparently) AR doesn't support join
tables with more than two columns.  Given that I need hyper-
edges, this loses badly.  So, it looks like I need some model
(e.g., acts as) code...


> The remaining problem is that the existing tools are only
> design tools, that generate database schemata and static
> data layers.

There's also the slight problem that NORMA requires Visual
Studio, C#, M$Windows, etc.

> What's needed in addition is a flexible runtime
> and query processor, written in a dynamic language, and it's
> to create such an animal that I registered the ActiveFacts
> project on RubyForge. There's no content there yet (sorry
> Christian), but if anyone who's willing to do the background
> study, they're welcome to help out. I hang out on the new
> Yahoo group "information_modeling", and need folk to discuss
> ActiveFacts with while I develop it to the point where I have
> enough on which to base collaboration.

I'd be happy to be part of the discussion.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm@cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

At 1:30 PM +0900 4/1/07, Clifford Heath wrote:
> ... I hang out on the new Yahoo group "information_modeling"

I've Googled around for this list and came up dry.  Help?

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm@cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

Rich Morin wrote:
> At 1:30 PM +0900 4/1/07, Clifford Heath wrote:
>> ... I hang out on the new Yahoo group "information_modeling"
> I've Googled around for this list and came up dry.  Help?

I guess Google doesn't want folk to join Yahoo groups :-)
<http://tech.groups.yahoo.com/group/information_modeling/>
It'll be good to see you there.

Clifford Heath.

Cross-posted and followups to information_modeling from
ruby-talk.

Rich Morin wrote:
> I'm a big fan of ORM2 (The current name for the ORM effort).

Hooray - someone else! ORM2 is a minor redrawing of the
graphical symbols for ORM, I'm not aware of any semantic
changes. And though the current mapper is relational,
there's no good reason not to do UML and other kinds of
artifacts from it.

Where did you come across ORM?
Did you study at Neumont/Northface?

> I'm not a database wonk, but I play around a lot with graph-
> based data structures, and ORM2 fits my needs very well.  I
> would like to mention 2.5 other technologies that I'm hoping
> to tie together with ORM2, Ruby, and Rails.

>   *  Conceptual Graphs (Dr. John Sowa, et al)
>      Although CGs use a different notation than ORM2, both
>      systems describe hypergraphs (graphs in which edges
>      may have more than two endpoints: "John took the train
>      to Chicago").  While ORM2 maps nicely into relational
>      DBs, CG maps nicely into predicate calculus.

Well, ORM has ternary and higher-order facts, but each
fact role connector has exactly two ends. The NORMA mapper
maps higher-order facts to binary ones before absorption,
which is strictly unnecessary, but simplified the XSLT
approach they were using before LiveOIAL foiled it.
The point is that you have objects types (entity, value
and nested types) and you have fact types with one or
more roles - each role is a 2-ended connector from a
fact type to an object type.

>   *  Ruby Graph Library   (RGL; Horst Duchene)
>      GRAph Theory in Ruby (GRATR; Shawn Garbett)
>      The basic idea in RGL and GRATR is a mapping between
>      graph nodes and objects.

I don't see why the objects couldn't *be* graph nodes.
You could re-open the Object class to add the required
single attr_accessor. But anyhow, you're saying that's
not what they do, and that's ok too.

> It seems to me (SciFi alert) that it should be possible to:

I'm not a graph theorist, though I studied it once, but what
you're suggesting sounds quite reasonable.

> One problem I see with using AR join tables for relationships
> is that there seems to be a presumption that there is only a
> single reason why a set of tables would be joined.  So, "Rich
> drives a Camry" and "Rich owns a Camry" live in cars_people.
> My working plan is to use a "type" field (ala STI) in each
> join table to disambiguate these cases.  Not pretty, however.

Ouch... I thought you could do this properly using has_many_through?
That said, I haven't tried it.

> Another problem is that (apparently) AR doesn't support join
> tables with more than two columns.  Given that I need hyper-
> edges, this loses badly.  So, it looks like I need some model
> (e.g., acts as) code...

I'll post my relational meta-model for ORM 2 shortly, in
the Yahoo group. It can represent (almost?) everything that
NORMA is capable of representing, and it maps to the object
hierarchy I've defined in Ruby that can already load NORMA
diagrams (though not yet constraints). This relational model
should work with AR with minimal changes, so you can use it
for your purposes.

> At 1:30 PM +0900 4/1/07, Clifford Heath wrote:
>> The most recent is an open source plugin for Visual Studio
>> called NORMA, .... Talk
>> about an iceberg in hell! This thing is already *way* cool.
>>...
>> The remaining problem is that the existing tools are only
>> design tools, that generate database schemata and static
>> data layers.
> There's also the slight problem that NORMA requires Visual
> Studio, C#, M$Windows, etc.

Well, I *did* say NORMA is an iceberg in hell :-).
But both Terry and I are, with others, keen to define
a textual language for ORM, and I'll implement that in
Ruby, or even sooner, a Ruby DSL for ORM, which I've
started. So there'll be no need for a visual tool.

> I'd be happy to be part of the discussion.

Great to have your interest, and thanks for joining
the Yahoo group. It only has a few people yet, but
it's only two weeks old too.

Clifford Heath.

On Apr 1, 2:07 am, Rich Morin <r...@cfcl.com> wrote:
> One problem I see with using AR join tables for relationships
> is that there seems to be a presumption that there is only a
> single reason why a set of tables would be joined.  So, "Rich
> drives a Camry" and "Rich owns a Camry" live in cars_people.
>
> My working plan is to use a "type" field (ala STI) in each
> join table to disambiguate these cases.  Not pretty, however.

Just a heads-up since feedback from this group would be appreciated:

I've implemented that in my DataMapper project.

RubyForge project (svn access): http://rubyforge.org/projects/datamapper
Blog (with related posts): http://substantiality.net/archives/tags/datamapper

Jochen Theodorou wrote:
> Austin Ziegler schrieb:
> [...]
>> SQL is, at best, an approximation of the relational model and it is
>> generally a failure at that, because SQL doesn't let you think in
>> logical terms more often than not.
> 
> say, is there a better way to make queries? I mean one that is in actual 
> use in one of the big databases and that is no sql dialect.

Nansen said: `Yes, there is.'

`What is it?' asked the monk.

Nansen replied: `It is not mind, it is not Buddha, it is not things.'

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Joel VanderWerf schrieb:
> Jochen Theodorou wrote:
>> Austin Ziegler schrieb:
>> [...]
>>> SQL is, at best, an approximation of the relational model and it is
>>> generally a failure at that, because SQL doesn't let you think in
>>> logical terms more often than not.
>>
>> say, is there a better way to make queries? I mean one that is in 
>> actual use in one of the big databases and that is no sql dialect.
> 
> Nansen said: `Yes, there is.'
> 
> `What is it?' asked the monk.
> 
> Nansen replied: `It is not mind, it is not Buddha, it is not things.'

hehe, ok.

bye blackdrag

Sam Smoot wrote:
> Just a heads-up since feedback from this group would be appreciated:
> I've implemented that in my DataMapper project.

(CC'ed into information_modeling - DataMapper is on
RubyForge for those folk).

It looks interesting Sam. I've not got very far into
reading it, but I like what I see. It's not heading
in the same direction as ActiveFacts, but we still
have some goals in common. Perhaps there's some room
for collaboration?

I have a couple of plans for AF that goes somewhat
against the tide of O/RM's, based on my experience
from building a very successful AR-style O/RM in C#:

* I don't believe in dynamic reflection from the DB.
   If reflection is needed it should be a manual thing
   that yields a schema file of some sort. DB schema
   don't have enough scope for documenting the original
   intent and conceptual structure - a simple list of
   tables, columns, FK's and indexes isn't a sufficient
   basis for writing good programs. Instead, the whole
   database schema should be generated from a higher-
   level schema that *is* properly annotated so that
   effective code can be generated, and result sets
   have an appropriate structure. (... and I certainly
   don't believe you should have to do a relational
   schema, an object hierarchy, *and* a set of XML
   mapping files, like iBatis for example!)

* I don't believe in fetching whole records, or in
   fetching from only a single relation (including a
   view) in one operation. Applications too often don't
   need that, and it makes lazy programmers who do it
   anyhow. Query results should be structured so they
   can reflect the sum of all the data that must be
   fetched in response to a single user action.

* I think that every row and value fetched should be
   traceable back through the query to the schema.
   IOW you can look at this value "42" and find out
   what the question was :-). This last goal is a bit
   demanding considering with AF, the query is made
   against the fact-based schema, translated to one
   or more SQL queries, potentially cached into a
   stored procedure, processed with parameters into
   one or more tabular result sets, then re-assembled
   into a graph that reflects the structure of the
   original query.

The idea here is that (for example in a Rails context)
you take the parameters from the user's context and
any submitted values, you run one query, and you get
the entire hierarchical result set for rendering the
next view. The result set is structured appropriately
too, so it can be mapped to a view that's dynamic, it
can wrap itself around a number of similar result sets.

If that sounds interesting, lets talk.

Clifford Heath.

On 3/31/07, Austin Ziegler <halostatue@gmail.com> wrote:
> On 3/31/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
> > On 3/31/07, Clifford Heath <no@spam.please.net> wrote:
> >> Yes. Relations are the right way to store data, objects are the right
> >> way to manipulate them, but facts are the right way to conceive of
> >> them, and hence to query them. Both ER and OO schemata are
> >> absorptions of fact-based schemata to suit the physical
> >> characteristics of disk storage and RAM storage/allocation
> >> respectively. IOW they're both derived, to some extent contrived, for
> >> different purposes. Neither can ever be the "one true way".
> > And there's a fundamental tension between the driving ideas of a
> > database and object oriented programming.
>
> I don't think that there's a fundamental tension, but that's just me.
>
> > Databases come from a philosophy of separating data and it's
> > representation from the programs which operate on it. In the case of
> > relational databases, that representation is encapsulated behind an
> > interface defined by SQl.
>
> This is not correct. Fabian Pascal would have a field day with this
> statement. Databases come from a formalization of the need to store
> data.

I think you misinterpret my point.

>  Hierarchical databases (and, to a degree, object databases) store
> the data in the same way that the programs which manipulate the data
> represent the data.

I don't believe that this is, in general, true. but let me get back to that.

> Relational databases come from the realisation that more than one
> program needs to work with a given set of data, you don't want to store
> more than one copy of any given datum, and there should be a formal way
> of modelling such things. Thus, you have the Relational Model of Data --
> which, as I have mentioned several times, is a model that represents
> tuples, attributes, and relations that can be queried using relational
> algebra.

I'll refer you to  Chris Dates 1975 book "An Introduction to Database
Systems." Which was the bible on database systems to folks of my
generation. Actually I'm looking at the third edition from 1981.  The
book covers the relational (using System R as the example),
hierarchical (using IMS/DB), and network (EBTG) approaches.

In the introduction, Date gives the driving reason for databases as
allowing enterprises to put their operational data under centralized
control. He gives a lengthy list of advantages from this reduction in
redundancy, reduction in inconsistency, data can be shared, standards
(various levels of enterprise standards, industry, national and
international), easier data interchange/migration, ability to apply
security restrictions, integrity maintenance, and the ability to
balance conflicting requirements.

These requirements lead to what Date calls an important goal of
database systems, 'data independence.'  This is the separation between
the database managment system and the applications which I was talking
about.  Data indepence allows applications to have different views of
the data, and to allow a DBA to change the storage structure and/or
access strategy without affecting applications.

The abstract model for this presented by Date is that the architecture
of the system has three levels, in internal storage level, an external
level (which comprises the individual views of the different
applications), and a conceptual level which provides a 'level of
indirection' between the two.  This conceptual level is what provides
the encapsulation/information hiding I alluded to.  The use of SQL as
the realization of the conceptual level for the relational approach
was just an example.

Maybe I'm just an old fuddy duddy, but this is what I learned as the
defining quality of a database system when I first encountered the
idea in the 1970s.

Object oriented databases back off just a bit from data independence
because they turn the conceptual level into a framework to be fleshed
out by the clients rather than sticking with a standard, and that's
the tension I'm talking about.

Now getting back to your statement:

>  Hierarchical databases (and, to a degree, object databases) store
> the data in the same way that the programs which manipulate the data
> represent the data.

This depends on the programs.  Some programs are written to look at
data hierarchically, or as a network.  Others aren't.  In fact the
vast majority of applications written when database systems were
introduced tended to work on sequential (usually sorted) data.  Back
then the ideas introduced by systems like IMS and CODASYL DBTG were
actually rather foreign and might be one reason why the relational
approach was widely adopted, the conceptual model looked more like an
extension and formalization of what application developers were
accustomed to back in those days.

It might be hard to see this, but for someone who lived through some
of the revolutions in information technology since the early 1970s,
it's evident.  I spent a good part of my career evangelizing
enterprise programmers about object-oriented technologies, so I know
how foreign what we take for granted these days was for the older
folks.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/