Re: sql views for denomalizing

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Wed, 03 Aug 2005 22:25:50 -0400
Message-Id: <pra8s2-1cl.ln1_at_pluto.downsfam.net>


Marshall Spight wrote:

> dawn wrote:

>> Marshall  Spight wrote:
>> > then I'd count this
>> > as a significant advantage to SQL. SQL's many-to-many handling
>> > is ... just ... beautiful.
>>
>> Beauty is in the eye of the beholder.  Think of a web page with a list
>> of students in a class.  Click on a student and you see all of their
>> classes with the attributes of each class.  Click on the class you came
>> from and you are back to that first list.  There is no need for an
>> intermediate web page to cross references these two.  They can store
>> all of their references without having helper tables to do so.  From a
>> logical modeling perspective, this is much more elegant, don't you
>> think?

>
> I'm not sure I follow this. We were talking about data structures
> and now you're talking about web pages. But it sounds like you're
> saying that a many-to-many table is not as good as having the
> two entities each contain a set of links to the other. If so,
> then you're comparing a data structure with no redundancy and
> that is therefor structurally immune to corruption, to one that
> has every datum twice, and that can get out of sync at the drop
> of a hat, and that needs every update to be done in two places.
>
> I think the first one is the more elegant. But as you say, it's
> in the eye of the beholder.
>

Aha! I believe I am beginning to understand where Dawn is coming from, though I will put much of it into the "anecdote..." thread.

The jump to the UI in the post above suggests that the suites she likes best have UI tools that are closely coupled to the data tools. As the RM specifies no UI, it remains to the developer to choose a UI strategy, and I think she is trying to "fix" this by wishes for data model features instead of UI tools. Just a hunch (hey if dawn can reason on hunches, can't i?)

My own tools build web pages directly out of the definition of the tables, with foreign keys being the primary source of auto-generated links. A table's child tables are "drilldown" links, and parent tables have little "jump" buttons next to the input. They behave exactly as Dawn suggests they should above because they ride on the table definitions. No changes to the data model needed, just a suite of UI tools that lays over the data model like sprayed-on latex.

>
> Marshall

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Thu Aug 04 2005 - 04:25:50 CEST

Original text of this message