Re: 3vl 2vl and NULL
Date: Sun, 08 Jan 2006 01:42:18 GMT
Message-ID: <_5_vf.209801$V7.138519_at_news-server.bigpond.net.au>
dawn wrote:
> Frank Hamersley wrote:
>
>>dawn wrote: >> >>>Frank Hamersley wrote: >>> >>[....] >> >>>If the data model visualized on the screen has one instance of an ID >>>and the SQL view backing that screen has many instances of this same ID >>>value, then the data models are different. >> >>Are we talking about the model or manifestations of it (instances)?
>
> We are talking about the logical model itself, but perhaps using that
> term differently. A logical model that is in first normal form is
> different from a model of that same data that is not. They are not the
> same model simply because they model the same thing. Trees, networks,
> and relations might all model the same data, but they are not the same
> model. The model associated with a screen of data is not typically a
> no-repeating-groups relation as required if it were to be output
> directly from a SQL-92 view.
You are presuming that visibility of all the data on the "screen" is mandated. Personally I have no such hang-ups*.
>>[..] >> >>>>I think you have expressed most clearly the core of the problem >>>>troubling you. It seems you can't accommodate the SQL outcomes because >>>>it doesn't have a "shape" that you are comfortable with. >>> >>>I'm actually quite comfortable with it, but I don't see an advantage to >>>using it to the extreme typically employed with SQL-DBMS's. >> >>I'm missing something - what is the "extreme" bit?
>
> If there really is a reason to have data in base relations with no
> repeating groups, surely that requirement goes away with relations that
> are logical views of the data. SQL permits views not to be in 2NF,
> 3NF, BCNF, 4NF, ... but took this notion of no repeating groups to the
> extreme and requires it even in logical views of the data.
As DC said I don't see any reason for exchange of information from the DBMS to the Screen App to be exclusively 1NF in the strictest sense. I suspect you feel that "softness" weakens the process more so than the 2VL/MV no translation mantra holds.
I disagree - there are measurable gains to be had in adopting the RM for the storage engine that, IMO, outweighs any perceived cost of developing and maintaining a dialect to transfer information from it to a application. In my view the 2VL/MV actually allows, nay encourages, that "softness" to find its way into the repository, which in the wrong hands is a Bad Thing tm.
>>>>That is >>>>something for you to deal with although I suspect you are not alone. >>>>The vast number of cursor happy application developers are a testament >>>>to that. >>> >>>I like set manipulations, but have no need to block other types of >>>access where useful. >> >>So do I, and I rarely find other types of access useful. Admittedly >>there are some and I will freely confess to the occasional use of a >>cursor as a last resort. >> >> >>>>Good luck on the journey Grasshopper! >>> >>>Much appreciated Master. >> >>Thats a good first step :-)
>
> I've worked with men my entire career.
How do you know I was not cross-dressed at the time of writing?
BTW I don't know if google will explain the various antipodean male rituals but be assured that is a certainty at some stage - often attended shortly thereafter by copious amounts of fermented fluids!
[..]
Cheers Frank. Received on Sun Jan 08 2006 - 02:42:18 CET