Re: 3vl 2vl and NULL
From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Tue, 03 Jan 2006 23:35:51 GMT
Message-ID: <rTDuf.167703$V7.111602_at_news-server.bigpond.net.au>
>
> 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.
>
>
> Yes, if I understand your question.
> Aw, come on, it would be helpful to know whether I'm only making sense
> to myself or actually engaging in a dialog that is making sense to you
> to, even if you disagree. Cheers! --dawn
Date: Tue, 03 Jan 2006 23:35:51 GMT
Message-ID: <rTDuf.167703$V7.111602_at_news-server.bigpond.net.au>
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.
> 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.
>>>Did that make sense? Thanks. --dawn >> >>The answer to that is moot at this point. >
> Aw, come on, it would be helpful to know whether I'm only making sense
> to myself or actually engaging in a dialog that is making sense to you
> to, even if you disagree. Cheers! --dawn
Thats cool - I suspect I might disagree based on the direction to date but before deciding I wanted to qualify the problem to avoid (well reduce the risk at least) of later embarrassment.
Cheers, Frank. Received on Wed Jan 04 2006 - 00:35:51 CET