Re: Need SQL Server Temp Table equivalent (challenge!)

Galen Boyer <galenboyer_at_hotpop.com> wrote in message news:<ur84ad21p.fsf_at_standardandpoors.com>...
> On 26 Jul 2003, kin_ng5_at_yahoo.com wrote:
> > Perhaps I can illustrate this idea with an example.
> >
> > A typical Product's relation design may include the product
> > master, Brand, Subbrand, Brand Extension etc. What happens if
> > we don't define Brand, Subbrand, Brand Extension etc but
> > instead create a structure such that these kind of
> > relationships can be "soft coded" so to speak.
>
> This is, and has been, my point. You aren't using the relational
> model to constrain the relationships (read what you say, what if
> we don't create the relationships?). You sacrificed the safety
> of relational constraints for future flexibility.
>

Even I have to agree somewhat with you on this point. However, my constraints are not implemented on the DB level but on the application level. This mostly is stored procedures. Normally I would have the same reactions as you when somebody says they want the program to control the verification logic instead of the DB. But for the flexibility of our system in adopting changes to the business, this is the extreme we have taken. Also an assumption of our design was that only IT will make most of the relationship changes (via the GUI front end of our system). Again, this is a compromise.

> > I have always felt that the relation model tend to represent
> > what is current and lacks the flexibility of self-changing,
>
> Eh? The main idea is that the relational model, "models" your
> business.
>
> Its sort of like, if you are selling close, then you model your
> store to display close. If, tomorrow, you decide to sell coffee,
> then, you will have to change something about how your store is
> laid out. Same thing with the relational model.
>
> >
> > sort of like the OS's self tuning...
>
> Not sure how you would think that the OS wouldn't protect its
> internal structures whether it tunes access to them or not.
>
> > That was the idea of our design. Let's face it, the pace of
> > change in the current business world is fast and changing a DB
> > model is slow, relatively speaking.
>
> I disagree completely. The change to the relational model just
> usually happens well after the business has already changed.

That's precisely the problem we had...many lost business opportunities. In order for the Business to change, they have to wait for the IT to change. Otherwise there is no infrastructure to support the Business model changes. With our design, we IT can change quickly. End result is the company benefits tremendously. It sometimes is more important than my inherent desire to be pure with the relationship model…come to think of it, we almost only use 3rd normal form, never goes down to 5th… Received on Mon Jul 28 2003 - 20:07:39 CDT