Re: Oracle transactions and DDL statements.

DA Morgan skrev:

> Comments in-line.
>
> peter.koch.larsen_at_gmail.com wrote:

[snip]

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

Our product did evolve since 1991 as well.

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

We surely do not market our product that way. Basically, we run the product in the environment present at the customer. If the customer wants Oracle, we'll do our best to give it to him.
> >> 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.

What happens with our system is that there is a testbed isolated from the production system. The system is tested here before being installed in the production system - well, what do you expect? We're not lunatics.

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

Of course not. The "upgrade" takes place perhaps three times a year. I have not had any mention of the frequency. Still, it is most annoying should the upgrade fail. Particularly on the testbed, where these changes are made perhaps several times a day. Also, when playing with the system and making an error that causes the system to not upgrade (that is the database or other parts of the system aborts), you have to stop the system and manually remove the tables that should not have been installed. This is a pain in you-know-what for the developers (but of course not a show-stopper).
> 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.

Reading this post makes it evident that you (and perhaps others) simply haven't understood our product. To repeat, we do not in a production system create new tables on a daily basis, but rather perhaps three times a year (and an upgrade would not necesarrily require new DDL-statements in our transaction).
I've reread the entire thread in search for a post that could be understod as if we would ever do so on a "daily" basis. Of course not - and how could you ever assume so?

The inability by Oracle to abort DDL-transaction is still a major nuisance for the users of our testbed. Our software relies on the fact that ABORT means ABORT and not just abort after the last DDL statement. As a consequence whenever we play with the system and something fails, we need to do a manual repair job (or backup the database first). This does not make our system unusable, but it certainly is a major inconvenience. Compare it to having to reboot your system every time you made an error and you will have an idea what I'm talking about.

> --
> Daniel A. Morgan

/Peter Received on Wed May 10 2006 - 16:41:33 CDT