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

From: paul c <>
Date: Sat, 15 Apr 2006 23:34:00 GMT
Message-ID: <Ipf0g.26868$WI1.23319_at_pd7tw2no>

Hugo Kornelis wrote:
> (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

thanks, that msg gives me the only glimmer of understanding i can remember about this xdb.

p Received on Sun Apr 16 2006 - 01:34:00 CEST

Original text of this message