Re: 3vl 2vl and NULL

From: dawn <dawnwolthuis_at_gmail.com>
Date: 3 Jan 2006 18:40:46 -0800
Message-ID: <1136342446.804011.272340_at_g47g2000cwa.googlegroups.com>


Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> >>>Frank Hamersley wrote:
> >>>>dawn wrote:
> >>>>[..]
> >>>>>>If there's something wrong with SQL, can you identify what's wrong?
> >>>>>
> >>>>>I believe that over the past couple of years I have identified several
> >>>>>things that make it a less productive tool than what I might want.
> >>>>>I'll give just one example: You cannot back an arbitrary "screen" (UI,
> >>>>>e.g. web page) with a SQL VIEW even though views need not be
> >>>>>normalized.
> >>>>
> >>>>G'day Dawn, I am intrigued as to what an arbitrary screen is and what
> >>>>the hitch is in using a view to populate it? Can you please elaborate?
> >>>
> >>>Thanks for biting, Frank (and I'm always charmed by the "G'day Dawn"
> >>>greeting from folks down under so I'm guessing that is where you are).
> >>
> >>Spot on Dawn. Shall we say it is a nibble to date ;-)
> >>
> >>>After David decided to bypass my response to his challenge, I decided I
> >>>would write this one up in one of my first entries in the blog I'm
> >>>starting in the new year. I'll give a quick response here, but I'm
> >>>hoping it is not too irritating to point you to the blog entry after I
> >>>post it.
> >>
> >>Nope - I will happily take a look though I think I can guess the POV
> >>that will be propounded there.
> >
> > Yes, I'm sure. I figure I have done enough research and chatted in
> > this forum enough to at least start writing up both facts and opinions
> > (trying to ensure the reader knows which is which) in an effort to help
> > move the industry in a direction that I think is forward. I recognize
> > there are still many relational theory proponents who will disagree. I
> > might bore cdt readers, but will try not to.
> >
> >>>The question is not whether one can use a (SQL) view to populate a
> >>>screen, but how one would prepare a (not-necessarily SQL) view to
> >>>precisely model a screen. What is the data model behind a screen that
> >>>has a set of radio buttons, a drop-down checklist, a multi-selection
> >>>drop-down, and a name and address, for example? So I'm not suggesting
> >>>that the data could not come from a SQL view, but that it cannot be
> >>>modeled by one.
> >>
> >>"by one" - did you mean a single view to describe the entire screen
> >>layout prior to rendering the data that "backs" it? For instance
> >>something like ...
> >>
> >> SELECT * FROM screens WHERE screen = "a_screen_name"
> >
> > Yes, if I understand your question.

>

> Is there a doubt? I have segmented the "back" phrase into one of two
> possibilities (a) the data to be rendered on the "screen", or (b) the
> screen metadata? that describes the exact layout of elements on the
> "screen". I thought you were addressing (b). Am I correct so far?

I think of modeling data with both tags (domain names) and values. Take a simple screen for displaying a person's first name, last name, all values for e-mail address and first names of all children. We can surely model this data with multiple relations and we could also use a single relation with nested relations to model it if we add in data for ordering, but we cannot model this view of the data with an SQL view. We could potentially have a cartesian product view that includes all of the data for the screen, but it does not use the same data model as the view. The data model for the screen is not in 1st normal form and SQL requires 1NF.

> > It is not just the values that I
> > want to be able to get, but the form, the data model, behind a screen
> > view of the data. It is easy enough to put an XML document behind a
> > screen, for example, retaining the shape of the data.

>

> Easy for you - not necessarily "easy" in terms of the number of
> instructions executed.

by whom? If you are referring to performance, I understand that concern. It is the data model that XML can handle that is of more interest to me that XML itself. If I suggest you model it using JSON (or any associative array that can include arrays as values), is that better? --dawn Received on Wed Jan 04 2006 - 03:40:46 CET

Original text of this message