Re: Supporting multiple oracle versions in a trigger
- From: "Jim Kennedy" <kennedy-downwithspammersfamily@xxxxxxxxx>
- Date: Fri, 21 Oct 2005 23:44:44 -0700
"Jack Addington" <jaddington@xxxxxxx> wrote in message
news:ue_5f.249169$1i.217028@xxxxxxxxxxx
>
> "Jim Kennedy" <kennedy-downwithspammersfamily@xxxxxxxxx> wrote in message
> news:wNWdnbq_CYuPwMXeRVn-tA@xxxxxxxxxxxxxx
> >
> > "Jack Addington" <jaddington@xxxxxxx> wrote in message
> > news:p_S5f.240333$oW2.157677@xxxxxxxxxxx
> >> "HansF" <News.Hans@xxxxxxxxx> wrote in message
> >> news:pan.2005.10.19.21.37.34.954878@xxxxxxxxxxxx
> >>
>
> ...
>
> > 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
.
- Follow-Ups:
- Re: Supporting multiple oracle versions in a trigger
- From: Jack Addington
- Re: Supporting multiple oracle versions in a trigger
- References:
- Supporting multiple oracle versions in a trigger
- From: Jack Addington
- Re: Supporting multiple oracle versions in a trigger
- From: HansF
- Re: Supporting multiple oracle versions in a trigger
- From: Jack Addington
- Re: Supporting multiple oracle versions in a trigger
- From: Jim Kennedy
- Re: Supporting multiple oracle versions in a trigger
- From: Jack Addington
- Supporting multiple oracle versions in a trigger
- Prev by Date: Re: Do I have to install Oracle Client for every machine?
- Next by Date: Music on USB
- Previous by thread: Re: Supporting multiple oracle versions in a trigger
- Next by thread: Re: Supporting multiple oracle versions in a trigger
- Index(es):
Relevant Pages
|