(OT???): Oracle vs. MS-SQL

[Karel Zak]

On Tue, Jun 12, 2001 at 02:25:52PM +0200, Libor Mitrenga wrote:

> > Co ja si pamatuju (z byvaleho zamestnani, MS SQL 6.5, Oracle 7.3.4 a 8.0.5)
> > tak nema cenu se o MS SQL proti Oraclu vubec bavit. Vemte Oracle a na MS
> > SQL zapomente. Cena za spravu vam porizovaci naklady bohate vrati. Oracle
> > se nemusi "opecovavat", zamyka po radcich a ne po strankach, nemusi se
> > explicitne startovat transakce, atd. Pokud zvolite MS SQL poznate na
> > vlastni kuzi, co to je databaze v deadlocku, ze ktereho se nemuze dostat,
> > coz je v pripade MS SQL bezny stav. Pak budete delat ruzne tabulky
> > urcujici, ktere operace muzete poustet najednou a ktere ne, i kdyz pracuji
> > evidentne s jinymi zaznamy.
> 
> No já si myslel, že při jakémkoliv zápisu v rámci transakce do tabulky se 
> "celá" tabulka na MS SQL zamkne až do ukončení transakce.

 tzv. "velkolepe MySQL transakce"? :-)

 Oni transakce jsou primarne o moznosti vratit DB do stavu pred BEGIN, 
ale pak je tu dalsi vec a to jak se budou chovat konkurujici si operace.

 Jde to propracovat az tak ze do provedeni COMMITu jsou udrzovany dve 
verze dat takze jde cist bez cekani a zamku i data ktera nekdo zrovna 
meneni v nejake transakci. Viz. PostgreSQL a jeho Multi-Version 
Concurrency Control (MVCC).

> To je určitě nevýhoda pro MS SQL server, ale tato vlastnost nemusí "vadit", 
> když bude aplikace navržena tak, že deadlock nemůže vzniknout. Nemám 
> zkušenosti s Oracle, ale jeho inteligentní zamykání zase může zpomalovat chod 
> transakcí, ale nazahltí se server (mohou jet vedle sebe paralelně transakce, 
> které zapisují do stejných tabulek). Jinak si myslím, že deadlock může jistě 
> vzniknout i na Oracle, když bude špatně udělaná aplikace.

 Jak uz tu nekdo psal deadlock udelate snadno, staci pokud se pokusi dve
transakce "krizem" o update stejnych radek ('A' udela update dat 'a', 
'B' udela update dat 'b', 'A' se pokusi o update dat 'b' a ceka, 
'B' se pokusi o update dat 'a' a mete deadlock .. ale rozumna DB ho 
detekuje a udela rollback transakce 'B').

> Proto velmi záleží na typu aplikace a na datovém návrhu databáze a na 
> fukcích, které s těmi daty mají manipulovat. Podle tohoto bych volil DB 
> server, který je pro mě lepší. Na telefonní seznam je určitě nejlepší MySQL a 
> vůbec mi nevadí, že nemá transakce, ale jen zamykání.

 Zamykani na urovni radku vs. zamykani na urovni tabulek (stranek apod.)
tezko budete resit v datovem modelu a funkcich. Je to o tom co vam udela
vykon DB pri 100 na jednou pracujicich klientech nad stejnymi daty. Proto 
napriklad pekelny vykon MySQL jde dost dolu v testech ktere toto testuji. 
A s tim, ze klient A i B chce udelat update na stejnou tabulku udela datovy
model kulove.... 
 Pochopitelne, ze tyto zamky na radkach neco stoji, ale celkem brzo se to
vyrovna pokud je tam vice konkurujicich si klientu.

			Karel

PS. hmm.... proc ne databases na linux.cz?

-- 
 Karel Zak  <zakkr na zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz