Re: Supporting multiple oracle versions in a trigger

"HansF" <News.Hans_at_telus.net> wrote in message news:pan.2005.10.21.03.44.24.804784_at_telus.net...
> On Thu, 20 Oct 2005 20:20:37 +0000, Jack Addington interested us by
> writing:
>
>
>> Any thoughts are greatly appreciated.
>
> Yes, I have thoughts. Four specific ones at that:
>
> 1) Based on the questions you have been asking in this forum over the past
> few weeks, I strongly encourage you to get Thomas Kyte's book as found at
> http://apress.com/book/bookDisplay.html?bID=10008 and read at least the
> first 3 chapters. That book will provide you with the information you
> need for development, as well as tuning tips and performance measurement
> techniques.
>
> This is, in my opinion, the smallest investment you can make to have the
> possibility of success with your project.

    I ordered the book - I have gleaned lots from AskTom and I appreciate the

> 2) You remind me of me about 20 years ago. I 'blew away' some fellow
> contractors with my dynamic data driven system in SQL/DS.
>
> After the third set of patches, that were basically about twice as large
> as the original system, I came to realize that small, dedicated,
> maintainable systems were the real requirement. Flexibility was just
> tickling my ego.

Apart from knowing you 20 years ago I completely agree that simple is better. I'm don't think my design is getting to complex given the feature set / business rules goal. I am all for removing 'cuteness' though where ever I can. I content putting my time / effort into the backend so I can remove future frontend maintaince. I really have very little dynamic sql, other than the stored proc in question which has about 15 lines of code and is basically a big loop to process all the fields in a collection.

> 4) In any case, your solution is not going to be very scalable. And your
> documentation requirements, even to support yourself, will ultimately be
> larger than the program itself.

Where do you see the major scalability issues? In terms of data collection I have what seems to be to be a basic and flexible design with 5 large partionable tables to store my data and then 2 header tables to link the data together and back to all the collection paramaters (user, date, purpose, project, etc).

I could see that creating/dropping tables on the fly with dynamic ddl might be an issue with people accessing the data in a transactional manner but that is not the case. The process to modify the data collection is a separate administrative business fuction that is the exception to daily work.

thank you kindly,

Jack Received on Thu Oct 20 2005 - 23:58:07 CDT