HOVD 2003-2018: Még egy adag grafikon

 ( traktor | 2019. április 3., szerda - 19:37 )
  • 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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

leginkább a kedvenc desktop környezetre gondolok, ahol 2dik lett

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...

ezek szerint lehetne máshogy is generálni. amúgy ne vedd rossz néven, szerintem krva érdekes amit csinálsz, és tökjó. de az érdelne, elég kézimunka lehet, ahogy összepasszintod a kategóriákat, mert mindig változnak

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?!

Mert kikerült a főoldalra.

--
trey @ gépház

Ja, koszi. Csak en a blogok kozott neztem es ott is feljott az elejere. Ami lesz meg:
- kedvenc video lejatszo (mar kint van)
- kedvenc smartphone OS (mar majdnem kesz)
- kedvenc forditott/script nyelvek
- kedvenc szovegszerkeszto (talan)

Majd sorban.

--
trey @ gépház

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

Mert csak ahhoz ért és Stockholm-szindrómás.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene

Mert ezek a szavazások nem a tényleges kedvencekről szólnak. A helyes kiírás az lenne, hogy "Melyiket ismered az alábbi (insert category name) közül?", vagy "Melyiket használtad már az alábbi (insert category name) közül?".

Jajj dehogy! Akkor nem lehetne minden kategoriaban szavazni. De itt teljesen tudatlanul is lehet! :)
Es ezert pont jo nev a "kedvenc". Lehet kedvenc allatod a grizli medve, es ehhez meg talalkoznod se kell vele. Sot, jobb is, ha nem.

Nem vagyok egy adatbazis guru, de dolgoztam par evig Oracle DB-vel, es bar nem jelolnem kedvencemnek, volt par ugyetlensege, de nem koveznem meg aki azt valasztja. Mondjuk ugy, hogy nem valt ki belolem indulatokat, ha visszagondolok ra. Neked mi faj benne igazan?

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:

Idézet:
"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.

"- Nem volt hozzá normális DB kezelő tool, de szerencsére az Adminer Oracle-t is tud." Brekeke. Akarom mondani TOAD. Fejelszteni, maszírozni nagyon jó eszköz.

Kösz a tippet, tényleg fasza cuccnak tűnik és ahogy nézem már MySQL-t/PostgreSQL-t is tud, szóval még használni is tudnám mire (lévén Oracle-lel azóta nem volt dolgom), csak sajnos ahogy nézem, súlyos lóvékba kerül.

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=toad-for-oracle

Ez csak windows alá van?

Igen, de bőven megéri ezt a kompromisszumot.

Hátha megy WINE alól, mert windózom az nincs. Kösz még egyszer a tippet.

Szerintem te rohadtul nem értettél hozzá :)

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...

A NULL az NULL, az üres string meg üres string. Ha nem raktál az adott oszlopba semmit, akkor az NULL, amire nem egyenlőséggel, hanem az 'IS (NOT) NULL' feltétellel kell vizsgálni.
Vagy félreértettem valamit?

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.

És a paraméter túl bonyolult vagy drága lett volna? Egyébként függetlenül attól, hogy szabvány előtti a viselkedés, ez már alapból sem tűnik egy túl bölcs dolognak; mégis mi indokolta? Valami nullpointer mágia PDP-11-eseken?

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.

Azt, hogy ha üres stringet teszel az oszlopba, akkor valójában NULL kerül oda. Ergó nem tud a rendszer üres stringet kezelni.

Tényleg, ezt már el is feljtettem, pedig mekkorát szoptunk ezzel is, amíg rájöttünk...

Nem én, és mert egy idióta.

Bennem ugyanez fogalmazódik meg a Postgre-vel kapcsolatban, számomra iszonyat kényelmetlen a kezelése.

--
openSUSE 42.2 x86_64

Ahogy nézem, én más szempontból néztem a dolgot, mint ti, mert én fejlesztőként néztem az Oracle DB-t, nem adminként és fejlesztőként rémálom volt. A PostgreSQL-t nem tudom, hogy mire érted, hogy kényelmetlen a kezelése, mindenesetre fejleszteni élmény alá.