Re: Multiplicity, Change and MV
Date: Wed, 12 Apr 2006 17:44:56 +0300
"Neo" <neo55592_at_hotmail.com> wrote in message
> > What are the operators of your "data model" ?
> The fundamental one is intersection. The rest are derived from it. I
> have been through questions like this with Bod Badour and others for
> the past 5 years and they repeatedly concluded that it was impossible
> for my data model to work, so I am not much inclined to crawl up this
> fruit-less tree again.
> Whatever the underlying operators, I can demonstrate basic create,
> select, update, delete, etc. Ask me how to do something specific with
> data that you believe I can't.
> It models given data in a highly structured manner. The modelled data
> is NULL-less, normalized (no redundancies) and integrity of
> "references" is maintained by db engine.
> > > 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 ...
> > This is exactly what the relational model intended to solve. :-)
What is the difference between range and scope ?
> this rough analogy, RM is the wrench set and most applications
> (currently) are integer sizes 1, 2, ... 10. Some applications beyond 10
> might include those that are AI-ish in nature.
I think you talk about SQL here, not about RM.
> In the recent thread
> titled "Storing data and code in a Db with LISP-like interface" I
> describe a small application equivalent to nut size 12.34 and posted a
> solution to it using my data model. I invited others (including you) to
> use any other methodology to post a solution, where the solution had
> similar flexibility. No one has (as of yet). Would you be interested in
> trying, (although I think you may want to review the recent thread more
> thoroughly first)? Or I can extend the recent Judge/Bailiff/Clerk
> example in the thread title "Data Model". Or I can extend OP's
> original problem to demonstrate how in RM one would need to update the
> initial schema, possibly migrate data and update script/queries/code to
> handle new/unanticipated project requirements. Please post a RM script
> to handle OP's problem and a few typical queries and we can proceed
> from there.
I cannot post a RM script, sorry. :-) Received on Wed Apr 12 2006 - 16:44:56 CEST