Re: 3vl 2vl and NULL
From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Thu, 05 Jan 2006 06:42:06 GMT
Message-ID: <2d3vf.179400$V7.67732_at_news-server.bigpond.net.au>
>
> 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.
>
> 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
Date: Thu, 05 Jan 2006 06:42:06 GMT
Message-ID: <2d3vf.179400$V7.67732_at_news-server.bigpond.net.au>
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,
> 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.
> 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
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.
Good luck on the journey Grasshopper! BTW may good fortune also attend the blog.
Cheers, Frank. Received on Thu Jan 05 2006 - 07:42:06 CET