Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Marshall wrote:
> The answer to this question begins with "structure, integrity,
> manipulation."
>
> Structure is the least of these, but even here, the RM has
> significant advantages. The RM has a theoretical foundation,
> in the form of set theory and predicate logic. It also has
> mathematical formulas for eliminating schemas that are
> subject to update anomalies.
>
> http://en.wikipedia.org/wiki/Database_normalization
>
> It is hard reading, and you'll probably have to get further
> background info.
>
> Integrity includes the ability to have the dbms automatically
> enforce declared invariants on the data. All that is necessary
> to have this is to state the invariant formally, in the language
> of the dbms. No if/then, no tracking down the various places
> relevant updates happen (or maintaing that, as new updates
> are added,) no translating a formal requirement into procedural
> code: you just state the invariant, and all updates that break the
> invariant are rejected.

Here you mean constraints?

> Manipulation includes the "rich queries" you mentioned. One
> thing often underestimated is the importance of ad hoc queries
> due to ad hoc analysis needs. If your data is only available
> behind a programmatic interface, then any analysis you want
> to do means you have to write and compile code. You can
> do an amazing amount of analysis on a database by simply
> typing in interactive one-off SQL queries.

I agree, and have been often querying database intensively to find out different informations when required. To write OO code to to this for me would be madness.

However, that is not something a non programmer can usually do. Surely you're not suggesting that app should be so implemented that the end user writes SQL statements? Who would be able to use such app?

> Notice how none of these things require persistence, and how
> they are are useful whether the data is long-lived or transient.

I don't understand - unless I'm mistaking, all of these are related to tables which then implies persistable data.

> OOPLs have nothing to compare with any of these things.

They most certainly don't. That's why I like and use RDBMSes, and presume that other OOers have some similar reasoning for using them.

I like OO because it has rich capabilities for abstracting - programming to an interface and polymorphism being my favorite mechanisms. This then allows me to separate conceptual (more abstract) parts from the implementational, more technology specific parts. This also allows me effective resolving of complex ifological problems, as well as runtime variations of a behavior.

How do you deal with such problems in RDBMS?

Sasa Received on Sat Jun 03 2006 - 08:19:15 CEST