Re: Flamewar object databases vs. relational databases

From: Carl Rosenberger <carl_at_db4o.com>
Date: Mon, 4 Jun 2001 14:52:47 +0200
Message-ID: <9fg0bp$cq9$02$1_at_news.t-online.com>


Todd Gillespie wrote:
> I also hope that bringing some real code in here might raise the level of
> debate. For instance, I take real opposition to Carl's complaint that he
> spent 1:45 hours debugging his SQL statements, when 80% of his code deals
> with Java type-casting and awkward string handling.

Please allow me to use pronounced examples.

Conversion of data to and from relational databases is a common issue for problems with:

- dates
- rounding floating point numbers
- rounding currency
- different character encodings
- null values

No doubt OR-mapping-frameworks solve these problems

- at the cost of performance
- with another layer that needs resources
- with another layer that can cause locking and concurrency problems.

The comments of Rico and Marten Feldtmann in this direction are excellent.

> That he fails to wrap them in a transaction and
> then posts lots of nonsense on here about
> managing multiple user environments.

If you download the benchmark code, the running code is enclosed in a transaction. Please, if you do comment on "nonsense", place it near the actual "nonsense" so I can defend myself.

> That filling 4 tables at once to
> store one object (eg, person, customer, document, contract to store a
> contract) completely is stupid in any real application (wherein a row is
> written to contract referring to existing person & document rows (possibly
> person_contract_map as well)) as reflects a naive OO view of data.

Excuse me for using this example for insertion and selecting from 4 tables. I tried to use objects that anyone understands. I didn't want to bore you with real life examples like:

class Contract
class ServiceContract extends Contract
class FacilityManagementContract extends ServiceContract class ContractCompanyX extends FacilityManagementContract class ContractCompanyXSpecialFees extends ContractCompanyX

Yes, we did need separate tables for every hierarchy, since every single one added somewhat 30 columns.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
Received on Mon Jun 04 2001 - 14:52:47 CEST

Original text of this message