Re: Multiplicity, Change and MV

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sun, 16 Apr 2006 01:14:45 GMT
Message-ID: <9Ug0g.69134$Jd.11332_at_newssvr25.news.prodigy.net>


"Neo" <neo55592_at_hotmail.com> wrote in message news:1145063988.166222.181510_at_i39g2000cwa.googlegroups.com...
>> while I appreciate the time invested in responses in this thread, I would
>> also appreciate it if you do not second guess my opinions
>
> Considering that you have been a non-participant in the very thread
> that you started 64 posts ago and have not clarified anyone's
> interpretation (including mine 61 posts ago), you are partially
> responsible by your lack of participation.
>
>> when promoting a personal agenda ...
>
> While I am probably more guilty of that than most others, nearly
> everyone has an agenda. For example, check yours in recent threads
> titled "The stupidest design I ever saw" and "Storing data and code in
> a Db". Even in this thread, you have an agenda, albeit a non-offensive
> one. It is to get some free opinions from "proficient people". Some
> like Bob, think it's their agenda to set people on the right path (RM).
> My main agenda is to find/implement the most flexible method of
> modelling things. My agenda seems to irritate everyone.
>
>> I would (personally) not be satisfied with a model that exonerates itself
>> of responsibility for representing constraints (which are equally
>> propositions we are trying to model after all) to the querying
>> application.
>
> Actually, I didn't express constraints limits sufficiently before. The
> experimental data model can represent any and all user-defined
> contraints and to a greater extent than RM if desired, however the db
> does not enforce any user-defined constriants stored in the db.
> Currently this is upto the code interfacing to the db. For example, if
> every person must have two arms and a mother, it can be stored in the
> db, but the db model and db itself, currently do not enforce it.
> Sometime way in the future, when it can better store/execute code
> (stored as data), this might change.
>

Forgive me for jumping in, but isn't the enforcement of constraints primarily the responsibility of the database engine? If constraint enforcement is up to the application, and more than one application exists for a particular database, then the exact code required to enforce constraints must exist in each and every application, otherwise consistency cannot be guaranteed. Put it another way: does it really matter how fast, how efficient--how asthetically pleasing a data model is if you can't rely on answers to queries? If the database engine cannot keep garbage out, then what's the point of even storing the data? Why not just return pseudorandom numbers?

Schema change can be a real pain--especially in a temporal database, but it doesn't make sense to ignore the primary function of a database schema--which is not really about organizing data, but rather about separating the wheat from the chaff.

>> but am not willing to lightly abandon the mathematical rigour that the RM
>> offers as a data model, especially in its supporting algebra.
>
> This is why I am Neo and you are in the Matrix :)
>
Received on Sun Apr 16 2006 - 03:14:45 CEST

Original text of this message