Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: anoper 28. 09. 2010, 12:56:37

Název: Rozdíl mezi SQL a MySQL
Přispěvatel: anoper 28. 09. 2010, 12:56:37
Jedhnoducha, mozno prihlupla otazka. V skole mame robit v SQL, cez nejaky oracle server... Ja by som to vsak radsej pisal v apache + mysql. Bude to fungovat ako ma ?
diky :)
Název: Re: Rozdiel SQL & MySQL
Přispěvatel: Vladimír Drgoňa 28. 09. 2010, 13:20:31
SQL je štandard. MySql ho väčšinou využíva, rovnako ako Oracle. Tá časť bude fungovať aj na Oracle. Kľudne si napíš všetko na MySql, nepoužívaj '`' pre označenie stĺpcov, možno radšej použi engine=InnoDB, aby si mal možnosť foreign kľúčov a transakcií.
Prepísať výsledný kód pre Oracle nebude ťažké. Asi sa budú inak volať dátové typy (CHAR, VARCHAR, VARTEXT) a pod, myslím, že tam nebude fungovať napríklad "show databases;" a podobné špecifické príkazy pre MySql, ale zvyšok by mal byť veľmi podobný.
Název: Re: Rozdiel SQL & MySQL
Přispěvatel: PCnity 28. 09. 2010, 16:50:40
Presne.

Akurat ja by som pouzil asi radsej pg_sql nakolko mi pride architekturalne podobnejsie Oradb.
Název: Re: Rozdiel SQL & MySQL
Přispěvatel: Vladimír Drgoňa 28. 09. 2010, 18:46:14
Postgres je naozaj bližšie k Oracle, ale aj k štandardom. Tiež ju používam doma na serveri, ale na hostingu je to problém - nikde na Slovensku ju pokiaľ viem nemajú a inde je to asi podobné.
Název: Re: Rozdiel SQL & MySQL
Přispěvatel: Logik 28. 09. 2010, 21:27:37
Rozhodně postgresql, mysql je se standardama na štíru.

Hostingy se daj najít, přinejmenším v ČR, s čimž byste nemali mať problém. :-)
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Pajk 29. 09. 2010, 09:30:59
Dovolím si malou poznámku z praxe - to vlastní SQL (tj. struktura databáze, dotazy, které z ní budou tahat data ...) nejspíš pro školní projekt půjde udělat univerzálně a bude celkem jedno, jaký konkrétní SQL server je použit (pokud nevyužijete nějaké pokročilé věci jako triggery, uložené procedury, ale skutečně jen tabulky a nějakou tu referenční integritu - cizí klíče). Ale pokud půjde o nějakou aplikaci s uživatelským rozhraním ve stylu tabulky/formuláře/web (ne jen sql konzolové dotazy), tak záleží hodně na tom, v čem (jaký framework, balík knihoven, prostředí) tu vlastní aplikaci vytvoříte - tam můžete být školou "dotlačen" do nějaké Oracle suite pro rychlý vývoj aplikací a pak vlastní aplikace přenositelná na jiné prostředí (mysql,pg sql,php nebo jiný jazyk pro vlastní programování) nebude ... Samozřejmě pokud to budete programovat od základů v PHP, Pythonu či Javě apod., přenos na jiný druh sql db by měl být možný změnou volaného db api v kódu (pracné) nebo v konfiguraci, ale od začátku to musíte tvořit tak, aby to používalo nějakou db abstrakci (ala odbc ve světě windows, SQLObjects pro Python apod.).
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Logik 29. 09. 2010, 11:48:52
Přenositelné? Už např. takovej autoincrement/serial se dle databáze liší - a to je naprosto základní věc. Stejně tak interní fce, který např. může chtít použít v check constraint nebo velmi často užívanej fulltext.

Nehledě na to, že taková věc jako trigger imho není pokročilá věc, ale pro spoustu věcí v podstatě nutnost.

Souhlasim s tím, že je dobré použít nějakou db knihovnu ale zásadně nesouhlasím s tím, že by se měli psát aplikace přenositelně. Samozřejmě že se má co to jde dodržet SQL standard a nepoužívat zbytečně proprietální syntax, ale nevyužívat zbytečně možnosti databáze je blbina....  To se pak rovnou může použít rychlejší key-value nosql databáze...
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: anoper 29. 09. 2010, 17:53:53
Tak nakoniec som nainstaloval ten oracle server, pretoze mi v skole zatrhli pouzivat prostage, sqlite, mysql , etc. Asi to je nakoniec aj lepsie, pretoze zaverecnu aplikaciu odovzdavam na skolsky server - najjednoduhsie riesenie.... Ale kazdopadne som zistil par novych veci, vdaka za rady !  ;)
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: dustin 29. 09. 2010, 19:08:05
To je dost smutný přístup školy. Místo aby vychovali někoho, kdo bude zaměstnavateli schopen řešit úkoly bez dodatečných nákladů, cíleně budují znalosti jedné konkrétní proprietární technologie. Stejné jako když přijde webový grafik a trvá na tom, že musí na webovou grafiku používat photoshop za 30k, místo aby uměl gimp.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Petr 29. 09. 2010, 20:57:29
To je dost smutný přístup školy. Místo aby vychovali někoho, kdo bude zaměstnavateli schopen řešit úkoly bez dodatečných nákladů, cíleně budují znalosti jedné konkrétní proprietární technologie. Stejné jako když přijde webový grafik a trvá na tom, že musí na webovou grafiku používat photoshop za 30k, místo aby uměl gimp.

Profesionál pracuje s nejlepším nástrojem na trhu, protože cena jeho práce velmi převyšuje cenu jakéhokoliv hw nebo sw. To je vidět, jak si vážíte práce svých podřízených (zaměstnanců). Ani Gimp, ani MySql nejsou technologie schopné obstát ve skutečně profesionálním prostředí. Stačí snad na nějaký ten blogísek.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Logik 29. 09. 2010, 21:16:27
Mysql možná ne. Ale postgresql (pokud není potřeba replikace, jak je to ve verzi 9.0 popř. postgresql cluster) nabízí v podstatě skoro stejný možnosti jako Oracle.
Navíc - webhosting s postgresql je všude, na oracle potřebuješ VPS.

Prostě je tu oracle a je tu postgresql, oba maj jiný náklady a jiný přednosti. Preferovat pouze oracle je postoj vhodnej tak do státní správy.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Justas 30. 09. 2010, 06:09:50
Nesouhlasím. I v reálném světě mnoho firem už používá nějaké prostředí, třeba ten Oracle. A potom přijít s tím, že na tenhle konkrétní projekt bude lepší koupit např. MS SQL je pěkná blbost - první manager vás s tím vyrazí, že generujete zbytečné náklady.

Něco jiného je situace, kdy se "na zelené louce" buduje fiemní IT infrastruktura. Tam je na místě zvažovat, do jakého prostředí se dát, a tady je místo pro volbu mezi vhodnými produkty. V prípadě, že potřebujete měnit už nasazené produkty, je potřeba zdůvodnit, proč přinese lepší výsledky pořízení jiného systému než nasazení aplikace pod již existujícím.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: FredFlinstone 30. 09. 2010, 09:05:38
To je dost smutný přístup školy. Místo aby vychovali někoho, kdo bude zaměstnavateli schopen řešit úkoly bez dodatečných nákladů, cíleně budují znalosti jedné konkrétní proprietární technologie. Stejné jako když přijde webový grafik a trvá na tom, že musí na webovou grafiku používat photoshop za 30k, místo aby uměl gimp.

Profesionál pracuje s nejlepším nástrojem na trhu, protože cena jeho práce velmi převyšuje cenu jakéhokoliv hw nebo sw. To je vidět, jak si vážíte práce svých podřízených (zaměstnanců). Ani Gimp, ani MySql nejsou technologie schopné obstát ve skutečně profesionálním prostředí. Stačí snad na nějaký ten blogísek.
pán kolega, udivilo ma Vaše tvrdenie, že ani Gimp ani MySQL nie je schopné obstáť v profesionálnom prostredí. K MySQL aspoň toľko:
http://downloadingbirds.blogspot.com/2010/06/facebook-bezi-stale-na-php-mysql.html (http://downloadingbirds.blogspot.com/2010/06/facebook-bezi-stale-na-php-mysql.html)
a Gimp je veľmi, veľmi podobný Photoshop-u. Fakt neobstojí?
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: karlos 30. 09. 2010, 10:03:55
grafika dela grafikem jeho hlava a ne jeho SW. stejne tak mysql muze najit uplatneni i v profi sfere - na web je (z ruznych duvodu) stale skvelym nastrojem!

Pokud skola mermomocí protlacuje jeden jediny komercni produkt pak je tam neco spatne! Zadani by melo byt ve skole v predmetu od databazich ve smyslu: pouzijte SQL, zduvodnete pouziti nekterych dotazu, pouzijte v aplikaci alespon 1x view a 1x trigger, aby bylo videt ze vite ktera bije. a jestli to napisete v cecku a mssql nebo php a mysql je nepodstatne - podstatne je jestli chapete podstatu SQL.

Aspon takhle to bylo cca 5 let zpatky na FME VUTBR na informatice a automatizaci.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: anoper 09. 10. 2010, 23:02:42
Tak neviem, neviem :) stále nás v škole, už asi od strednej vedú smerom nefixovať sa na soft, ale pochopiť princíp a ako funguje technológia, ktoru ak treba aplikovať na software s ktorýḿ budem pracovať... No viem si predstaviť, že po 20rokoch práce s konkrétnym programom sa mi nebude chcieť migrovať na niečo iné... Teraz ešte plánujem byť aspoň 10 rokov dosť mladý nato  aby som sa naučil čokoľvek :)) ( čo bude mať zmysel )
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: FredFlinstone 25. 11. 2010, 17:08:57
ak je manažment firmy taký, že sa do toho nerozumie (napriek tomu, že sa, ako každý manažment tvári, že sa do toho rozumie), a keď IT-čkár povie, že sa to dá urobiť iba s MS SQL servrom (aj to len preto, že ho to takto naučili na škole) a manažment mu na to skočí a MS SQL mu bez najmenšieho rozmyslu kúpi, tak načo by sme si mali lámať hlavu? Nabudúce povieme, že potrebujeme Photoshop (za 1000€), potrebujeme na vývoj tiež MS VisualStudio (najlepšie team verziu) atď, atď.
Na čo by sme rozmýšali, na čo by sme chceli ušetriť. Veď manažment firmy aj pri prípadnom ušetrení nám tie peniaze nedá. Tak sa to kúpi a basta. Nám to treba, inak sa to nedá ...
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: mishino 25. 11. 2010, 22:43:16
Toto je trosku nepresny nazor. Uvediem priklad na PostgreSQL vs. Oracle z pohladu zakaznika. Objednal som si urcity softver, ktory ma bude stat kopec penazi, tento softver bude moj biznis podporovat alebo ho priamo tvorit. Na tomto softveri funguje mojich 200 zamestnancov. Samozrejme zaplatil som si aj normalnu podporu, aby som mal istotu, ze softver jedneho dna neprestane fungovat, pretoze ak by prestal mohol by som svojich 200 zamestnancov poslat na tyzden na dovolenku. Bolo mi vsak luto vyhodit 30 000 eur na oracle databazu, tak sme to navrhli nad postgresql. Po pol roku moj uzasny softver prestane fungovat na chybe v db, ktora sa neprejavila testovanim a je to chyba priamo v DB. Co teraz? Poslat zamestnancov na mesiac na dovolenku a prerobit to na inu databazau? Alebo som si mal rovno kupit oracle so slusnym supportom, ktory mi moj problem pomoze vyriesit? Kto mi pomoze vyriesit moj problem s postgresql? Postnem bug do postgreql bugzilly a budem cakat? :)
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 26. 11. 2010, 00:15:32
Viacero nazorov je tu velmi zavadzajucich a vas taktiez. PostgreSQL ma enterprise podporu napr. http://www.enterprisedb.com/. Taktiez existuju firmy, ktore spravuju databazy (aj na dialku) a niektore z nich vedia v pripade problemov vyvorit aj patch. Vsetko je otazka penazi, ktore ste ochotny do toho vlozit, resp. nakolko funkcnost vasej DB alebo aplikacie nad nou ovplyvnuje chod vasej firmy. A ak chod vasej firmy je zavisly na funkcnosti DB, tak si nenainstalujete "komunitnu" verziu PostgreSQL, ale "enterprise" a zakupite si na to support.

Taktiez to neznamena, ze ked mate DB od najvacsich hracov na trhu, ze automaticky mate vyhrate.
Z vlastnej skusenosti Vam mozem povedat, ze viac krat som nasiel skorej workaround alebo problem ako samotny vendor DB (nie, chyba nebola medzi stolickou a klavesnicou) a to by ste mozno neverili co vsetko, dokaze urobit support takehoto velkeho vendora, len aby ziskal cas na opravu.

Zaroven nemozem suhlasit aj s nazormi (tentoraz nie vasimi) na temu MySQL. MySQL je hodne dobra DB a v niektorych firmach sa pouziva na naozaj velmi velke veci a DB su naozaj velmi velke (velke = hovorime o Tera Byteoch).

Taktiez tu odznela tema standardy. Dovolim si pripomenut, ze napr. Oracle do verzie 9i tie tiez nesiel podla standardov (napr. JOIN syntax). MSSQL ma tiez "select TOP N", co tiez nie je moc podla ANSI SQL. Su to specifika konretnej DB a tieto specifika ma takmer kazda databaza. A ti co tu spominaju standardy aspon by mohli uviest, ktory presne standard (verziu) maju na mysli...

Zanela tu aj pripomienka na velku podobnost PostgreSQL s Oracle. Kto pozna obe DB trosku viacej do hlbky, tak vam toto vyvrati. Napriklad table partitioning. Ten co je v MySQL sa teda viac podoba tomu v Oracle ako to co prislo v prvych verziach PostgreSQL.

Zaverom dodam, ze kazda DB ma svoje pre a proti, ale kazda z vyssie menovanych sa hodi pre business a ma aj komercnu podporu.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: dustin 26. 11. 2010, 08:58:47
Toto je trosku nepresny nazor. Uvediem priklad na PostgreSQL vs. Oracle z pohladu zakaznika. Objednal som si urcity softver, ktory ma bude stat kopec penazi, tento softver bude moj biznis podporovat alebo ho priamo tvorit. Na tomto softveri funguje mojich 200 zamestnancov. Samozrejme zaplatil som si aj normalnu podporu, aby som mal istotu, ze softver jedneho dna neprestane fungovat, pretoze ak by prestal mohol by som svojich 200 zamestnancov poslat na tyzden na dovolenku. Bolo mi vsak luto vyhodit 30 000 eur na oracle databazu, tak sme to navrhli nad postgresql. Po pol roku moj uzasny softver prestane fungovat na chybe v db, ktora sa neprejavila testovanim a je to chyba priamo v DB. Co teraz? Poslat zamestnancov na mesiac na dovolenku a prerobit to na inu databazau? Alebo som si mal rovno kupit oracle so slusnym supportom, ktory mi moj problem pomoze vyriesit? Kto mi pomoze vyriesit moj problem s postgresql? Postnem bug do postgreql bugzilly a budem cakat? :)

Máš nějaký konkrétní příklad, opravdu se to stalo? I kdyby to byl skutečný případ, velice pravděpodobně by to šlo vyřešit úpravou aplikaci. A pokud od ní nejsou zdrojáky nebo se k ní dodavatel již nehlásí, pak je to chyba objednatele, že na takový lock-in kývnul a ještě za něj zaplatil.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: mishino 26. 11. 2010, 12:46:52
To bol cisto vymysleny priklad. Chcel som tym len naznacit, ze uvazovanie manazerov moze byt uplne ine ako len hlupe schvalovanie toho co IT oddelenie navrhne ako jedno jedine super riesenie, ci uz to riesenie je zobrat zadarmo postgresql, alebo kupit enterprisedb, oracle... Vzdy to treba namodelovat na aktualnu situaciu a vymysliet si pre porovanie alternativne riesnie. Uloha IT oddelenia v neIT firmach je podpora pre spavne fungovanie biznisu a IT manazer si to musi uvedomit a podla toho konat. Nejde o to firme minut peniaze za super drahe riesenie, alebo setrit na super lacnom. Treba najist urcitu strednu cestu zodpovedajucu poziadavkam a velkosti spolocnosti. Nechat si nakodit od studenta aplikaciu a kupit k tomu drahu databazu nie je spravne riesenie, rovnako ako si najat etablovanu spolocnost na naprogramovanie (relativne drahej) aplikacie a setrit na databazovom rieseni. A pri tomto pohlade je jedno o akom DB rieseni sa bavime. Kazde bude vhodne na nieco trosku ine.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: df 26. 11. 2010, 16:48:19
To bol cisto vymysleny priklad. Chcel som tym len naznacit, ze uvazovanie manazerov moze byt uplne ine ako len hlupe schvalovanie toho co IT oddelenie navrhne ako jedno jedine super riesenie, ci uz to riesenie je zobrat zadarmo postgresql, alebo kupit enterprisedb, oracle... Vzdy to treba namodelovat na aktualnu situaciu a vymysliet si pre porovanie alternativne riesnie. Uloha IT oddelenia v neIT firmach je podpora pre spavne fungovanie biznisu a IT manazer si to musi uvedomit a podla toho konat. Nejde o to firme minut peniaze za super drahe riesenie, alebo setrit na super lacnom. Treba najist urcitu strednu cestu zodpovedajucu poziadavkam a velkosti spolocnosti. Nechat si nakodit od studenta aplikaciu a kupit k tomu drahu databazu nie je spravne riesenie, rovnako ako si najat etablovanu spolocnost na naprogramovanie (relativne drahej) aplikacie a setrit na databazovom rieseni. A pri tomto pohlade je jedno o akom DB rieseni sa bavime. Kazde bude vhodne na nieco trosku ine.

No ty si aky kaskader? Taky kyd som snad videl iba na volebnych billboardoch. Vidim, ze z teba hovoria same skusenosti - nechces este vysvetlit podstatu sveta nam jednoduchym, pan manazer?
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Lenin POWER! 26. 11. 2010, 17:36:43
No ty si aky kaskader? Taky kyd som snad videl iba na volebnych billboardoch. Vidim, ze z teba hovoria same skusenosti - nechces este vysvetlit podstatu sveta nam jednoduchym, pan manazer?
Vzdyt ma pravdu, jen blazen by riskoval s PGSQL kde dela komercni support snad jen jedna firma - EDB. Kdyz si koupi cokoliv jineho tak se tim jeho sance na poskytnuti podpory pri pripadnych problemech zvysi. Na pohadky o genialnich inhouse administratorech snad uz dospeli lide neveri. Rika se tomu management rizik.
Reseni ktere je zadarmo, jeste nemusi byt nejlevnejsi. Downtime je zatracene draha zalezitost.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Pavel Stěhule 26. 11. 2010, 20:52:19
Toto je trosku nepresny nazor. Uvediem priklad na PostgreSQL vs. Oracle z pohladu zakaznika. Objednal som si urcity softver, ktory ma bude stat kopec penazi, tento softver bude moj biznis podporovat alebo ho priamo tvorit. Na tomto softveri funguje mojich 200 zamestnancov. Samozrejme zaplatil som si aj normalnu podporu, aby som mal istotu, ze softver jedneho dna neprestane fungovat, pretoze ak by prestal mohol by som svojich 200 zamestnancov poslat na tyzden na dovolenku. Bolo mi vsak luto vyhodit 30 000 eur na oracle databazu, tak sme to navrhli nad postgresql. Po pol roku moj uzasny softver prestane fungovat na chybe v db, ktora sa neprejavila testovanim a je to chyba priamo v DB. Co teraz? Poslat zamestnancov na mesiac na dovolenku a prerobit to na inu databazau? Alebo som si mal rovno kupit oracle so slusnym supportom, ktory mi moj problem pomoze vyriesit? Kto mi pomoze vyriesit moj problem s postgresql? Postnem bug do postgreql bugzilly a budem cakat? :)
Řekněte mi, kolik by stála podpora Oraclu, která Vám do 48 pošle kompletní fix? Předevčírem jeden z uživatelů nahlásil chybu v PostgreSQL - memory leak v modulu xml2 - viz http://groups.google.com/group/postgresql-cz/browse_thread/thread/f5bcae59dbb2f1f3?hl=cs , během dopoledne jsem udělal rychlý fix, a nyní je k dispozici finální oprava - http://archives.postgresql.org/pgsql-hackers/2010-11/msg01798.php
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Mirek Prýmek 26. 11. 2010, 21:23:59
Postnem bug do postgreql bugzilly a budem cakat? :)

A u Oraclu to bude jak?

Zavolam na support, mile si popovidam s milou slecnou, ktera mile vyplni ticket a mile mi popreje prijemny den...

...a budu cekat :)

----
S Oraclackym supportem zkusenost nemam, delam si srandu... jen chci rict, ze myslet si, ze placeny support je *vzdy* a *za kazdych okolnosti* lepsi nez komunitni ci inhouse, je stejne blahove jako myslet si, ze oss je *vzdy* a *za kazdych okolnosti* levnejsi.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Ivan 26. 11. 2010, 22:17:28
Oracle ma nejhorsi support. Jestli nejsi top100 enterprise customer, tak se s tebou nikdo nebude ani bavit.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Ivan 26. 11. 2010, 22:33:23
Koukam, ze diskuze se dostala nekam do pryc - kde si kluci honi ego vychvalovanim te sve dabataze a odbihanim od temau.
Takze odpoved na puvodni otazku: Otazka znela: "Jaky je rozdil mezi SQL a MySQL?"
Odpoved zni: Rozdil je stejny jako mezi traktorem a benzinem. SQL je jazyk a MySQL je databazovy server. Casto se najdou lidi kteri za SQL pokladaji MS SQL Server, ale to se tak vyjadruji zejmena IT analfabeti, kteri se hraji na Microsoft Certified Partnery - amateri, vyhodit.
Mezi nejpouzivanejsi databaze patri (v abecednim poradi): DB/2, Firebird, Interbase, MS SQL Server, MySQL, Oracle, Postgree, Sybase (coz je MS SQL). Ze vsech vyjmenovanych ma nejblize k dodrzovani standardu SQL zrovna Firebird. Cim drazsi DB (MS SQL, Oracle ....) tim dal od standardu!!! Jestli tady nejaky Oraclista tvrdi, ze je to jinak, je to amater - vyhodit na hodinu, jelikoz nezna prinejmensim 2/3 funkci Oraclu. Nejlepsi DB na web aplikace vzhledem k pomeru cena/vykon je MySQL. Nejlepsi databaze pro supervelke firmy (T-Mobile, DHL a pod.) je Teradata (brutalni vykon). Nejlepsi databaze pro vse ostatni je Firebird. Ano! S Firebirdem udelate vsechny typy apliakci, od embeded po enterprise a za 0 EUR. Vsechny ostatni databaze se jen motaji nekde mezi temahle.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: mishino 27. 11. 2010, 00:57:31
No ty si aky kaskader? Taky kyd som snad videl iba na volebnych billboardoch. Vidim, ze z teba hovoria same skusenosti - nechces este vysvetlit podstatu sveta nam jednoduchym, pan manazer?

Ziadny pan manazer, na to som este nedozrel  ;) Len som sa zamyslel nad tym ako sa moze zamyslat osoba na pozicii rozhodujuca o takomto projete.

Nejlepsi DB na web aplikace vzhledem k pomeru cena/vykon je MySQL. Nejlepsi databaze pro supervelke firmy (T-Mobile, DHL a pod.) je Teradata (brutalni vykon). Nejlepsi databaze pro vse ostatni je Firebird.

Toto sa presne takto neda a nemoze skatulkovat. Pretoze.. Co je to web aplikacia? :-) Ale to uz patri asi vazne do inej diskusie..  8)
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 28. 11. 2010, 01:50:50
Nejlepsi databaze pro supervelke firmy (T-Mobile, DHL a pod.) je Teradata (brutalni vykon).

No teba by mali tiez vyhodit, za niekolko vyrokov, ale hlavne za tento!
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Ivan 29. 11. 2010, 09:04:01
Nejlepsi databaze pro supervelke firmy (T-Mobile, DHL a pod.) je Teradata (brutalni vykon).

No teba by mali tiez vyhodit, za niekolko vyrokov, ale hlavne za tento!

Souhlasim s tim, ze ma odpoved je hodne zjednodusena, ale predpokladam, ze jako odpoved na dotaz zacatecnika postacuje. Kdyz nekdo chce detailnejsi zduvodneni co kam kdy kterou DB pouzit, tak si vypracuje SWOT analyzu.

Nicmene by me zajimalo, proc s tim nesouhlasis.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: libra 29. 11. 2010, 09:56:21
Z vlastnej skusenosti:
napr. na TUKE funguje predmet SQL-Oracle, ktora je spolocnym predmetom T-systems a TUKE, vychadza z potrieb T-sys, aby sa vyprodukovali ludia znali prave tohoto DBS. Je niekolko odlisnosti voci osatnym SQL systemom, treba sa s tym zmierit a ucit sa. Ked je to raz predmet zamerany na Oracle, tak je zbytocne vymyslat nieco ine.
Okrem toho, zo stranky Oracle,com je mozne oproti bezplatnej registracii stiahnut plna verzia DBS, takze ani vyhovorky typu zadarmo/za peniaze nie su na mieste.
Vsetky spominane SQL systemy maju niekolko odlisnosti, ale maju jednu vec spolocnu: SQL. Treba sa naucit tento jazyk, ostatne veci sa daju pre kazdu databazu prisposobit (ine datove typy, neexistujuci autoincrement, neexistujuce vnorene dotazy, ... ).

Na TUKE som sa stretol vramci vyucby s MySQL, Informix, Oracle, PostgreSQL, Java DB a kazdy novy system znamenal nejaku zmenu v zauzivanych zvyklostiach. Naucil som sa co najviac vyuzivat standardne riesenia, pricom viac-menej poznam zakladne crty a odlisnosti jednotlivych DBS a imho, tak to ma byt. Samozrejme, obcas sa vyskytne situacia, ked je vyhodnejsie pouzit nejaku specialnu vlastnost danej databazy, ale vacsina veci sa da riesit univerzalne.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: mishino 29. 11. 2010, 12:28:02
Souhlasim s tim, ze ma odpoved je hodne zjednodusena, ale predpokladam, ze jako odpoved na dotaz zacatecnika postacuje.

Toto je ale uplna blbost. Prave koli takymto odpovediam potom vznikaju pseudo odbornici, ktori to vycitali niekde v diskusii ako jedno jedine super riesenie. Takato odpoved akurat zaciatocnika zmatie a prinajhorsom to zacne chudak dalej rozsirovat. Co uz len co za hovadinu takto skatulkovat databazy.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 29. 11. 2010, 16:06:12
Nicmene by me zajimalo, proc s tim nesouhlasis.

Nesuhlasim s tym z viacerych dovodov, ale ten najhlavnejsi, je ta veta znela prilis generalizovane. A tu je problem. TD vzhladom na to ako funguje je urcena primarne pre DSS.
Dalsia vec je, ze tvoj general statement vyznel ako keby Oracle a MSSQL su nevyhovujuce, pricom prave tieto dva spomenute maju najvacsi trhovy podiel v tejto oblasti.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 29. 11. 2010, 16:36:41
Mierne ta poopravim.

Okrem toho, zo stranky Oracle,com je mozne oproti bezplatnej registracii stiahnut plna verzia DBS, takze ani vyhovorky typu zadarmo/za peniaze nie su na mieste.

1. Pre tieto ucely bola spravena edicia XE, cize Oracle XE, takze nie je dovod tahat plnu DB, lebo az na par limitacii (ktore s prepacenim vysokoskolsky student potrebovat nebude) je v plnej verzii. Cize na tento ucel ako stvorene. Mimochodom taketo iste ponuka aj MS.
2. Ano, stiahnut to mozes zdarma, ale podla licencnych podmienok, to mozes pouzivat bez zaplatenia licencie iba 30 dni, to si zabudol povedat.
3. Ak sa nemylim tak este stale mas skola vlastny repozitar, z ktoreho je mozne potrebny SW stiahnut (nakolko skola ma tieto veci licencovane pre vyuku) aspon.

Naucil som sa co najviac vyuzivat standardne riesenia, pricom viac-menej poznam zakladne crty a odlisnosti jednotlivych DBS a imho, tak to ma byt. Samozrejme, obcas sa vyskytne situacia, ked je vyhodnejsie pouzit nejaku specialnu vlastnost danej databazy, ale vacsina veci sa da riesit univerzalne.

Na jednej strane chvalim tvoj postoj ohladne standardnych rieseni a na druhej strane nesuhlasim. Co je dolezite, ze si nespomenul co je podla teba standardne riesenie.
Nevadi, nacrtol si najvacsi problem dnesnych aplikacii a preco ludia, ktori su zodpovedni za spravu DB nadavaju na aplikacie a hlavne ludi, co ich pisali.
Pretoze ta univerzalnost je prave problem. Kazda DB ponuka nejaku vlastnost, ktora vyuzije potencial (povedzme signifikantne urychli vykonanie dotazu) DB. Ale developer ju nepouzije. Preco?
a) lebo o nej nevie - dost casty jav
b) lebo taka vlastnost nie je povedzme na Sybase alebo Firebird (priklad), pre ktoru ma aplikacia tiez fungovat

Takze miesto toho aby som vyuzil vsetok potencial z mojho Mercedesu E, za ktory som zaplatil velke prachy pri nakupe a platim velke prachy za support, tak mam klasicky ludovy Peugeot 307. Naopak toto je najrozsirenejsi a hodne zauzivany omyl. Prave naopak, je velmi dolezite pisat pre konkretnu DB, vyuzit vsetky jej prednosti (pre ktore bola vybrata a pre ktore je platena). Ak chces pisat naozaj univerzalne, tak prosim, ale v tom pripade pouzivaj prislusne query v zavislosti od pouzivanej DB, cize inymi slovami od konfiguracie bude zavisiet sada query, ktore sa budu nad DB spustat. Ze to je prilis zdlhave? Ano je, ale ovela lahsie Ti to umoznuje prave specificke zmeny pre konkretnu DB bez toho, aby si nejakym sposobom ovplyvnoval iny typ DB alebo este horsie zavadzal nejaku nechutnu barlu (rozumej workaround) do aplikacie. A zaroven nepouzivas viazaci drat, tam kde su potrebne hmozdinky a skrutky.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 29. 11. 2010, 16:50:00
Mysql možná ne. Ale postgresql (pokud není potřeba replikace, jak je to ve verzi 9.0 popř. postgresql cluster) nabízí v podstatě skoro stejný možnosti jako Oracle.
Navíc - webhosting s postgresql je všude, na oracle potřebuješ VPS.

Prostě je tu oracle a je tu postgresql, oba maj jiný náklady a jiný přednosti. Preferovat pouze oracle je postoj vhodnej tak do státní správy.

Zaujimavy pohlad, ale skusim to takto. (Cisto hypoteticky)  Povedzme, ze dostanete ulohu vybrat DB, kde hlavnym kriteriom vyberu vo vyberovej matici by bola "maximalna eliminacia moznosti straty dat" a az potom vsetko ostatne vratane ceny. Ktoru DB by ste preferovali? Ja Oracle, co vy?
Název: trzni podil RDBMS
Přispěvatel: Lenin POWER! 29. 11. 2010, 18:28:52
Dalsia vec je, ze tvoj general statement vyznel ako keby Oracle a MSSQL su nevyhovujuce, pricom prave tieto dva spomenute maju najvacsi trhovy podiel v tejto oblasti.
Trojka Oracle, DB2 a MSSQL zabira dohromady 85% trhu. Na ostatni databaze toho moc nezbyde. Navic Oracle ma asi dvojnasobny naskok oproti DB2 ktera je druha.
Skoda jen je, ze z techto srovnani je vynechan IMS (aka DB1) neb neni RDBMS. Ten ve sve kategorii po 40 let vpodstate nema konkurenci kdyz nepocitame TPF. IMS neni vubec levny software, vyrazne drazsi nez Oracle/DB2, dival jsem se do ShopZ a projistotu tam nemaji IMS cenu ani uvedenou.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Ivan 29. 11. 2010, 19:04:49
Dalsia vec je, ze tvoj general statement vyznel ako keby Oracle a MSSQL su nevyhovujuce, pricom prave tieto dva spomenute maju najvacsi trhovy podiel v tejto oblasti.

1. Trzni podil nevypovida o kvalite/vhodnosti produktu, ale o tom, jak byl zvladnut marketing jeho vyrobce. To nam uz snad historie nekolik krat dokazala a porad dokazuje.

2. muj "general statement", jak jsi to nazval, nemuzes vytrhnout z kontextu! Ja jsem pred jeho vyhlasenim psal o tom, ze kazda DB je vhodna na neco jineho a je potreba udelat SWOT analyzu pro spravny vyber dle parametru, ktere nas zajimaji. Ale zacatenik ji delat jiste nebude a je nesmysl aby zacal na Oraclu.

3. Taky urcit market share DB neni zadna legrace a temer nikdo nevi jak se dobrat k rozumnym cislum. Napriklad:
http://www.mysql.com/why-mysql/marketshare/
http://www.informationweek.com/news/software/database_apps/showArticle.jhtml?articleID=207402230
http://www.gartner.com/it/page.jsp?id=507466
Ovsem docela zajimave jsou vysledky vyhledavani dle klicovych slov DB serveru.
http://www.citrustechnology.com/blog/database-market-share
Docela me prekvapilo, ze nevede Oracle, vzhledem k poctu pruseru, ktere se s tym serverem musi resit. ;-)
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Lenin POWER! 29. 11. 2010, 19:38:23
Povedzme, ze dostanete ulohu vybrat DB, kde hlavnym kriteriom vyberu vo vyberovej matici by bola "maximalna eliminacia moznosti straty dat" a az potom vsetko ostatne vratane ceny. Ktoru DB by ste preferovali? Ja Oracle, co vy?
DB2 pro zOS. Ta se da provozovat s nulovym downtimem klidne po deset let, umi i major upgrady i vymenu HW bez zastaveni DB, Oracle neumi ani vsechny minor. Neni ani tak draha (asi jen 4x drazsi nez Oracle) a ten mainframe HW taky neni nijak vyjimecne drahy i kdyz pravda oni si to vynahradi na doplnkach. $6k za 1GB RAM. Rozhodne je to idealni prostredi pro 24x7 provoz.
Oracle neni nic moc, toho rozhodi i to ze disk ma write cache zapnutou a keca o tom ze zapsal data na disk do logu. Zapnout write cache u disku a mackat reset, po restartu project db na zmrsene bloky. I kdyz tohle rozhodi vetsinu databazi pokud nejsou specialne napsane tak aby se s timhle pripadem umely vyporadat (vsechen DB soft od IBM a MQ series to umi. IMS taky, TPF nevim.) Pravda porad je Oracle lepsi nez PGSQL, kde se nedopracovali jeste ani k checksumum u stranek, pokud jsem neco neprehlednul u devitky.
Pokud bych se rozhodoval co nacpat zakaznikovi tak to bude mainframova DB2, pripadne Oracle na Sun SPARC Enterprise M9000. DB2 na POWER7 bych mu necpal protoze na tom Oraclu se vyrazne vic vydela za licence a HW. Navic ma Oracle vyrazne obtiznejsi administraci nez Unixova DB2 a proto vydelate i na skolenich, instalaci, supportu a podobne.
Ja unixovej oracle nemam moc rad (nevim zda jeste delaji ten mainframovej) sam bych ho pro inhouse aplikaci nepouzil, porad se v nem neco sere. Potrebuju aby to jelo a mohli jsme delat a vydelavat. To snad uz i ten informix je lepsi protoze se do nej nemusi neustale vrtat.
Naprotitomu unixovou DB2 lidi provozuji pod SAPem bez toho aniz by meli vyhrazeneho db administratora, jen si nechaji delat upgrady od servisnich firem. To by si nikdo s Oraclem nedovolil, tam se porad resi problemy typu dohaje proc to zase jede tak pomalu, to zase jsou statistiky v hajzlu nebo co?
Koncim flamewar, jdu vydelavat USD.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 29. 11. 2010, 23:06:28
Nehnevajte sa ale takmer cokolvek co bezi na mainframe dokaze mat takmer nulovy downtime, pretoze to je uloha mainframeu. Ale zabudli ste na jednu podstatnu vec, napr. na ludsky faktor, chyba v aplikacii, tieto veci vam mozu sposobit stratu dat a tu vam mainframe vobec nepomoze.

"Oracle neni nic moc, toho rozhodi i to ze disk ma write cache zapnutou a keca o tom ze zapsal data na disk do logu."

Opravim vas, prv nez Oracle zapise do datafileu, tak pred tym zapise do logu (konkretne do online redo logu) je to prave kvoli tomu, ze ak by doslo k vypadku, urobi takzvane Instance (alebo crash) recovery, kde v ramci rollforward fazy aplikuje vsetky zmeny a potom vramci rollback fazy tie necommitnute odroluje (to uz pri otvorenej DB). Vidite, ziadna strata. Ak mate zmrsene bloky a teda je potrebne media recovery, tak to taktiez nie je problem, na to mame dost opominanu funkcionalitu Blockrecover (na to mame fullbackupy, inkrementaly a koniec koncov archivne redology) cize vieme urobit kokretne bloky.

Ano, Oracle si opravnene mysli, ze zapisal na disk (aj ked zapisal do cache) pretoze dostal ACK o zapise. Chcete snad povedat, ze IBM DB2 kona inak, resp. ze nepise do cache na urovni storage? Za prve to nevie ovplyvnit a za druhe sa riadi tym co jej povie OS. Mimochodom crash recovery u DB2 je velmi podobna ako u Oracle, je tu par specifickych rozdielov, ale princip je ten isty.

Ano, Oracle vydava DB aj pre mainframe.

"Ja unixovej oracle nemam moc rad (nevim zda jeste delaji ten mainframovej) sam bych ho pro inhouse aplikaci nepouzil, porad se v nem neco sere. Potrebuju aby to jelo a mohli jsme delat a vydelavat. To snad uz i ten informix je lepsi protoze se do nej nemusi neustale vrtat.
Naprotitomu unixovou DB2 lidi provozuji pod SAPem bez toho aniz by meli vyhrazeneho db administratora, jen si nechaji delat upgrady od servisnich firem. To by si nikdo s Oraclem nedovolil, tam se porad resi problemy typu dohaje proc to zase jede tak pomalu, to zase jsou statistiky v hajzlu nebo co?
Koncim flamewar, jdu vydelavat USD."


Ak dovolite, toto necham bez komentara, pretoze evidentne "rozumiete problematike" a nechcem pouzivat invektivy.
Mimochodom od Oracle 10g je zber databazovych statistik automaticky vykonavany (pokial to niekto nezrusil alebo neprestavil) tak a) vzdy od 22:00-06:00. b) cez vikend.

Takze moznosti je 5:
1. Mate Oracle starsi ako 10g a neratate statistiky vobec alebo len v pripade problemov = zly DBA, pretoze ide o fundamentalne zaklady
2. Ak mate 10g tak niekto zrusil job na zber statistik. Ak to nenahradil inym zberom = zly DBA, pretoze ide o fundamentalne zaklady
3. Ak job zbieha, mate, tak zrejme mate dost velku DB a tum padom, zber statistik nie je dostatocne rychly, resp. default job nestihne v potrebnej dobe dostatocne frekventovane uskutocnit zber. = DBA musi identifikovat tieto objekty a ratat explicitne statistiky s vacsou frekevenciou. Ak nevie ako to identifikovat alebo ako to nastavit = zly DBA, pretoze ide o fundamentalne zaklady
4. Statistiky mozu mat nespravne parametre (granularita, histogramy atd.) ktore zapricinia ze Cost Based Optimizer zvoli nespravny exekucny plan.
5. Nie je to vobec problem statistik

Mozno sa to zda prilis komplikovane, ale presne tak je to komplikovane aj pri inych DB, niekde menej a niekde viacej a prave preto tu mame poziciu DBA a DBA musi mat tieto znalosti, minimalne preto aby vedel poskytovat poradenstvo architektom resp. designerom a programatorom DB aplikacii. Zial dnes vela ludi do databaz viac keca ako im rozumie.
Nie som zaslepeny obhajcom Oracle, robim s viacerymi DB od viacerych vendorov a mam viac ako 10 rokov denno dennej skusenosti s tymito DB, preto mi pride vela vyrokov velmi smiesnych resp. mam pocit, ze niektore je potrebne konfrontovat.
Napriklad ten, ze s Oracle su sustavne problemy... tu mozem povedat len jedno, zamyslite sa nad kvalitou vasich DBA.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Ivan 01. 12. 2010, 00:06:34
Nie som zaslepeny obhajcom Oracle, robim s viacerymi DB od viacerych vendorov a mam viac ako 10 rokov denno dennej skusenosti s tymito DB, preto mi pride vela vyrokov velmi smiesnych resp. mam pocit, ze niektore je potrebne konfrontovat.
Napriklad ten, ze s Oracle su sustavne problemy... tu mozem povedat len jedno, zamyslite sa nad kvalitou vasich DBA.

No, kdyz napises dotaz a on polozi Oracle, nebo bezi 100x dele nez na jine DB a jeste k tomu bez optimalizace, nebo nedobehne vubec, tak je spatny Oracle a ani super admin tomu proste nemuze pomoct. Taky spatna volba planu, spatny rebuild indexu a podobny veci jsou proste spatnym navrhem DB a ne spatnym Adminem. Oracle je docela hodne zabugovana DB a kdyz ohlasis chybu na Oracle i s testcase tak na Tebe support Oracle prdi dokud jim nedelas mnohamilionove obraty mesicne. A doba kym vydaji opravu ... skoda mluvit. A kdyz vydaji opravu na bug A, tak rozkopou 10 jinych veci, ktere pred tim jiz byly 2x opraveny, jako kdyby ani nepouzivali unittesty.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 01. 12. 2010, 02:29:04
No, kdyz napises dotaz a on polozi Oracle, nebo bezi 100x dele nez na jine DB a jeste k tomu bez optimalizace, nebo nedobehne vubec, tak je spatny Oracle a ani super admin tomu proste nemuze pomoct. Taky spatna volba planu, spatny rebuild indexu a podobny veci jsou proste spatnym navrhem DB a ne spatnym Adminem. Oracle je docela hodne zabugovana DB a kdyz ohlasis chybu na Oracle i s testcase tak na Tebe support Oracle prdi dokud jim nedelas mnohamilionove obraty mesicne. A doba kym vydaji opravu ... skoda mluvit. A kdyz vydaji opravu na bug A, tak rozkopou 10 jinych veci, ktere pred tim jiz byly 2x opraveny, jako kdyby ani nepouzivali unittesty.

Prosim Vas nehovorte hluposti.
Co je bugove na tom, ze sa zmenila kardinalita dat, resp. selektivita indexu a CBO sa opiera o povodne statistiky, kde prave vykonavany plan bol optimalny? Alebo na to urobil DBA SQL profile alebo nedajboze stored outline, ktory tento plan forsiruje. To je na vine databaza? Alebo design databazy?
Prosim definujte co myslite pod pojmom "spatny rebuild indexu"?
Zaujimave je, ze Ste vobec nespomenuli moznost spatne navrhnuteho SQL dotazu.
Taktie je zaujimave, ze Ste vobec nespomenuli moznost spatneho navrhu datoveho modelu.

Viete co. Mam navrh. Ak na taketo nieco narazite ze sa bude query chovat tak ako ste popisali. A vy vulucite, ze ide o chybne napisane SQL query, ze vas DBA urobil vsetko co mal a ze vasa aplikacia je postavena na dobrom datovom modeli, skratka budete mat pocit, ze to je problem zlej DB, tak poslite mi e-mail na adresu: rotdba(nespamuj)orangemail(bodka)sk, prilozte relevantny trace z SQL urovne 12 a v surovej forme a taktiez CBO trace z uvedeneho SQL.
Tuto schranku dohladujem, takze vam urcite odpoviem a rad obetujem par minut svojho casu na takyto problem. Zaroven si ale vyhradzujem pravo zverejnit analyzu a jej vysledok (samozrejme hodnoty v query sa budu lisit) na svojej stranke.
Dovtedy prosim vo vlastnom zaujme nerozirujte taketo bludy.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 01. 12. 2010, 02:36:25
Zaroven si ale vyhradzujem pravo zverejnit analyzu a jej vysledok (samozrejme hodnoty v query sa budu lisit) na svojej stranke.

Len dodam, ze vysledok analyzy uverejnim aj na root.cz ak o to bude zaujem, resp. ak to bude mozne.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Ivan 01. 12. 2010, 20:04:46
Prosim Vas nehovorte hluposti.
Zaujimave je, ze Ste vobec nespomenuli moznost spatne navrhnuteho SQL dotazu.

Dotaz ani DB struktura nemuze byt navrzen spatne, protoze bezi na dalsich 4 serverech bez probelmu. (coz jsem psal)
Název: ora vs db2
Přispěvatel: Lenin POWER! 01. 12. 2010, 21:39:30
Nehnevajte sa ale takmer cokolvek co bezi na mainframe dokaze mat takmer nulovy downtime, pretoze to je uloha mainframeu.
Mainframe neni jenom HW. Pro vysokou dostupnost je potreba aby tuto funkcionalitu podporoval operacni system a aplikace. Je nutna soucinost vsech techto slozek. Pokud na mainframe jedete linux, tak to ho pak pouzivate jen jako nastroj pro virtualizaci.

Takze kdyz na mainframe nainstalujete oracle, tak ty veci co neumeli delat bez downtime na unixu nebude umet delat ani na mainframu. Mainframova DB2 a unixova DB2 jsou dva odlisne produkty, ktere maji jednak uplne rozdilnou administraci a nemaji ani 100% kompatibilni user mode SQL statementy. Mainframova DB2 toho umi vic nez unixova DB2. Kuprikladu unixova neumi index nad vyrazem bez toho aniz by se vytvoril v tabulce generated always sloupecek. Unixova DB2 je slabsi odvar te mainframove, ackoliv to neplati vzdy par drobnosti ma ta unixova zase navic. Mainframovej oracle je ale klasickej oracle jaky zname z unixu.

My mame na mainframu za poslednich 8 let nulovy downtime (planovany i neplanovany). Srovnejte si to s oraclem, ktery donedavna (neco okolo 10 nebo 11) neumel ani tak zakladni vec jako online index build. DB2 podporuje jenom online index build uz od svych ranych verzi pred 25 lety. Proto taky oracle na mainframech prakticky nikdo nepouziva (linuxovou verzi nepocitam to spis pouzivaj zVM virtualizaci).

Ale zabudli ste na jednu podstatnu vec, napr. na ludsky faktor, chyba v aplikacii, tieto veci vam mozu sposobit stratu dat a tu vam mainframe vobec nepomoze.
Ale pomuze, vzdyt u DB2 kdyz mate jeden z toolu co k tomu dodavaji - tusim snad recovery expert tak muzete selektivne vracet jednotlive transakce nebo vratit databazi par minut zpet. Nejsou k tomu zapotrebi zadne specialni upravy aplikace, staci klasicke transakcni logy.

Opravim vas, prv nez Oracle zapise do datafileu, tak pred tym zapise do logu (konkretne do online redo logu) je to prave kvoli tomu, ze ak by doslo k vypadku, urobi takzvane Instance (alebo crash) recovery, kde v ramci rollforward fazy aplikuje vsetky zmeny a potom vramci rollback fazy tie necommitnute odroluje (to uz pri otvorenej DB).
Vidite, ziadna strata.

1. oracle ma spoustu bugu. uz nekolikrat se mi stalo ze mi shutdown immediate zmrsilo databazi tak ze pak nesla nastartovat bez recovery. shutdown abort jsem nekolikrat pouzil a to mi zrovna databazi nezmrsilo, nicmene jsem mel dost vitr ze prijdu o data.

Naproti tomu u db2 shutdowny nedelam nikdy a to asi uz 10 let a nikdy jsem o zadna data neprisel. udelam power off na cely virtualni stroj, je to rychlejsi. Taky delam misto cekani na rollback reset virtualniho stroje. Recovery probiha v nekolika procesech soucasne, tak vyjde rychleji nez uzivatelsky rollback ktery dela jen jeden agent. Pravda, odpraskne to transakce i vsem ostatnim uzivatelum, ale websphere je umi zopakovat na novem pripojeni do db, ktere si automaticky vezme dalsi db2 image ktery je up.

U oracle jsem chtel taky praktikovat resetem delane rollbacky nicmene asi 3 ti den jsem prisel o data a tak jsem toho uz pak nechal. Misti oracle admini mi to nedoporucovali.

Ano, Oracle si opravnene mysli, ze zapisal na disk (aj ked zapisal do cache) pretoze dostal ACK o zapise.
Oracle je kriticky zavisly na tom ze kdyz zapise do logu checkpoint rekord ze musi mit datove stranky opravdu zapsane na disk. Pokud je nema poskodi to databazi pri recovery, nabouraji se mu bloky. Vzhledem k tomu ze tento jev nenastava zrovna malo casto (disky maji casto interni cache a kecaji o zapisu) tak ma oracle funkci block recover. DB2 ji nema nebyl k jejimu napsani duvod, protoze tento jev u ni nenastava, tam bloky zarvou jen v pripade hw chyb.

Chcete snad povedat, ze IBM DB2 kona inak, resp. ze nepise do cache na urovni storage? Za prve to nevie ovplyvnit a za druhe sa riadi tym co jej povie OS.
DB2 nedela nikdy checkpointy, takze jeji suma fuk zda ji ty disky kecaji nebo ne. dokaze se s tim pri recovery vyrovnat. Takove algoritmy existuji. ZFS to umi taky. Oracle by si mel tuto patentovanou technologii koupit.

Mimochodom crash recovery u DB2 je velmi podobna ako u Oracle, je tu par specifickych rozdielov, ale princip je ten isty.
neni. Oracle pouziva checkpoint based system - tedy klasiku. DB2 ma ARIES, coz je checkpoint free algoritmus pro obnovu dat pri vypadku. Z pohledu admina to sice muze vypadat velmi podobne, ale uvitr je to velmi jine. ARIES taky pracuje s tim ktere transakce jsou a ktere nejsou na disku, ale nepotrebuje tuto informaci pro obnovu. ARIES se umi vyporadat se stavem ze ma sice v logu napsano ze tato transakce by mela byt zapsana i v datovych souborech a on kontrolou hlavicek stranek zjisti ze se tam nezapsala tak umi transakci vratit zpet, naproti tomu oracke rozbije ty inkriminovane bloky. Oracle by mohl udelat to same pokud by mel konzistentni rollback segment ale to mit nebude protoze pri tehlech pruserech zarve rollback segment jako prvni.
DB2 pri prvnim startu po rebootu projede cely transakcni log bez ohledu na znacku kam az se to udajne stihlo zapsat na disk a porovna hlavicky logu s hlavickama datovych stranek zda jsou vuci sobe konzistentni. Vetsinou si lidi nechavaji tak 10GB online logu aby to nedelalo dlouhe starty, ty to projede maximalne za 5 minut, vetsinou neco pres minutu.

Ak dovolite, toto necham bez komentara, pretoze evidentne "rozumiete problematike" a nechcem pouzivat invektivy.
Ja problematice databazi rozumim rozhodne lepe nez vy. Mam cerifikaty jak od oraclu tak od ibm a to na unix i mainframe platformu. Jsem v data warehousingu dost dobrej a navic vyrazne vic vydelavam. Za 1 den vydelam asi tolik co vy za rok, kdybyste byl tak dobrej jak tady machrujete tak proc by jste si uz nekoupil nejakou IT firmu. Banky dneska pujcuji na cokoliv levne.

Mozno sa to zda prilis komplikovane, ale presne tak je to komplikovane aj pri inych DB, niekde menej a niekde viacej a prave preto tu mame poziciu DBA.
DBA pozice by mela delat tvurci praci a ne rutini ukoly. Znalosti dba by se meli vlozit do db enginu a nechat ho delat tyto veci automaticky.
1.
DB2 umi jednak automaticky spoustet statistiky kdy jsou potreba (synchrone - necha dotaz cekat nez dojedou nebo asynchrone). To je vyrazne zlepseni vuci oracle, ktery dela statistiky pres pouhy job scheduler.
2.
Umi trasovat dotazy a zjistovat nad kterymi sloupecky jsou potreba podrobnejsi a jak moc podrobne statistiky.
3.
DB2 Executor (technologie LEO) umi kompenzovat statistiky neodpovidajici datum. V pripade ze admin + 1 + 2 selze. Dela si krivku kterou aplikuje na statistiky tak aby odpovidaly skutecnemu stavu. Dokaze pri zjisteni neschody - statistiky vs real v prubehu dotazu spustit novou optimalizaci dotazu a pouzit jiz ty casti ktere se vykonaly aby se nemuseli v novem planu opakovat. Vynikajici vec pro dlouhe warehouse dotazy.
4.
i5/os DB2 umi dokonce sama vytvaret i chybejici a likvidovat nadbytecne indexy. Vynikajici vec. Tahleta edice se povedla a ma MYSQL kompatibilni modul! Proto si LAMP patlalove v bankach oblibili i5/os.

5.
automatickou reorganizaci dat a indexu umi vsechny

6.
taky ma db2 (i unixova) vynikajici vec - workload manager. To je naprosta nutnost, krasne si nadefinujete classy dotazu a muzete pak OLTP dotazy uprednostnovat pred OLAP. Workload managing v zOS je uzasna technologie a hezky to spolupracuje i s websphere.

Shrnuto. DB2 nema neustale srani se se statistikama. V pripade ze to dotaz na zaklade chybnych statistik podela, tak ho to podela jen 1x, pri dalsim vykonavani jiz pojede optimalni trasou. Proto se taky v DB2 manualni hinting prakticky nepouziva, zato v oracle se hintuje fest.

Napriklad ten, ze s Oracle su sustavne problemy... tu mozem povedat len jedno, zamyslite sa nad kvalitou vasich DBA.

Vemte si to tak, mam asi 90+ databazi (instanci v terminologii ora) DB2 a to mi spravuji 2 fulltime lidi. Kdybych mel 90 oraclu tak bych na to potreboval aspon 10 lidi.

Vemte si jaka je poptavka po oracle a db2 adminech. Odpovida trznimu podilu databazi t.j. 2:1 pro oracle? Ne, je zhruba 10:1 pro oracle adminy. Proc tomu asi tak je?

Znate nekoho kdo by mel 200k zamestancu a SAP pod oraclem a nemel na ten Oracle admina? Ja takovy instalace mainframove DB2 znam. Pravda maji tam asi jen 2 TB dat.

Jdu vydelavat. Nemam cas na dlouhe flamewars.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: DBA 01. 12. 2010, 21:40:12
No to este nic nemusi znamenat. Infromatika je exaktna veda a ja sa zoberam faktami, nie domnienkami.
Kazdopadne moj mail mate, ak si stojite za svojim tvrdenim, vyuzijete to.
Název: Re: ora vs db2
Přispěvatel: DBA 01. 12. 2010, 23:56:43
Niektori to zrejme nechapu, a tak to skusim este raz. Nie som zatazeny na Oracle, ale zial objavuju sa tu nazory, ktore nekoresponduju s realitou.

My mame na mainframu za poslednich 8 let nulovy downtime (planovany i neplanovany).
Gratulujem, ale nachapem cim sa tu chvalite, ved na to ste si zadovazili mainframe.

Srovnejte si to s oraclem, ktery donedavna (neco okolo 10 nebo 11) neumel ani tak zakladni vec jako online index build.

Blud c.1 Online Index Rebuild prisiel v Oracle 8i. Hovorime o roku 1999.


Ale pomuze, vzdyt u DB2 kdyz mate jeden z toolu co k tomu dodavaji - tusim snad recovery expert tak muzete selektivne vracet jednotlive transakce nebo vratit databazi par minut zpet. Nejsou k tomu zapotrebi zadne specialni upravy aplikace, staci klasicke transakcni logy.


Tak ako u Oracle Logminer, Flashback (pozor je ich niekolko a funkcionalita sa rozsiruje v kazdom release) toto mate v baliku.

1. oracle ma spoustu bugu. uz nekolikrat se mi stalo ze mi shutdown immediate zmrsilo databazi tak ze pak nesla nastartovat bez recovery. shutdown abort jsem nekolikrat pouzil a to mi zrovna databazi nezmrsilo, nicmene jsem mel dost vitr ze prijdu o data.

Blud c. 2, ani sa nejdem rozpisovat. Nema to zmyslel.

Naproti tomu u db2 shutdowny nedelam nikdy a to asi uz 10 let a nikdy jsem o zadna data neprisel. udelam power off na cely virtualni stroj, je to rychlejsi. Taky delam misto cekani na rollback reset virtualniho stroje. Recovery probiha v nekolika procesech soucasne, tak vyjde rychleji nez uzivatelsky rollback ktery dela jen jeden agent. Pravda, odpraskne to transakce i vsem ostatnim uzivatelum, ale websphere je umi zopakovat na novem pripojeni do db, ktere si automaticky vezme dalsi db2 image ktery je up.

Bavme sa iba o DB2, Websphere vynechajme, ibaco by sme to zbytocne vetvili. Poznamka pre nadejnych DB2 DBA z tohto si rozhodne priklad neberte.

U oracle jsem chtel taky praktikovat resetem delane rollbacky nicmene asi 3 ti den jsem prisel o data a tak jsem toho uz pak nechal. Misti oracle admini mi to nedoporucovali.

Toto hodne vypoveda o vasich skusenostiach a hlavne vedomostiach o Oracle a ani certifikaty vam nepomozu tento obraz zmenit.

Oracle je kriticky zavisly na tom ze kdyz zapise do logu checkpoint rekord ze musi mit datove stranky opravdu zapsane na disk. Pokud je nema poskodi to databazi pri recovery, nabouraji se mu bloky. Vzhledem k tomu ze tento jev nenastava zrovna malo casto (disky maji casto interni cache a kecaji o zapisu) tak ma oracle funkci block recover. DB2 ji nema nebyl k jejimu napsani duvod, protoze tento jev u ni nenastava, tam bloky zarvou jen v pripade hw chyb.

Blud c.3 okrem jedineho, DB2 naozaj nema blockrecover funkciu.


DB2 nedela nikdy checkpointy, takze jeji suma fuk zda ji ty disky kecaji nebo ne. dokaze se s tim pri recovery vyrovnat.

Blud c. 4. alias nikdy nehovor nikdy napriklad: (mimochodm linka je na vasu oblubeny mainframeovu verziu): http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.admin/db2z_checkpointlogrecord.htm


Oracle pouziva checkpoint based system - tedy klasiku. DB2 ma ARIES, coz je checkpoint free algoritmus pro obnovu dat pri vypadku. Z pohledu admina to sice muze vypadat velmi podobne, ale uvitr je to velmi jine. ARIES taky pracuje s tim ktere transakce jsou a ktere nejsou na disku, ale nepotrebuje tuto informaci pro obnovu. ARIES se umi vyporadat se stavem ze ma sice v logu napsano ze tato transakce by mela byt zapsana i v datovych souborech a on kontrolou hlavicek stranek zjisti ze se tam nezapsala tak umi transakci vratit zpet, naproti tomu oracke rozbije ty inkriminovane bloky. Oracle by mohl udelat to same pokud by mel konzistentni rollback segment ale to mit nebude protoze pri tehlech pruserech zarve rollback segment jako prvni.
DB2 pri prvnim startu po rebootu projede cely transakcni log bez ohledu na znacku kam az se to udajne stihlo zapsat na disk a porovna hlavicky logu s hlavickama datovych stranek zda jsou vuci sobe konzistentni. Vetsinou si lidi nechavaji tak 10GB online logu aby to nedelalo dlouhe starty, ty to projede maximalne za 5 minut, vetsinou neco pres minutu.


Ak pod pojmom ARIES mate na mysli Algorithms for Recovery and Isolation Exploiting Semantics, tak si najskor prosim vas aspon nieco o tom precitajte nieco a potom skuste pisat do diskusii.

Ja problematice databazi rozumim rozhodne lepe nez vy. Mam cerifikaty jak od oraclu tak od ibm a to na unix i mainframe platformu.
Stavim sa, ze ste aj dokonca vyssi ako ja, aspon minimalne o hlavu.

Jsem v data warehousingu dost dobrej a navic vyrazne vic vydelavam.
To ze ste dost dobry v datawarehousingu o vas musia povedat ini ludia, nie vy sam. Ja zatial o vas viem, ze sirite akurat FUD a to na zaklade vlastnej neznalosti. Zaroven lutujem toho, kto vas plati ak vasa praca je podobne kvalitna ako vase prispevky.

Za 1 den vydelam asi tolik co vy za rok, kdybyste byl tak dobrej jak tady machrujete tak proc by jste si uz nekoupil nejakou IT firmu. Banky dneska pujcuji na cokoliv levne.
Prepacte ale merat sa s vami nebudem. Z detinskych veci som vyrastol. Mimochodom, kde beriete to presvedcenie o mojom zarobku alebo o firme? Ale pravdepodobne, to bude z toho isteho pramena ako vase "mudrosti", ktore tu pisete. Ale uzivajte si vase peniaze v zdravi, ja Vam to doprajem.


DBA pozice by mela delat tvurci praci a ne rutini ukoly.
Neverim, prva normalna veta od Vas a dokonca s nou aj suhlasim. A dokonca aj za beznych okolnosti to tak aj je. Zial obcas su potrebne aj rutinne ulohy.

Znalosti dba by se meli vlozit do db enginu a nechat ho delat tyto veci automaticky.
Potom by neboli potrebny DBA, neboli by potrebne skolenia, state v dokumentacii, clanky na internete a techniky ladenia vykonnosti, napriklad.

1.
DB2 umi jednak automaticky spoustet statistiky kdy jsou potreba (synchrone - necha dotaz cekat nez dojedou nebo asynchrone). To je vyrazne zlepseni vuci oracle, ktery dela statistiky pres pouhy job scheduler.


To cez co je spustane je jedno. Zalezi co je  vykonavane a vy podla toho ako ste to napisal, nemate ani paru o tom ako su tieto statistiky zbierane. Iba spekulujete a tym vytvarate FUD. Pre vasu informaciu, ta default procedura pre kazdy objekt stanovi automaticky ako nad nou budu ratane statistiky, aku bude mat prioritu pri zbere statistik, paralelizmus, ci s histogramami alebo bez a s akymi. a podobne. A prepacte synchronne tu nema cenu, pretoze so zozbieranymu statistikami viete nadalej pracovat. Nehovoriac, ze ich viete zbierat aj manualne a samozrejme aj modifikovat. Taktiez viete rozhodnut o sposobe ich aplikacie.
Nic len dalsi blud z vase strany.

2.
Umi trasovat dotazy a zjistovat nad kterymi sloupecky jsou potreba podrobnejsi a jak moc podrobne statistiky.

Ano, to i Oracle.

3.
DB2 Executor (technologie LEO) umi kompenzovat statistiky neodpovidajici datum. V pripade ze admin + 1 + 2 selze. Dela si krivku kterou aplikuje na statistiky tak aby odpovidaly skutecnemu stavu. Dokaze pri zjisteni neschody - statistiky vs real v prubehu dotazu spustit novou optimalizaci dotazu a pouzit jiz ty casti ktere se vykonaly aby se nemuseli v novem planu opakovat. Vynikajici vec pro dlouhe warehouse dotazy.


V tomto bode by to bolo na dlho. Boli by ste totiz prekvapeny ako casto bojujem s LEOm a ze bezchybny teda rozhodne nie je.

6.
taky ma db2 (i unixova) vynikajici vec - workload manager. To je naprosta nutnost, krasne si nadefinujete classy dotazu a muzete pak OLTP dotazy uprednostnovat pred OLAP. Workload managing v zOS je uzasna technologie a hezky to spolupracuje i s websphere.


Oracle ma tiez podobne zalezitosti, nic nove a prevratne.

Shrnuto. DB2 nema neustale srani se se statistikama. V pripade ze to dotaz na zaklade chybnych statistik podela, tak ho to podela jen 1x, pri dalsim vykonavani jiz pojede optimalni trasou. Proto se taky v DB2 manualni hinting prakticky nepouziva, zato v oracle se hintuje fest.

Hinty su posledna moznost, ktoru ma vyvojar zvazit. To ze niekto hintuje fest, este neznamena, ze naozaj musi, resp. musel.

Vemte si jaka je poptavka po oracle a db2 adminech. Odpovida trznimu podilu databazi t.j. 2:1 pro oracle? Ne, je zhruba 10:1 pro oracle adminy. Proc tomu asi tak je?
Prepacte moj obor je IT, nie HR. Ale je potrebne rozlisovat napr. Oracle App. Administrator a DB Administrator.

Znate nekoho kdo by mel 200k zamestancu a SAP pod oraclem a nemel na ten Oracle admina? Ja takovy instalace mainframove DB2 znam. Pravda maji tam asi jen 2 TB dat.
SAP je nad Oraclom, nie opacne. A ked hovorime o SAPe na Oracle DB, tak uz nehovorime o Oracle DB ale o mutantovi. To uz s Oracle uz ma pramalo spolocne. Ale to uz zial mimo vase chapanie.

Jdu vydelavat. Nemam cas na dlouhe flamewars.
Kludne chodte. Tak ich nevtvarajte a hlavne nespravnymi informaciami, lebo sa mi zda ze mate silne nutkanie nieco povedat alebo si honit ego, nic viac.
Název: Re: Rozdíl mezi SQL a MySQL
Přispěvatel: Lenin POWER! 03. 12. 2010, 13:33:24
Oracle je docela hodne zabugovana DB a kdyz ohlasis chybu na Oracle i s testcase tak na Tebe support Oracle prdi dokud jim nedelas mnohamilionove obraty mesicne. A doba kym vydaji opravu ... skoda mluvit. A kdyz vydaji opravu na bug A, tak rozkopou 10 jinych veci, ktere pred tim jiz byly 2x opraveny, jako kdyby ani nepouzivali unittesty.
Jo nam tam lezi reporty bugu i s prikladama nekolik (i 5) let. Ja jsem empiricky zjistil ze kdyz potrebujeme opravit nejaky bug v oraclu, tak je nejlepsi pouzit me zname v ibm aby ten bug do oraclu nareportovali oni. Pak to oracle opravi tak do 3 tydnu.