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