Re: 3vl 2vl and NULL

Frank Hamersley wrote:
> 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'm presuming no such thing. I'm talking about the model of the data needed for the screen. To answer David's question too, if you were to prepare a diagram of your choice, perhaps UML these days, of the logical data model that a software application needs for interfacing with the database and the logical model it needs for the UI, choosing the same entities and attributes to model, your UML diagrams would be different. Given there is an industry arising from this along with the OO-RM impedence mismatch, I think this is rather well established.

We take data in from a screen as strings, change them to objects based on specifications in code or parameter data, and then to relations based on specifications in code or parameter data, with each process validating everything along the way. The RDBMS takes those relations, validates with constraint logic likely written in a different language than the other validations, and turns the data into strings to be stored.

That doesn't seem efficient in either machine or people time for both development and maintenance activities. Or am I missing something?

> * see below.
>
> >>[..]
> >>
> >>>>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,

Can you point me to some emperical data that indicates that? And even if that were the case, are there corresponding gains to making the RM the interface between dbms and humans (developers)?

> 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.

There are greater risks for some types of problems in one scenario and others in the other. I don't know how to go about getting emperical data about the quality of data and processes over time using one approach compared to another.

>
> >>>>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?

I was cross-dressed, so I just assumed you were too.

> 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!

I don't understand -- you'll have to pass along a picture. Cheers! --dawn

> [..]
>
> Cheers Frank.
Received on Sun Jan 08 2006 - 09:10:32 CET