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

[Karel Salavec]

Dne Út, 12 čen 2001 jste napsal(a):
> On Tue, Jun 12, 2001 at 02:25:52PM +0200, Libor Mitrenga wrote:
> 
> > 
> > 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).

dtto Oracle

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

Naprosty souhlas.

Dovolil bych si jeste pripodotknout - z praxe vim, ze i pri znacne zatezi (cti
podstatne vyssi, nez je dimeznovane zelezo) Oracle stale jede. Sice pomalu, lae
jede. Nechci rikat, co v takovem pripade udela M$ SQL (a davat to pak do kupy
... :-((( )

Dalsi, dosud nezohlednene (fuj, to je slovo) hledisko je bezpecnost. Pokud se
vam nekdo dostane na M$ SQL, ma moznost plne vlady nad strojem (a neda se to
vypnout!). Oracle vyslovne nuti k tomu, aby db bezela pod neprivilegovanym
uzivatelem.
Dale overovani uzivatelu do M$ je pres OS - cili presne to, co bylo ve
starsich verzich silne vytykano Informixu. 

K vykonu se vyjadrovat nehodlam, na to jsou testy renomovanych i mene
renomovanych firem. Ale vim, ze pokud mela byt M$ SQL konkurenceschopna, tak se
to neobeslo bez pritomnosti specialistu od M$, kteri aplikovali slusnou
hromadku neverjnych patchu + nedokumentovana nastaveni jak systemu, tak db. Sam
si odpovezte, zda na tohle mate.

Jo, uz na zaver, widle se opravdu bozsky spravuji na dalku :-((( Vim o cem
mluvim, bohuzel jich mam par ve sprave :-(((((((((((((((((((((((((((((

> 
> 			Karel
> 
> PS. hmm.... proc ne databases na linux.cz?
> 
A kolik by tam bylo odpovedi?

-- 
S pozdravem

                      Karel Salavec

vedouci oddeleni operacnich systemu
provoz IT, provoz aplikaci CSG a HQ

Uz ani ty deprese nejsou co byvaly!