Archyvas

Įrašai, pažymėti ‘fetch’

100 ir 1 priežastis kodėl MySQL >> IBM DB2. Arba kodėl protingi naudoja MySQL

2009.12.04 Xamas Komentarų: 0

[PAPILDYTAS - 2009.12.11]

Atsakom į esminį klausimą:

“Why Mysql is hundred and one time better than IBM DB2″.

Pirma:

MySQL’eriai rašo: LIMIT 12;

IBM DB2’seriai rašo: FETCH FIRST 12 ROWS ONLY;

Antra:

MySQL’eriai rašo: LIMIT 67,12

IBM DB2’seriai: nervinasi ir rašo lioliasdešimt eilučių užklausą

Trečia:

MySQL’eriai rašo:

(SELECT a FROM b WHERE c LIMIT 67,12)
UNION (SELECT a FROM b WHERE c LIMIT 111,2) ORDER BY a LIMIT 16,21

IBM DB2’seriai:

priversti pasiduoti, nes jų galvoje užklausos kodo
kiekis įgavo atžymą brain_overflow=1.

Ketvirta:

Mysql’eriai rašo:

auto_increment

IBM DB2’seriai rašo:

GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1)

Penkta:

Mysql’eriai rašo:
$man_ne_zhopa = mysql_insert_id();
IBM DB2’seriai rašo:
$i_luv_word_identity = IDENTITY_VAL_LOCAL();

Čia iš esmė tas pats, tik kad Mysql’as panaudojo savo brand’ing funkcijos pavadinimui.

Šešta:

Mysql’eriai rašo:

CREATE TABLE IF NOT EXIST agurkai

IBM DB2’seriai rašo:

Begin atomic
 if( exists(SELECT 1 FROM syscat.tables
        WHERE tabschema = 'MYSCHEMA' AND tabname = 'agurkai')
  )
then DROP TABLE MYSCHEMA.agurkai
else CREATE TABLE MYSCHEMA.agurkai;
 end if;
 End

Septinta:

Mysql’eriai rašo:

 DROP TABLE IF EXIST agurkai

IBM DB2’seriai rašo:

Begin atomic
 if( exists(SELECT 1 FROM syscat.tables
        WHERE tabschema='MYSCHEMA' AND tabname='agurkai')
  )
then DROP TABLE MYSCHEMA.agurkai;
 end if;
 End

Aštunta:

Mysql’eriai rūpinasi resursų taupymu(field2 išnaudojam int(11), su 4******…..) :

CREATE TABLE a(
 field1 bigint(11) unsigned NOT NULL,
 filed2 int(11) unsigned NOT NULL
))

IBM DB2’seriams vietos taupymas visiškai vienodai(aukštesnę užklausą db2 parašyti gausis tik taip):

CREATE TABLE a(
 field1 bigint NOT NULL,
 filed2 bigint NOT NULL
))

Devinta:

Kad netaupo vietos DB2’seriai, jau pastebėjom. Bet kad jie apskritai įgnoruoja ‘taupius’ laukelių tipus, t.y. tinyint’ą tai dar ‘protingiau’…

Dešimta:

Ignoruoja ir plačius laukelius jie, t.y. 65535′iolio TEXT’ą, bei ilgesnįjį jo brolį LONG TEXT’ą . Vietoj jų tik CLOB’ą gali pasiūlyti.

Vienuolikta:

MySQL šitas dalykas veiks:

FOREIGN KEY organizer_validation(identity_code)

O štai DB2 jau spjaudysis errorais – neva DB2 nesupranta ilgesnių nei 18 simbolių.

Dvylikta:

Mysql’e veiks ir šitas dalykas:

field3 varchar(255)

O štai DB2 šis limitas nestandartinis – ir maksimalus kuris veiks:

field3 varchar(254)

Turint omenyje kad PC viskas dvejetainiame/šešioliktainiame variante, tai MySQL’o [0-255] rodos į temą, o štai DB2 matyt kažkur kitur ;)

Trylikta:

O čia dar vienas bajeris, privertęs mane nusijuokti iš DB2 ‘developerio’ atsakymo.

Man įdomu ką IBM DB2’seriai atsakytų į klausimą – aš noriu nustatyti naują auto_incement reikšmę(tarkim prirašiau šlamšto, ir dabar vėl noriu kad skaičiuotų nuo 97). Mysql’eris parašys:

ALTER TABLE `table name` AUTO_INCREMENT=new_value;

DB2′erio pirmoji mintis:

aaaaaaaaa…………oooooooooooo……. hmmmmmmmm……????…. Nobody use that.

Ir tada duos ‘klasišką patarimą‘(paimta tiesiai iš IBM DB2 vieno iš support saitų):

What the heck are you doing that you need to do such a thing.
Either make you ID so big you'll never have to worry about it BIGINT
or DEC(31,0) if you are afraid of liability of your descendants ;-)
Or don't use identity to begin with and use a natural key.
Cheers, Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Jo, ilgam prajuokino. Na visad galima spręsti problemą įvairiai. Tarkim aš nežinau kokio dydžio bus duomenų masyvas mano programoje – tai velniop tuos pointerius ir ‘dynamic lists’ – susikuriame kvadratilijonį kvadratilijonuoju masyvą, išskirdami 100GB vietos harde ir galvos neskaudės. Sakyčiau būtų tikrai TOK(tobulai optimalus kodas). ;) :D :D:D

Ale linksmi žmonės dirba IBM. Vietoje pripažinimo kad FAIL tas jų DB2, pasakys ‘nafig tau to reikia:D .

————

Na bet galiausiai atsirado dar didesnis proto šviesuolis, kuris pasiūlė sukurti trigerį kuris executinis RESTART funkciją kas kuris laikas. Savo nuomonę apie trigerius(kuri yra vieša paslapis), aš išsakysiu įrašo pabaigoje.

Kitas pasiūlė nudropinti visą lentelę ir iš naujo perkurti :D .

——————-

………. Ir taip toliau :)

Tikiuosi visiems aišku “Why IBM DB2 sucks very much”.

Ir kaip pasaulyje dar gali būti žmonių kurie reikalauja programuoti šita kledaro lygio kalba.

Čia buvo retorinis pamąstymas.

—————

Pabaigai: Mano asmeninė nuomonė apie trigerius:

 sux sux sux sux sux sux sux sux sux sux sux sux sux sux sux fuck sux
 sux sux sux sux sux fuck sux sux sux sux sux sux sux sux sux sux sux
 sux sux sux sux sux sux sux sux sux sux sux sux sux sux sux fuck sux
 sux sux sux sux sux sux fuck sux sux sux sux sux sux sux sux sux sux
 sux sux sux sux sux sux sux sux sux sux sux sux sux sux sux

Beje, ar tai tik sutapimas – bet trigerį pirmą kartą ‘life ever‘ panaudojau tik universitete, kai dėl jo privalomo naudojimo tiesiog ‘užlipo’. Vienintelis atvejis kada trigeris gali būti naudojamas, tai tik tuomet kai kartu neprogramuojama pati programa – čia praktiškai trigeris leidžia interpretuoti programos kodą. Ir realybėje(teorija – gražu, realybė – kai būna iš tiesų), bet kuriam ‘newly hired software engineer’ yra daug papraščiau CTRL+F pagalba(net ir find in files atveju), išsiaiškinti ką kode reiškia dalis:

UPDATE ".DB_CLIENT."
SET client_new_orientation='".$core->validate_orientation($client['ornt'])."'
WHERE client_id=1

Nei sėdėti 2 valandas ir nesuprasti kodėl gaunami SQL_STATE errorai atlikus trivialią užklausą:

UPDATE clients SET savings_after_robery=10000.49 WHERE client_id=1

Dar mane kamuoja kažkokia mistiška nuojauta, kad per artimiausius n-metų aš jo daugiau galiu ir nebepanaudoti. :)

PS. Dar aš kartais ignoruoju ‘read more’ dalį. Todėl visą blogo įrašą šį kartą atpyliau į “excerpt’ą”.

Kategorijos: programavimas Žymos: , , , , ,