Re: IDJIT! Your Data Model Can't Posssibly Work!
From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 15 Apr 2006 23:34:00 GMT
Message-ID: <Ipf0g.26868$WI1.23319_at_pd7tw2no>
>
>
> 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.
>
>
>
>
> 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
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