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

Hi Galen Boyer, thanks for writing this:
> 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.
>
> > 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.
>
>

I have to agree with Galen on this. A model has to model the real world, not some abstract view of it. Ultimate flexibility comes at a price that is often higher than a less flexible solution.

Yes, businesses do change at internet speeds these days (sounds like a marketing slogan). But if the business changes faster than you can resync your db model, then you probably shouldn't be using an RDBMS in the first place. After all, 3x5 index cards offer ultimate flexibility and their structure can be changed on the fly.

While it's true that it can be quite time-consuming if, for example, your business inserts a junction record between an existing parent and child entity, you still have to reflect the change in your model (or else you don't really *have* a model). Some logical model changes will require structural changes in your physical model ... but that is just the nature of the beast we work with every day.

-- 
[:%s/Karsten Farrell/Oracle DBA/g]