Re: IDJIT! Your Data Model Can't Posssibly Work!

From: Hugo Kornelis <hugo_at_perFact.REMOVETHIS.info.INVALID>
Date: Sun, 16 Apr 2006 00:36:22 +0200
Message-ID: <fvr242li6ds90k0hr9enjp4n5oj520he8f_at_4ax.com>


(crosspost to c.d.object removed)

On 15 Apr 2006 08:07:18 -0700, Neo wrote:

(snip)
>In fact I can use the experimental db to store the data (at least the
>part that I can understand) in the shown ORM diagram in a normalized
>and NULL-less manner and doesn't ever require the user to specify a
>schema, normalize data, or worry about IDs and referential integrity.

Hi Neo,

These four lines prove that you understand absolutely nothing of ORM.

ORM, NIAM, FCO-IM, and other leafs on the same branch are all methods that are _specifically designed_ to specify a schema (even with more precision and accuracy than any other method I know), normalize the data, and maintain referential and other integrity.

>Is there another tool that does similar? Does that tool store the data
>in a RMDB? If so, I assert that it won't be as flexible. Would you or
>someone be willing to demonstrate it here and compare it with the
>experimental db?

Your experimental db is intended for uses where no schema is known in advance and where the schema is not fixed. Basically, it allows any input and changes the schema to match the input. That might be great in some specific cases where this flexibility is required and where the risk of a tool that, by design, CAN'T guard against nonsensical data is acceptable.

Both the RM and ORM/NIAM/FCO-IM are intended to be used in situations where the schema is known in advance and where changes in the schema are rare and never on the fly. The very fact that a fixed schema exists allows the computer to check any input and reject input that doesn't match the integrity constraints. In my experience, well over 99.9% of all cases fall in this category - a good tool based on RM, ORM, or any other analysis/design method serves those cases well.

In the extremely rare cases where data should be handled without a fixed design, yur experimental db *might* be oof value. Though it probably faces some stiff competition - I've never investigated, but I do expect that there are already some commercial offerings for products that are designed for handling unstructered data. Those are the products you should compare your experimental db against, because that's the league you are playing in.

Best, Hugo Received on Sun Apr 16 2006 - 00:36:22 CEST

Original text of this message