Re: oracle - mysql comparison

"VC" <boston103_at_hotmail.com> wrote in message news:<l9DJc.98700$XM6.25133_at_attbi_s53>...
> "Alex Filonov" <afilonov_at_yahoo.com> wrote in message
> news:336da121.0407150733.5db6de1_at_posting.google.com...
>
> > According to some information M$ is going to implement read-only
> > consistency (Oracle style) in the next version.
>
> Yes, MS SQL Server is going to have multiversion concurrency control (the
> latest Yukon beta actually already has it). It'll be exposed to the user as
> SNAPSHOT isolation level.
>
> >As for correct concurrency
> > model,
>
> A correct concurrency control/model ensures that all the permitted
> transactions are serializable. In this sense, databases like DB2 or MSSQL
> implement a correct concurrency model albeit at the expense of lower
> concurrency in some circumstances. Funnily enough, none of the Oracle
> isolation levels can make the same promise, i.e. ensure serializable
> transaction histories, in any of its isolation levels. Usually, it's quite
> easy to obtain correct results by augmenting an isolation level with
> something like 'select for update', though..
>

Hm, what about SERIALIZABLE isolation level in Oracle? I don't see that it's any different from similar isolation level in MSSQL.

> >I remember one project, when data warehouse was build using MSSQL,
> > everything was almost OK, management was pleased immensely. Until they
> > started running reports. When management found out that reports
> practically
> > stopped online work, mood changed.
>
> Well, there are several possible responses to this anecdote:
>
> 1. If the described system was a true data warehouse/DSS, then there
> should not have been a problem at all since there should have been no OLTP
> activity by definition.
>

Well, this is an example of real life different from the theory. Happens all the time.

> 2. On the other hand, if the implementation was a mixed OLTP/DSS project,
> then judging by your story, the database architect was not qualified to
> design a system like that. His/her being surprised that a locking
> scheduler's reads block writes, and vice versa, is akin to a swimmer's being
> amazed that water is wet. There are several well-known approaches to the
> reporting problem such as replicating the main database to a reporting
> database, transaction log shipping, scheduling reports off-hours, etc.
>

Yeah, right. Now, tell me where to find managers who understand what kind of DB architects they really need. And who prefer architects proposing more expensive, although correct, solutions. And, of course, offline reporting (and all solutions you propose are actually variants of it) is not always what customer wants.

> VC
Received on Fri Jul 16 2004 - 11:45:57 CDT