Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Need SQL Server Temp Table equivalent (challenge!)

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

From: Stu Charlton <stuartc_at_mac.com>
Date: 29 Jul 2003 11:54:34 -0700
Message-ID: <21398ab6.0307291054.7db82477@posting.google.com>


kin_ng5_at_yahoo.com (Kin Ng) wrote in message news:<d5b3f600.0307281707.6624af82_at_posting.google.com>...

> > 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?

I understand what you're doing, I've done it before as well. I used to think it was the right technical solution for certain classes of problems. I think differently now.

Usually when I see "meta models" being designed in the relational database for "flexibility" it's because the turnaround time of the development group (which includes DBAs) is not perceived to be sufficient for business needs. So basically, it's not a technical problem, it's a poltical and process problem: how quickly can you develop, test, and deploy a new feature?

In some IT shops, especially where the DBAs are not closely aligned with the developers & business groups driving the feature changes, physical change turnarounds can be slow, if not barred outright.

The proper solution is to get a process in place that allows the turnaround time you need. The problem is the polticical will in senior IT management tends to be slow growing. So the developers, wary of their deadlines, take matters into their own hands. It's sometimes a lot easier to chew up I/O and CPU to workaround a business problem instead of actually fixing it. Hence "meta frameworks" and "entity beans", and "object caches", etc.

On the other hand, sometimes the business requirements really do imply a 1 to 2 hour turnaround time for data model changes (perhaps in a CAD/CAM environment or something). In this case, a meta model might be appropriate (which is why object databases have fared well in those environments).

Just my two cents. Received on Tue Jul 29 2003 - 13:54:34 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US