-----Original Message-----
From: owner-informix-list@iiug.org [mailtowner-informix-list@iiug.org]
On Behalf Of DA Morgan
Sent: 11 April 2005 05:55 PM

Dirk Moolman wrote:

[snip]


>>I agree with the heffalump, but it seems to me that Oracle's official
>>response would be "chuck more tin at it..."
>>
>>And more people to support it, higher running costs, more hassle etc
>
> etc
>
> I tend to agree with this statement !
>
> sending to informix-list
>
>I don't. It totally ignores the huge investment Oracle has made into
>10g such as ADDM, ASM, OMF, etc. And if you don't recognize these
>acronyms it equates to a lack of understanding of any recent release
>of Oracle.


Apologies, not trying to offend anyone here. We are still on version 9i
of Oracle (busy migrating to it), and so far Oracle involves a lot more
maintenance than my Informix systems.

Probably just a lack of setting it up 100%.

In my environment, I can use all the time I can save. It just feels
that Oracle is more flexible when it comes to tuning, but that also
means more planning and more work, which I don't have.

sending to informix-list

Dirk Moolman wrote:

> -----Original Message-----
> From: owner-informix-list@iiug.org [mailtowner-informix-list@iiug.org]
> On Behalf Of DA Morgan
> Sent: 11 April 2005 05:55 PM
>
> Dirk Moolman wrote:
>
> [snip]
>
>
>
>>>I agree with the heffalump, but it seems to me that Oracle's official
>>>response would be "chuck more tin at it..."
>>>
>>>And more people to support it, higher running costs, more hassle etc
>>
>>etc
>>
>>I tend to agree with this statement !
>>
>>sending to informix-list
>>
>>I don't. It totally ignores the huge investment Oracle has made into
>>10g such as ADDM, ASM, OMF, etc. And if you don't recognize these
>>acronyms it equates to a lack of understanding of any recent release
>>of Oracle.
>
>
>
> Apologies, not trying to offend anyone here. We are still on version 9i
> of Oracle (busy migrating to it), and so far Oracle involves a lot more
> maintenance than my Informix systems.
>
> Probably just a lack of setting it up 100%.
>
> In my environment, I can use all the time I can save. It just feels
> that Oracle is more flexible when it comes to tuning, but that also
> means more planning and more work, which I don't have.
>
> sending to informix-list

Likely you are too busy fighting off aligators to think of draining
the swamp. But my production 9i systems run without little or none
of my time required. The problem for most people is that they are
still managing Oracle 9i and 10g the way they managed Oracle 6 and 7.
Seriously ... if you don't understand those acronyms above ... you
need some serious time off for education.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

nobody wrote:

> I mean heck. I could write a simple POS (Point of sale) system using
> Cloudscape or any other JDBC compliant database and either a straight
> Java or JSP front end.
>
> All the databases will work fine. (Oracle, Sybase, SQLServer, Progress,
> DB2, IDS, etc...)

Actually this is not true. And it is that misconception that is the
heart of what I am pointing out. The exact same code doing the exact
same thing. Or put another way the exact same transaction architecture
put on all of the products you list will absolutely, definitely, and
unconditionally fail on one or more of them except by unadulterated
luck.

A wise person doesn't trust luck to make an application behave properly.

What amazes me is that this mythology, mythology that you have repeated
here, is so widespread. It may be widely believed ... but the fact that
many repeat it does not make it so.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

nobody wrote:

>> Actually this is not true. And it is that misconception that is the
>> heart of what I am pointing out. The exact same code doing the exact
>> same thing. Or put another way the exact same transaction architecture
>> put on all of the products you list will absolutely, definitely, and
>> unconditionally fail on one or more of them except by unadulterated
>> luck.
>>
> So where did you get your education in software development? You're
> clearly not an engineer.

Stanford and I now teach at the University of Washington to answer your
question.

> The point I am trying to make is that I *can* write a POS system where
> the underlying data storage is abstracted.

Which is totally irrelevant to the point I made.

> (And yes, I have written
> several applications where the client wanted database portability. Oh
> and with JDBC, you really do have it.

JDBC is irrelevant to transaction architecture. You clearly know a lot
about somethings and very little about the differences in architecture
between the major commercial RDBMS products.

> Its called abstraction of the data storage layer.

And is, as stated above, completely irrelevant to the differences in
architecture to which I refer.

>> A wise person doesn't trust luck to make an application behave properly.
>>
>> What amazes me is that this mythology, mythology that you have repeated
>> here, is so widespread. It may be widely believed ... but the fact that
>> many repeat it does not make it so.
>
> Myth?
> Junior, learn the art of software development and then talk to me.

"Junion" is likely as old or older than your father. You make
assumptions about me as on-target as those about RDBMS architecture: No
surprise there methinks.

> JDBC doesn't care what the data storage layer looks like, as long as it
> conforms to a published API spec.

And JDBC is irrelevant to what I have brought up as an issue. Perhaps
a good read of Tom Kyte's "Expert one-on-one Oracle" ... just the first
three chapters ... would help you. Well that or reading the concept
docs for the major RDBMS products but that I suspect would be asking
too much.

> Having said that, your "myth" is now grounded in reality.

I've read words without grounding in fact. JDBC is irrelevant to
tranaction architecture. JDBC is irrelevant to basic RDBMS concepts
implemented differently by different companies in different products.
You've not argued any point. You have attacked this issue as would a
politician. By ignoring that which you don't understand and repeating
your campaign slogan. You don't get my vote because your statements
are, while true, irrelevant.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

"DA Morgan" <damorgan@x.washington.edu> wrote

You first wrote:-

>Actually this is not true. And it is that misconception that is the
>heart of what I am pointing out. The exact same code doing the exact
>same thing. Or put another way the exact same transaction architecture
>put on all of the products you list will absolutely, definitely, and
>unconditionally fail on one or more of them except by unadulterated
>luck.

and also wrote:-

> JDBC is irrelevant to transaction architecture. You clearly know a lot
> about somethings and very little about the differences in architecture
> between the major commercial RDBMS products.

not taking sides with any one here, but u are out of whack when u suggest
that *all* RDBMs have different architecture to such an extent that if
a product is to support different RDBMs, one has to code accordingly. Well
that applies to only Oracle. That is, a product can be developed with
the same locking, transaction and isolation strategy for Informix,
SQL Server/Sybase and DB2 and it will work just fine. The one RDBMS
which requires a different mindset is Oracle and only Oracle.

If you read the documentation of SQL Server 2005, they clearly mention
that the main reason for introducing Oracle like versioning in 2005 is
to make it easy for ISV's who develop a product for both Oracle and SS.

rkusenet wrote:

> "DA Morgan" <damorgan@x.washington.edu> wrote
>
> You first wrote:-
>
>
>>Actually this is not true. And it is that misconception that is the
>>heart of what I am pointing out. The exact same code doing the exact
>>same thing. Or put another way the exact same transaction architecture
>>put on all of the products you list will absolutely, definitely, and
>>unconditionally fail on one or more of them except by unadulterated
>>luck.
>
>
> and also wrote:-
>
>
>>JDBC is irrelevant to transaction architecture. You clearly know a lot
>>about somethings and very little about the differences in architecture
>>between the major commercial RDBMS products.
>
>
> not taking sides with any one here, but u are out of whack when u suggest
> that *all* RDBMs have different architecture to such an extent that if
> a product is to support different RDBMs, one has to code accordingly. Well
> that applies to only Oracle. That is, a product can be developed with
> the same locking, transaction and isolation strategy for Informix,
> SQL Server/Sybase and DB2 and it will work just fine. The one RDBMS
> which requires a different mindset is Oracle and only Oracle.
>
> If you read the documentation of SQL Server 2005, they clearly mention
> that the main reason for introducing Oracle like versioning in 2005 is
> to make it easy for ISV's who develop a product for both Oracle and SS.

I never said "ALL" I said one or more in the list I provided which was:
DB2, Informix, Oracle, SQL Server, Sybase. They do not share the same
transaction model.

And whether one approaches them with ODBC or JDBC or any other driver
set will have no affect on the transaction model or best practice.

Tom Kyte clearly spells this out in the book I referenced.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu
(replace 'x' with 'u' to respond)

"DA Morgan" <damorgan@x.washington.edu> wrote in message news:1113804286.177778@yasure...
> I never said "ALL" I said one or more in the list I provided which was:
> DB2, Informix, Oracle, SQL Server, Sybase. They do not share the same
> transaction model.

there u go again. Only Oracle in the above list does not share the same
transaction model. When u or Tom Kyte mentions "they do not share", it
is not entirely true. Only oracle does not share the same model. Don't
u think there is a subtle difference in mentioning "they do not share the
same transaction model" to "only oracle does not share the same
transaction model" .

> Tom Kyte clearly spells this out in the book I referenced.

Been reading it. I have reached upto Chapter 5. Excellent book though the
obvious Oracle slant makes me chuckle. Mr. Kyte definitely knows how
to put his slanted (and incorrect views) in an interesting manner.

DA Morgan wrote:
> rkusenet wrote:
>
>> "DA Morgan" <damorgan@x.washington.edu> wrote
>> You first wrote:-
>>
>>
>>> Actually this is not true. And it is that misconception that is the
>>> heart of what I am pointing out. The exact same code doing the exact
>>> same thing. Or put another way the exact same transaction architecture
>>> put on all of the products you list will absolutely, definitely, and
>>> unconditionally fail on one or more of them except by unadulterated
>>> luck.
>>
>>
>>
>> and also wrote:-
>>
>>
>>> JDBC is irrelevant to transaction architecture. You clearly know a lot
>>> about somethings and very little about the differences in architecture
>>> between the major commercial RDBMS products.
>>
>>
>>
>> not taking sides with any one here, but u are out of whack when u suggest
>> that *all* RDBMs have different architecture to such an extent that if
>> a product is to support different RDBMs, one has to code accordingly.
>> Well
>> that applies to only Oracle. That is, a product can be developed with
>> the same locking, transaction and isolation strategy for Informix,
>> SQL Server/Sybase and DB2 and it will work just fine. The one RDBMS
>> which requires a different mindset is Oracle and only Oracle.
>>
>> If you read the documentation of SQL Server 2005, they clearly mention
>> that the main reason for introducing Oracle like versioning in 2005 is
>> to make it easy for ISV's who develop a product for both Oracle and SS.
>
>
> I never said "ALL" I said one or more in the list I provided which was:
> DB2, Informix, Oracle, SQL Server, Sybase. They do not share the same
> transaction model.
>
> And whether one approaches them with ODBC or JDBC or any other driver
> set will have no affect on the transaction model or best practice.
>
> Tom Kyte clearly spells this out in the book I referenced.

I have the book Tom-Kyte-Oracle-expert-one-on-one book and it does say
that Oracle is different from all the others, which supports the statement
that rkusenet said. ( what he said ). Starting on page 124.

It **is** relevant to point out that Oracle has gone out of its way to
be MORE complex, not less complex, when dealing with transactions compared
to most if not all other major database products on the market. ( Which is
quite humorous in light of Oracles' campaign to "reduce complexity". )

One of the reasons I believe, reading Mr. Kytes book, that there is more
complexity, is to simply provide non-blocking reads and non-blocking
writes. Having worked with just about all the non-Oracle products out
there, I would find this feature very desirable in a high transaction
environment, but the cost to implement it reminds me that this feature
is not in use in quite a few environments quite successfully. I would
hardly expect this to even be understood by a majority of systems that
choose not to use Oracle. ( SQL-Server shops especially! ) The trick
is to commit writers fast enough that the readers don't notice.

Instead, through better design of the system non-Oracle systems can perform
quite well without non-blocking reads/writes.

The downside is that the development team must know how to provide transactions
that do not block readers without help from the database engine. I've worked
in one system using SQL-Server where this is probably one of the chief complaints,
during peak usage, lots and lots of blocking writes preventing readers from
getting to the data. It is more a design of the application and the application
mindset ( COM objects etc ) that actually introduces these problems, not
necessarily a problem with the database engine. The developers choose to let
their environment literally throw data over the fence at the database without
really controlling what is happening--thus leaving the transaction at the mercy
of the database engine. In older non-Microsoft environments, most developers know
how to control their transactions, and thusly can use a non-Oracle system quite
efficiently.

I guess according to what was said about Microsoft is that they are essentially
saying they will adopt the Oracle method because they know their developers are
too lazy to control their transactions. For the smart money a manager will
have to size up their team and go with the database engine that works best for
the talent pool they can find to make their business work. Which is why the
database market will continue to have everybody-else vs. Oracle for generations
to come.

"Data Goob" <datagoob@netscape.net> wrote

> The downside is that the development team must know how to provide transactions
> that do not block readers without help from the database engine. I've worked
> in one system using SQL-Server where this is probably one of the chief complaints,
> during peak usage, lots and lots of blocking writes preventing readers from
> getting to the data.

I had the same problem in my new job wherein SQL-Server user complained of
blocking. Eventually turned out to be poor design. Well it seems only Informix
is the engine which automatically creates an index on foreign key. On all
other RDBMSs (DB2/LUW,Oracle,SS,Sybase) one has to explicitly create
an index on FKY. That's what happened in the product I am working. The
developer created FKY and just didn't care about index on FKY columns.
Result was that on non-indexed FKY tables, the table was locked whenever
master-child table join is used.

Since Oracle has versioning feature, lack of index on child table will not result in
blocking despite table scan involved.

rkusenet wrote:
> "Data Goob" <datagoob@netscape.net> wrote
>
>> The downside is that the development team must know how to provide
>> transactions
>> that do not block readers without help from the database engine. I've
>> worked
>> in one system using SQL-Server where this is probably one of the chief
>> complaints,
>> during peak usage, lots and lots of blocking writes preventing readers
>> from
>> getting to the data.
>
>
> I had the same problem in my new job wherein SQL-Server user complained of
> blocking. Eventually turned out to be poor design. Well it seems only
> Informix
> is the engine which automatically creates an index on foreign key. On all
> other RDBMSs (DB2/LUW,Oracle,SS,Sybase) one has to explicitly create
> an index on FKY. That's what happened in the product I am working. The
> developer created FKY and just didn't care about index on FKY columns.
> Result was that on non-indexed FKY tables, the table was locked whenever
> master-child table join is used.
> Since Oracle has versioning feature, lack of index on child table will
> not result in
> blocking despite table scan involved.
>
>

It is the nature of Microsoft environments to create application
abstraction from the database, either physically or logically, because
of people wanting to program in OO. This means that many developers
may not even know how to understand the complexity created by other
programmers, to the point where they can't even figure out what the
problem is that creates the blocker. The DBA gets involved using the
few tools available such as SQL-Profiler or the sysprocesses table,
but even here it is difficult to diagnose, and as such, SQL code review
is paramount. But the DBA will get blamed for the poor performance or
other errors and omissions created by the developers--it's a thankless
job. SQL-Server has limited tuning, limited-to-none log management, so
you really need to enforce index usage with table hints, and other
enforcement to make sure developers do the right things. Maybe Microsoft
will buy an old version of Oracle and come up with a new database engine.
LOL.