Object/Relational Mapping is the Vietnam of Computer Science

[Rick DeNatale]

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.

 

[Austin Ziegler]

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]

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

 

[Hazel and Joe]

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

 

[Daniel DeLorme]

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

 

[Austin Ziegler]

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

 

[James Edward Gray II]

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

 

[Mark T]

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

 

[Daniel DeLorme]

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.
http://en.wikipedia.org/wiki/Graph_(data_structure)

Daniel DeLorme

 

[Austin Ziegler]

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]

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

 

[Daniel DeLorme]

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

 

[ara.t.howard]

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

 

[Austin Ziegler]

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.

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.

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

 

[Clifford Heath]

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.

 

[Daniel DeLorme]

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

 

[JONNALAGADDA Srinivas]

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

 

[benjohn]

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.

 

[Alex Young]

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?

 

[Eleanor McHugh]

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.