Re: Oracle transactions and DDL statements.

From: DA Morgan <damorgan_at_psoug.org>
Date: Wed, 10 May 2006 13:47:33 -0700
Message-ID: <1147294054.37699@bubbleator.drizzle.com>

Comments in-line.

peter.koch.larsen_at_gmail.com wrote:
> DA Morgan skrev:
>

>> peter.koch.larsen_at_gmail.com wrote:
>>
>>> The table creation has nothing at all to do with temporary tables. The
>>> fact is that when we deliver our software we have no idea what tables
>>> there should be.
>>>
>>> /Peter
>>>> Jim

> Hi Daniel
>

>> This statement is horrifying. I read your original post and reread it
>> again just now. It appears that faced with a business problem you
>> chose a solution independent of best practice and independent of the
>> architecture of products, such as Oracle, on which you might implement
>> it.

> First let me get this straight with you. This is not a new product as
> it has been in production for probably more than fifteen years.

Whether it has been in production for 15 years or 15 minutes you are now trying to move it to Oracle. And the database world, for all databases, changes every few years. This is not 1991 and decisions made that long ago are not going to be best practice in 2006 nor would I expect what I do today to be best practice in 2021.

> It currently runs on a wide variety of databases and operating systems all
> over the world. And it is by most regarded as the market leader in its
> domain.

Which may all be true but in no way changes my statement. Banner is a piece of wildly successful software based on Oracle. I can't state my opinion of it without using four letter words: Several of them.

> It is also important to add- in case you haven't realised this already
> - that this software is not shrink wrap software. We do not sell a new
> product every day - and probably not one each month. Also I should add
> that the configuration is not performed by ordinary end-users, but by
> highly skilled users - most likely IT-professionals in cooperation with
> domain specialists.

Doesn't matter. What you've done in the past says nothing about Oracle and nothing about what you should be doing in 2006.

>> I'd suggest that you both reconsider you choices and reconsider the
>> above statement. The above statement is so bad that I have kept a
>> copy of it to present to my Oracle students as an example of why
>> projects fail.

>
> As you might guess, this is not a failed product, but a market leading
> and highly successful product that thrives very well in its niche.

Then best wishes. But please don't make a corporate marketing decision with respect to Oracle and expect Oracle to comply with your corporation's bad design decision.

>> You've earned the dubious honor of being a "bad example"
>> at the University of Washington (though I did remove your name from
>> the slide).

>
> Honor the fool ;-)
> So please be explicit when critizicing our product.

Gladly. What you are doing precludes optimization and is unscalable.

 > So far as I guess,
> our solution will not differ from e.g. large accounting system such as
> SAP where customisation is a major part of the product.

Performing manual customization in a product like Oracle EBS, PeopleSoft, JD Edwards, Siebel, etc. is done in my experience prior to the product going into production. There are no transactions taking place on the system. You seem to be saying that your product's design is one in which at any point in time, middle of the business day, someone that buys your product can modify schemas. It is to this I am reacting. There are far better ways to implement flexibility unless I am misunderstanding the posts you have made in this forum.

>> Seriously ... your statement equates with ... I don't care about
>> security, stability, scalability, performance, or maintainability.

>
> Please motivate that statement. I have a really har time detecting
> what e.g. security has to do with all this.

You can not implement capabilities such as Fine Grained Auditing and Fine Grained Access Control on tables you don't know exist. Neither can you implement many other forms of auditing and security.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Received on Wed May 10 2006 - 15:47:33 CDT