Dotaz: MSSQL - pro a PROTI

[cd9da]

Ahoj, nemám rád když se samá věc dělá 1000x, když se všechno podělá potom co se to dodělá a proto nemám rád produkty od Microsoftu. Nicméně asi budu nucený dělat pod MSSQL databází. Nenašel jsem nic konkrétního proti použití MSSQL. Prosím ty kteří s sql databázemi mají zkušenosti - napište co je na MSSQL špatné/strašné/lepší oproti třeba Oraclu, Postresql a třeba i Mysql.

Odpovědi

[okbob]

PRO - OLAP analýzy, datové pumpy, reporty PROTI - T-SQL, knihovní funkce, datové typy

[AraxoN]

V MSSQL je napríklad "zaujímavá" funkcia RAND(), ktorá pre celé query urobí len jedno náhodné číslo. Napríklad:

SELECT id, name, RAND() FROM user;

id   name       rand()
1    smurf      0.912315
2    admin      0.912315
3    retep      0.912315
4    killer     0.912315
5    motofoko   0.912315

Zjavne to nie je chyba, ale vlastnosť.

[jos]

nepíšeš o jakou verzi se jedná, kupříkladu 2000 by strčila do kapsy snad jedině MySQL, za ostatníma zaostává dost

naštěstí sme už přešli na 2005, která docela ujde, nicméně se nachystej na problémy typu: jo tak vy chcete používat fíčuru A? dobrá, ale jen když to nebudete kombinovat s fíčurou B

verzi 2008 neznam vůbec

a jak píše Pavel, T-SQL je hnus

[Michal Kubeček]

Pro mne je třeba dost zásadním argumentem proti fakt, že jakmile použijete MS SQL, uvážete si na nohu kouli v podobě Windows, protože to je jediná platforma, kde MS SQL běží.

[Šangala]

Pamatuji-li si dobře, tak triggry „FOR EACH ROW“ na MSSQL neuděláte.
Je to MS - takže je to jen pro MS produkty, a to ještě nejlépe vydané ve stejném období :).
Např. v PHP to není nijak super zařízené pro plnohodnotné použití.

[rADOn]

Plus ve srovnani s MySQL - triggery, ulozeny procedury a kurzory fungujou a daji se celkem pouzivat. Jinak je T-SQL jak jiz bylo receno hnus hnusatej.

[okbob]

No jeste aby ulozene procedury nefungovaly u ciste komercni databaze. Ale docela dlouho Microsoftu trvalo nez je rozbehal - jeste v 6.5 bez problemu srazily server do kolen a ani sedmickovy SQL nebyl kdovijak robustni. Problem je, ze T-SQL je neco jako assambler - je to vypocetne uplne, ale jinde je to lepsi - zasadni chyba je chybejici podpora poli, chybi bohatsi ridici konstrukce - kvalitni diagnostika - je na tom videt vek a chybejici vule neco vylepsovat.

[Šangala]

MySQL má triggery!
a pokud je třeba vykonávat je pro každý změněný/vloženy/smazaný řádek zvlášť (FOR EACH ROW), tak ve srovnání s MSSQL si troufnu tvrdit, že výkon je na straně MySQL, provést to na MSSQL je zase komplikovanější :).
Obráceně zas MySQL má triggery jen „FOR EACH ROW“, ale pro práci je daleko snazší (z mého pohledu) tento nedostatek obejít (pokud je to vůbec třeba).
Rovněž definice triggeru v MySQL/PostgreSQL BEFORE/AFTER může být zajímavější než MSSQL INSTEAD OF/AFTER.

[rADOn]

Dobre, MySQL ma triggery, ale pokud chci cokoliv slozitejsiho nez "ON DELETE CASCADE", konstrukce pro praci s nimi jsou hrozne. V MSSQL nebyl problem dopsat do triggeru relativne slozitou logiku, v MySQL je to prakticky nemozne. Totez plati pro kurzory, MySQL je teoreticky podporuje, ale prace s nimi je tak prijemna a efektivni ze si radsi napisu skript v pythonu nebo shellu.

[Šangala]

Protože jsou triggery v MYSQL prováděny „FOR EACH ROW“ tak se hodně použití kurzorů eliminuje (v triggerech), na rozdíl od MSSQL kde Vám nic jiného často nezbývá.
Nevím co znamená „složití logika“, ale zatím jsem neměl problém dát do triggeru v MySQL to co v MSSQL, možná proto že tam mám „jen jednoduchou logiku“ :). Spíše jsem narazil na opačný problém, že triggery za určitých okolností byly složité jak prase na MSSQL a na MySQL šli provést několikařádkově a to díky zmiňovanému provádění triggerů.
Obecně nemám rád MSSQL a raději použiji MySQL (když bych vybíral mezi těmito dvěma), takže je možné (je to jisté), že jsem zaujatý, nicméně mimo keců okolo přináším sdělení:
„MySQL má triggery, procedury a funkce a lze je používat“ :)

[AraxoN]

„MySQL má triggery, procedury a funkce a lze je používat“ :)

A komu by to naozaj nestačilo, môže siahnuť po PostgreSQL.

[jeleniste]

No, přechod z MySQL bude tvrdej, MSSQL je o něco přísnější na syntax, oproti benevolentnímu MySQL.

Pro: CTE, inteligentní SQL Management studio (de tam dát VIMemu), snadná administrace, nástroj pro export/import, pymssql, hierarchyid, snadné propojení s čimkoliv mikrosoftim (Visual studio ap.), ADO

Proti: Postgis je výrazně použitelnější než prostorový nástroje v MSSQL 08, navíc pro otevření zvenku čehokoliv prostorovýho je třeba kompilovat GDAL s ODBC a vůbec problém propojit se s čimkoliv nemikrosoftím jinak, než přes ODBC. osql je v porovnání psql téměř k ničemu. TSQL je uplně zoufale zastaralý, nejde ošetřit výjimky ve fcích, nejde v proceduře dát odkaz na neexistující sloupec, nebo neexistující tabulku v těle if, jde to obejít, ale je to votrava.

Shrnutí: Pracuje se s tím docela příjemně, pokud člověk nutně nepotřebuje něco nemikrosoftího pak nastupuje ODBC. Některý finty z postgre nejdou použít (a vice versa).

Je.

[jeleniste]

Ještě jsem zapoměl, že MSSQL umí na rozdíl od Postgre (kde to řeší db link) dotazy napříč databází :select * from databaze.schema.tabulka a taky USE database, navíc v management studiu se daj přilinkovat servery. Information schema vypadá v MSSQL i PG podobně, což je příjemný. Pokud člověk se bude snažit psát v TSQL tak, jak by psal v Pl/SQL, tak bude pochopitelně nasranej, to je jak drbat se nohou za uchem. Je zkrátka třeba přijmout jinej styl práce..

Zdůtazňuju, že mluvim o SQL a operátorský práci, rozdíly v administraci, nárocích, bezpečnosti nejsem schopnej posoudit

[iq]

A co treba cena? Prijde mne ze je nejdrazsi Pravda zalezi na dane licenci a hw k ni souvisejici.