Még 2012-2013-ban volt hozzá szerencsétlenségem; a kukakulának kellett 3 promóciós-kupakfeltöltős weboldalt lefejleszteni és ők pedig csak Oracle-lel voltak hajlandóak dolgozni. (Abból is az Express Editionnel.) Persze ebben az is benne volt, hogy mélyvíz volt, akkor láttunk először közelről Oracle DB-t, de a felmerülő problémákra a megoldásokat nem mi hánytuk össze ad-hoc módon, tudás híján saját kútfőből, hanem Oracle GURU-k által elkövetett netes manualokból és stackoverflow posztokból puskáztuk ki.
Problémáim voltak vele többek közt a következőek (és még egyszer hangsúlyozom, 2012-2013, nem tudom, ebből még mi igaz):
- Amikor fetc_assoc-kal lekértük az aktuális sort a lekérés eredményéből, minden mezőt nagybetűkkel adott vissza, függetlenül attól, hogy én milyen betűket használtam a mezőnevek definiálásakor és mivel a névazonosított tömbök case-dependent-ek, így mindjárt ezzel szívás volt.
- Integer adattípus egyáltalán nem létezik, a number egy 160-bites (vagy 192?) lebegőpontos szám; nagyon helytakarékos, erőforráskímélő és gyors, amikor egy sima 8, 16 vagy 32-bites integert szeretne tárolni az ember.
- Nincs benne se LIMIT, se OFFSET. Helyette egy bedrótozott immaginárius rownum oszlop van. Amivel így lehet pl. lapozni:
SELECT * FROM
(
SELECT a.*, rownum r__
FROM
(
SELECT * FROM ORDERS WHERE CustomerID LIKE 'A%'
ORDER BY OrderDate DESC, ShippingDate DESC
) a
WHERE rownum < ((pageNumber * pageSize) + 1)
)
WHERE r__ >= (((pageNumber-1) * pageSize) + 1)
Hogy ez a két kulcsszót három egymásba ágyazott SELECT-tel helyettesítő kód milyen szép az egy dolog, de az megvan, hogy így tkp. az egész táblát le kell kérnie az embernek ahhoz, hogy lapozni tudja?
- Nincs autoincrement flag, szekvenciákat (sequence.nextval()) pedig beszúrásnál nem lehetett használni: "ora-02287: sequence number not allowed here"
- Egyetlen szöveges típusú mező van benne, a VARCHAR2 (igen, 2), ami max. 4000 karakter lehet. Van ugyan CLOB, de:
* A CLOB - nomen est omen - objektumként jön vissza a fetch után és külön loaddal kell betölteni. Ez is nagyon jót tesz a sebességnek az amúgy is hulladék és tetűlassú PHP nyelvben.
* A CLOB-ban nem működik a LIKE, tehát nem lehet benne keresni csak úgy.
* A CLOB-ot JOIN-olni sem lehet, tehát, ha a különféle tartalmak nyelvi adatai egy másik táblában vannak, amit content ID és language ID által JOIN-olsz, akkor azt nem tárolhatod CLOB-ban, vagy írhatsz rá mezőnként subselecteket.
* A CLOB ugyan max 8 TB hosszú lehet, de adatot egyszerre beletölteni maximum 4000 karakternyit lehet.
Σ: Ezek a limitációk tárolt eljárásokkal kerülhetőek meg, lehet iszonyatosan bonyolult és konvulens lekérési eljárásokat írni, miknek segítségével a CLOB-ot 4000 karakter méretű darabonként VARCHAR2-be konvertálhatod...egészen 32000 byte méretig bezárólag... Inkább nem kísérleteztem azzal, hogy olyan SQL eljárásokat írjak, ami többszörösen egymásba ágyazott subselectek végtelen sorozatával és konkatenációk egész hadseregével lehetővé teszi azt, hogy helyettesítsem a LIKE vagy a JOIN parancsot, inkább beismerem, hogy nem tudok ilyet, nem megy ez nekem, leülök elégtelennel és elmegyek kapálni... Vagy inkább használok normális DB motort (pl. PgSQL-t).
- Képtelenek voltunk belőni benne a karakterkódolást és igen, ez lehet, hogy a mi szegénységi bizonyítványunk, de az már aligha, hogy ha HTML entitást szúrtunk be a DB-be, akkor azt a DB lekéréskor már úgy adta vissza, hogy visszakonvertálta karakterré és ékezettelenítette. Így pl. egy "ö" entitásból csak simán "o" lett. Ki kérte, hogy elemezze a beszúrt adatokat, azt meg pláne ki kérte, hogy önhatalmúlag bele is nyúljon? Lehetett saját "házi" entitásokat használni, pl.: ö = _*o*_
- Nem volt hozzá normális DB kezelő tool, de szerencsére az Adminer Oracle-t is tud.
- Az Oracle a whitespace karaktereken is fennakad és kriptikus, teljesen irreleváns hibaüzenetekkel szórakoztatja a fejlesztőket.
- Az Oracle hibaüzenetei ezen felül is teljességgel ad-hoc módon adnak tájékoztatást, hogy mi a nyavalya baja van épp a motornak. Pl. a következő három SQL query:
CREATE TABLE "TABLENAME1" (
"ID" number NOT NULL,
"FIELDN1" number NOT NULL,
"FIELDN2" number NOT NULL DEFAULT '-1',
"FIELDN3" number NOT NULL DEFAULT '0',
"FIELDN4" number NOT NULL
);
CREATE TABLE "TABLENAME1" (
"ID" number NOT NULL,
"FIELDN1" number NOT NULL,
"FIELDN2" number NOT NULL DEFAULT ('-1'),
"FIELDN3" number NOT NULL DEFAULT ('0'),
"FIELDN4" number NOT NULL
);
CREATE TABLE "TABLENAME1" (
"ID" number NULL,
"FIELDN1" number NULL,
"FIELDN2" number NULL DEFAULT '-1',
"FIELDN3" number NULL DEFAULT '0',
"FIELDN4" number NULL
);
egy darab "ORA-00907: missing right parenthesis" error-t fog eredményezni. Milyen jobboldali zárójel hiányzik ennek a szarnak? Minden kinyitott zárójel be is van zárva. És bármit is próbáltunk DEFAULT-ként beállítani úgy, hogy volt előtte valami írva, ezt kaptuk. Pedig tuti lehet alapértéket adni a NOT NULL mezőknek...vagy nem?
Most hirtelen ennyit tudtam összeszedni, már rég volt. Mindenesetre Mcload kollégámnak az volt a véleménye, hogy ekkora szart még dilettantizmusból vagy balfasságból is képtelenség összehozni, ezt szándékosan csinálták, hogy az alapfunkciók hiányát pótló, kötelező jelleggel megírandó tárolt eljárások mennyisége és komplexsége elrettentsen mindenkit attól, hogy bepróbálkozzanak vele és inkább megvegyék az überdrága, seggkinyaló fejlesztőeszközöket... Hát, az Oracle-t ismerve ez egyáltalán nem lepne meg.
Lehet tolni a nem értesz hozzá dumát. Amúgy tény: nem értek hozzá, de a fentiek után nem is akarok.