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

comments imbedded

"Kin Ng" <kin_ng5_at_yahoo.com> wrote in message news:d5b3f600.0307281707.6624af82_at_posting.google.com...
> 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.
That's your problem, the constraints etc. should be implimented in the DB so if you change the tool you don't have to change the database.

>
> > > 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 - 21:12:55 CDT