Re: Supporting multiple oracle versions in a trigger

"Jack Addington" <jaddington_at_shaw.ca> wrote in message news:ue_5f.249169$1i.217028_at_pd7tw2no...
>
> "Jim Kennedy" <kennedy-downwithspammersfamily_at_attbi.net> wrote in message
> news:wNWdnbq_CYuPwMXeRVn-tA_at_comcast.com...
> >
> > "Jack Addington" <jaddington_at_shaw.ca> wrote in message
> > news:p_S5f.240333$oW2.157677_at_pd7tw1no...
> >> "HansF" <News.Hans_at_telus.net> wrote in message
> >> news:pan.2005.10.19.21.37.34.954878_at_telus.net...
> >>
>
> ...
>
> > Ouch! This is a very unscalable solution. Let me ask a question, when
> > you
> > write code in C or Java do you just make everything a generic object or
> > use
> > a generic struct? Why would you do that in a database? (other than it is
> > possible)
> > Jim
> >
>
> Jim,
>
> What is so unscalable? Performance? Size? If you can suggest, other than
> ask rhetorical questions, where you see problems that would actually be
> helpful to me. I'm always looking for feedback I can use and am quite
> flexible on my implementation design.
>
> Right now though:
>
> - I/my clients have unlimited re-use of data collections and data fields.
> - I can add/support a new client in the database in 10 minutes
> - I can build a new data collection form in minutes
> - I can extract/merge my data into any format
> - I can transpose any dataset consisting (number,string,date) provided by
a
> 3rd party as a view to be merged into my data
> - I can inherit/create hierarchical data collections based on prior
existing
> collections and capture/share data from two distinct sources
> - Ditto for data extractions
> - I can almost instantaneous extract data from any collection across any
> time period and merge it for multivariate analysis (access to any piece
of
> data based on time, site, subject, project, etc) is all primary key
lookups.
> - Clients can add/modify their data collection requirements in minutes
> without IT/dba support or new front-end code release
> - Clients can connect to the database with 3rd party sql tools and access
> their data in a standard table/column
> - I can add 'skins' to the front end GUI to hide any abstractions of the
> data layer yet maintain different client data requirements without
> re-releasing the software or changing the database schema
>
> Thanks for you time.
>
>
>

You are going to serialize on latches big time. I worked one place where this type of thing was done. The other engineering team didn't believe the database engineering team. They "knew" better. The product went out the door and clients started calling. No one could use the system when the engineers who "knew" better than us when their code ran. It would bring the system to its knees. we fixed their code and they accomplished the task in a different manner. We got a 5 X performance improvement and no one knew when their code was running. (the other clients could do work at the same time.)

Read Tom Kyte's book. Read the Application Developer's Guide (esp the performance part). You can get a free copy of the Oracle docs (which as a developer you should have read first, no really) at otn.oracle.com. (or on the CD;s with the software) You can also get Tales of the Oak Table. Nice story in there about the project where one developer tried a similar idea. Sounded fantastic, ultimately flexible, on demand reconfiguable. (result, it sucked and after millions of dollars the guy was fired and they went with a commercial app. One of those that used "old fashioned traditional methods".)

Seriously, when you write a C program do you create a generic object or struct with a pointer to one of each type? Of course not. Why would you think it would be a good way to do things in a database. My question isn't really rhetorical it is based on decades of varied experience.

Jim Received on Sat Oct 22 2005 - 01:44:44 CDT