HOVD 2003-2018: Még egy adag grafikon

  • Kedvenc adatbázis kezelő
  • Kedvenc Linux Disztribúció (ez a kategória pár éve fel lett bontva szerver/desktop-ra, hogy a folytonosságot megőrizzem a szerver+desktop számok összesítve vannak az újabb években)
  • Kedvenc BSD rendszer
  • Kedvenc virtualizációs technológia
  • Kedvenc desktop környezet

Hozzászólások

szerintem az (is) érdekes, ahol az other kategória magasan van, pláne ahol felfele megy, vagy mint a kedvenc desktop második helyen van. valszeg ott jobban elő tudtuk volna készíteni a szavazást. amúgy nekem sose hiányzott a pontom, mindig egyértelmű volt hova.

Ahol nagyon magas az "egyéb" az azért is lehet, mert szar a grafikon. Némely kategóriában nagyon sok változás van 15 év alatt, ami nem csak annyit jelent, hogy sokat mozognak a görbék le-fel, de azt is, hogy a szereplők is megváltoztak közben, esetleg többször is. Ezért aztán bele kell raknom egy csomó szereplőt az egyébbe, lehet, hogy olyat is ami egy adott évben amúgy egész jól szerepelt és megérdemelne egy saját vonalat...

Bocsi, ez a bejegyzes nemtom miert ugrott fel ide... mar vagy egy hete irtam. Lehet, hogy veletlenul beleszerkesztettem ma mikor a masikat irtam. Es ettol megvaltozik a datuma is?!

Tényleg nem flame-nek szánom, de ki az, akinek az Oracle DB-je a kedvenc DB-je és miért?

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 "&ouml;" 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.

En meg regebben, 2012 elott foglalkoztam Oracle-lel. :) Es nem fejlesztettem, hanem inkabb adminkodtam, ugyhogy a fentiek nagy resze nem mond nekem semmit. Talan egy megis:

"Nem volt hozzá normális DB kezelő tool..."

Oracle SQL Developer, a nevevel ellentetben nem csak Oracle DB-hez tud kapcsolodni. Oracle DB-t mar nem hasznalok evek oda, de az SQL developer-t megtartottam, ha nagy ritkan MySQL-ben kell bogarasznom. De tud Postgres-t is, meg asszem MS SQL-t (meg meg mast is?!).

Az ORA-NNNNNN kodos hibauzeneteket meg pont szerettem (jo, hat te pont belefutottal valamibe ;) ), tok jo, hogy nem csak egy hibauzenet van, hanem ez a kod, sokkal jobban lehet guglizni.

Sokszor volt amugy az az erzesem, hogy ezt nem fejlesztok csinaltak fejlesztoknek szeretettel, hanem arra mentek ra, hogy sok feature-t ki lehessen pipalni, hogy jol eladhato legyen, az mar nem baj, ha kicsit kenyelmetlenul lehet hasznalni. Na de, hat egy kereskedelmi termeknel ez nem annyira fura. Futottam bele en is egy par pofonba, de soha nem az derult ki, hogy ez egy szar amivel ezt vagy azt nem lehet megoldani. (Es akkor meg egyszer: en admin oldalrol egy kicsit mas felol nezegettem.)

> Oracle SQL Developer, a nevevel ellentetben nem csak Oracle DB-hez tud kapcsolodni. Oracle DB-t mar nem hasznalok evek oda, de az SQL
> developer-t megtartottam, ha nagy ritkan MySQL-ben kell bogarasznom. De tud Postgres-t is, meg asszem MS SQL-t (meg meg mast is?!).

Fura, ez valahogy nem került elénk.

> Az ORA-NNNNNN kodos hibauzeneteket meg pont szerettem (jo, hat te pont belefutottal valamibe ;) ), tok jo, hogy nem csak egy
> hibauzenet van, hanem ez a kod, sokkal jobban lehet guglizni.

Nem az volt a bajom, hogy hibakódot ad, az pont jó; az a baj, hogy hótt irreleváns volt, amit adott. Nem egybe futottunk bele, hanem tucatnyiba, csak ez maradt meg.

> Sokszor volt amugy az az erzesem, hogy ezt nem fejlesztok csinaltak fejlesztoknek szeretettel, hanem arra mentek ra, hogy sok
> feature-t ki lehessen pipalni, hogy jol eladhato legyen, az mar nem baj, ha kicsit kenyelmetlenul lehet hasznalni. Na de, hat egy
> kereskedelmi termeknel ez nem annyira fura. Futottam bele en is egy par pofonba, de soha nem az derult ki, hogy ez egy szar amivel
> ezt vagy azt nem lehet megoldani. (Es akkor meg egyszer: en admin oldalrol egy kicsit mas felol nezegettem.)

Megoldani meg lehetett, csak iszonyatos szívások árán.

FreeTOAD is van, ha jól tudom (egy cégnél jogtisztán maximum 5 munkahelyen használható) - én napi munkában (Oracle IAS alá fejlesztéshez) tizensok évvel ezelőtt használtam, de az a szó, hogy "kényelmes" vagy hogy "mindentudó" messze nem írja le azt, hogy mennyire jól összerakott eszköz.

https://www.toadworld.com/products/downloads?type=Freeware&download=toa…

Nekem az a "kedvencem", hogy a varchar2 az üres stringet NULL-ként tárolja, a NULL értéket tartalmazó sorok pedig nem kerülnek be az adott oszlopra épített indexbe, és nyilvánvalóan nem is lehet egyezést feltételként úgy megadni, hogy col = 'valami', mert ha a valami pont üres string, akkor sosem lesz igaz a feltétel...

Hát pont ez az, hogy a NULL az nem érték, hanem állapot, nem egyenlő semmivel, akkor beszúráskor mégis hogy lett hirtelen a '' egyenlő NULL-lal? Ki kérte, hogy feleltesse meg önhatalmúlag? Az ember arra számít, hogy a mezőben üres string van és a "XYZ"='' nem fog működni, mert nem az van benne. Nyilván, ha az ember tudja, hogy ott nem üres string, hanem NULL van, akkor IS NULL-lal fog vizsgálni, de itt az volt a szívás, hogy nem tudtuk, hogy az Oracle ezt így arbitrálisan kicseréli...

Ez már szoftver-archeológia: az Oracle még a kezdetek kezdetén hozta meg azt a tervezési döntést, hogy az '' az VARCHAR/VARCHAR2 mezőkben "NULL"-ként tárolódik. A szabvány később írta elő a megkülönböztetést, az Oracle-nek ekkor kellett dönteni, hogy vagy tökönrúgja az addigi felhasználóit, vagy bevezet egy paramétert, ami a két működés között vált, vagy pedig hagyja az egészet, és ezt a szabványtól való eltérést meghagyja.

Az a tervezési döntés egy orbitális hiba volt. Utána kompatibilitási okokból ragaszkodni hozzá évtizedeken át - miközben az egész világ szembement vele az autópályán, ez azért már gyakorlatilag microsoftos magasságokban van.

Számtalan megoldás lett volna ennek a szarságnak az eltüntetésére.