Re: Multiplicity, Change and MV

From: x <x_at_not-exists.org>
Date: Tue, 11 Apr 2006 11:10:36 +0300
Message-ID: <e1fo8u$jel$1_at_emma.aioe.org>


"Neo" <neo55592_at_hotmail.com> wrote in message news:1144709834.166897.135080_at_g10g2000cwb.googlegroups.com...
> > Change bothers me. Especially in database schema, and specifically when
we want to accomodate change in the cardinalities of the relationships we are modelling.

> On the plus side, the new data model is so generic that it can handle a
> wider variety of applications than practical with any one existing
> methodology (ie hierarchal model, network model, relational model,
> etc). Another plus side is that existing queries and code are more
> resilient to future changes.

What are the operators of your "data model" ?

>Conversely, there are a number of down
> sides, the main one being that it is less efficent within the scope of
> a more specialized methodology, another being more complex
> queries/code/script.

This is exactly what the relational model intended to solve. :-)

> Below is an abridged script which show how the initial query to find
> what courses a lecturers teaches is unaffected by going from one course
> to many. Note that in my method of modelling, all constriants (except
> referential integrity) requires user code (at this time) where as RM
> can implement basic one directly at db level.
>
> // Store Tom teaches French in db.
> (create tom teach french)
>
> // Store Bob teach English in db.
> (create bob teach english)
>
> // Recall what Tom teaches.
> // Returns 1 thing: french
> (select tom teach *)
>
>
> // Store Tom teaches German.
> // Note, I don't have to modify schema to allow this.
> (create tom teach german)
>
> // Recall what Tom teaches.
> // Returns 2 things: french and german.
> // Notice the original query works!
> (select tom teach *)

 How is your "data model" different from "unstructured data model" ? Received on Tue Apr 11 2006 - 10:10:36 CEST

Original text of this message