Re: 3vl 2vl and NULL
Date: 5 Jan 2006 19:41:58 -0800
Message-ID: <1136518918.587014.85120_at_g14g2000cwa.googlegroups.com>
Frank Hamersley wrote:
> dawn wrote:
> > 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.
>
> Que? - why not? It seems quite trivial to me!
>
> > We could potentially have a cartesian product view that includes all of
> > the data for the screen,
>
> Of course. It is somewhat clunky but you have selected certain
> impractical requirements and compliance does not come without
> inhibitions to style.
>
> > but it does not use the same data model as the view.
>
> Of course it does and if the screen functions as expected that merely
> confirms this is the case.
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.
>
> > The data model for the screen is not in 1st normal form and SQL
> > requires 1NF.
>
> As DC said below in practical terms it doesn't need to be compliant in
> this regard anyway. The only reason I would entertain otherwise is to
> disprove your claims.
>> > (or any associative array that can include arrays as values), is that
> >>>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
> > better? --dawn
>
> 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.
> 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.
> Good luck on the journey Grasshopper!
> BTW may good fortune also attend
> the blog.
Thanks, Frank. I don't know how many cdt readers will take the journey with me as there are a lot of relational disciples here who might have had enough of me. I will only announce the first entry here. I am working hard to ensure it is accurate, easy to tell when I am stating facts compared to opinions, bold, and a good read. It will come out next week. Cheers! --dawn Received on Fri Jan 06 2006 - 04:41:58 CET