Re: 3vl 2vl and NULL

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

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

Relevant Pages

  • Re: Bit Datatype - Solved
    ... I suspect I know what I did. ... I have another table called Login with a key LoginID - no nulls ... The only way I can re-create the error is doing a stupid relationship to ... MS SQL Server 2005? ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Standard Programming Languages
    ... proficient in SQL and C, I suspect the goal of all of these products ... I suspect that the average analyst/investor is not familiar ... SQL or C. IMO, if they do not achieve the previously mentioned goal, ...
    (misc.invest.stocks)
  • Re: DATABSE IS SUSPECT BECAUSE OF MISSING FILES
    ... situation including resetting the suspect status. ... Andrew J. Kelly SQL MVP ... > missing files that SQL needs in order to remove the DB ...
    (microsoft.public.sqlserver.connect)
  • Re: Mirror one table from 1 db to another
    ... I suspect the answer is no. ... issue some SQL to merge regularly. ... Your inserting rows present on DB B that are not present on DB ... The WHERE clause filters out all the rows where all nonPKfields are ...
    (microsoft.public.data.ado)
  • Re: Opinions on approach, please...
    ... Code conversion is much more tricky. ... to update more than 32k records without a commit in-between. ... I advise you to do cursor definitions on working storage). ... I don't want to see ANY SQL code in them. ...
    (comp.lang.cobol)
Loading