Bővített JavaScript- és JSON-támogatással jön az új Oracle 21c
2021-01-15T13:15:04+01:00
2021-01-17T14:03:33+01:00
2022-07-20T12:01:49+02:00
  • Egy profinak, akit az adatbázishoz mernék engedni, a tanulás mennyi idő?

    Értelmesen szemlélve a dolgot igazad lenne. De...

    Általában az hogy csak profit engednek az adatbázishoz, sajnos nem szokott kritérium lenni, mert akkor soha nem találnának embert olcsón. Innentől kezdve az, hogy majd beletanul, az egyáltalán nem garantált.

    A menedzserek legkevésbé sincsenek tisztában azzal hogy melyik technológia mennyire bonyolult, sem pedig hogy az embereik vagy a jelentkezők mennyire képesek egy adott feladat ellátására. Ezért a menedzserek általában szeretik a checklisten kipipálni, hogy ehhez vagy ahhoz a CV-jük szerint értő embereik vannak, lehetőleg minél olcsóbban. Ebben a Javascript az adatbázisban egy elég nagy segítség.

    Az Oracle adatbázist nem a fejlesztők szokták kifizetni, ergo a feature-ökben is a menedzserek is meg vannak célozva.
    Mutasd a teljes hozzászólást!
  • Nem azt mondtam hogy nehéz megtanulni, hanem hogy kevesen voltak akik hajlandóak voltak. 

    Egy profinak, akit az adatbázishoz mernék engedni, a tanulás mennyi idő?
    Két nap?

    Ha érti a DB-t és az SQL-t, programozik valamiben tapasztalattal, akkor az első lépések (copy-paste, egyszerű probléma) mennyi idő? Félóra?
    Mutasd a teljes hozzászólást!
  • Nem is azért van, hogy egy frontendes írja a tároltakat

    Én azt mondanám, hogy erre IS fogják használni.
    Mutasd a teljes hozzászólást!
  • A tárolt eljárásokkal nem az a baj, hogy a nyelvet nehéz megtanulni

    Nem azt mondtam hogy nehéz megtanulni, hanem hogy kevesen voltak akik hajlandóak voltak. A nagyobb cégeknek így megvan a lehetőségük, hogy olyanokat is felvegyenek erre a munkára, akik nem voltak hajlandóak.

    hanem az, hogy néha egy-egy dolgot úgy lehet megoldani, hogy a lábaddal vakarod meg a füledet.

    Hát, bizonyos dolgok a script nyelv és az SQL hülyeségeiből adódnak, bizonyos dolgok nem.

    Viszont azt kétlem, hogy ezzel a cuccal ha egy frontendes javascript bajnokot leültetsz egy db script elé, sokat segít rajta hogy ismeri a javascript nyelvet.

    Ha a db script js-ben lesz írva, akkor több esélye és hajlandósága lesz.
    Mutasd a teljes hozzászólást!
  • Nem is azért van, hogy egy frontendes írja a tároltakat, hanem hogy a megírt tároltakban meg tudj hívni JS kódot, amit egy GraalVM futtat. Vagyis hogy a JS-ben írt üzleti logikád az adatbázis adta biztonság, konzisztencia, teljesítmény stb mellett hajtódhasson végre, amiből hívhatsz más PL/SQL SP-ket is akár, vagy sima SQL-t. Converged database a kulcsszó.
    Mutasd a teljes hozzászólást!
  • Pont a backend js developerekre lőnek. Nem új piacot szerezve, hanem hogy a nodejs kollégát importáló cég ne váltsa le (részben sem) az adattarolo réteget valami másra. 
    Kicsiben ugyanez: mysql csapat nem telepít mongodb-t ha az a pár tábla befer egy JSON típusba is mysql alatt.
    Mutasd a teljes hozzászólást!
  • A tárolt eljárásokkal nem az a baj, hogy a nyelvet nehéz megtanulni, hanem az, hogy néha egy-egy dolgot úgy lehet megoldani, hogy a lábaddal vakarod meg a füledet. Viszont azt kétlem, hogy ezzel a cuccal ha egy frontendes javascript bajnokot leültetsz egy db script elé, sokat segít rajta hogy ismeri a javascript nyelvet.
    Mutasd a teljes hozzászólást!
  • 1. Nem mindegy overhead szempontjából hogy egy külső "script interpretert" kell hívogass tárolt eljárás hívásonként, vagy pedig a DB engine egy függvényhívás költségét költi csak overhead-ként a tárolt eljárás meghívására. Az Oracle rengeteget szokott költeni az ilyen optimalizálásokra, hogy még versenyképesebbé tegye az Exa* családot.

    Ez kb. az adott adatbázis saját belső tárolt eljárás futtató nyelvének szintjére viszi le a költségeket.

    én nem igazán tudom elképzelni, hogy ezek hogyan tudnának hatékonyabbak lenni a pl/sql vagy plpg/sql-hez képest.

    Ahhoz képest nem. De jóval többen ismerik a Javascriptet mint a plsql-t vagy a plpgsql-t. Könnyebben találnak embert.

    aminek viszont szerintem lehet itt haszna, az az R.

    Nem tudom. Nekem az jön le az utóbbi években a cikkekből, hogy az R nem igazán terjed el annyira mint hype-olták. Lehet hogy tévedek.
    Mutasd a teljes hozzászólást!
  • De ez a hajó elment, ma már nem nagyon írunk komplex logikákat SP-be, azt az adatelérési réteg felett lévõ üzleti logikába tesszük.

    Azért annak van értelme, ha egy leválogatott adathalmazra be tudsz küldeni egy programot/rutint, ami azt feldolgozza helyben, és meg tud hívni project rutinokat vagy bármi nem RDBMS kódot. Ilyen szempontból a javascript egy elég kézenfekvő választás.

    Annál is inkább, mert Pl. azure alatt amúgy is ms-sql-t, esetleg postgrest vagy mysql-t használunk, nem Oracle-t. Ráadásul ma már sok minden nem is SQL-be megy hanem Cosmos-ba, Redis-be, vagy más NoSQL-be.

    Azért az Oracle messze a legnépszerűbb RDBMS. Főleg ott, ahol rengeteg adat van. Semmiképp nem a market share oldaláról fognám meg, hogy van-e ennek értelme. Ráadásul sok nosql ad SP-hez hasonló funkcionalitást, akár valamilyen script nyelv támogatással. Redis pl emlékeim szerint lua-val. Ahogy egyébként SQL-t is többen adnak.

    A többi feature is nagyon jónak tűnik. A JSON támogatás, blockchain táblák, meg a perzisztens memória támogatás elég fontos mérföldkövek.
    Mutasd a teljes hozzászólást!
  • Nem volt, de lehetett volna. A T-SQL egy elég béna kacsa ha bármilyen kicsit is komplexebb logikát akarsz benne megvalósítani. Ha akkor, amikor a linq megszületett, a MS picit frissíti ezt a dolgot, és olyan megoldást csinál amivel linq-val közvetlenül - vagy legalábbis nagyon vékony absztrakciós rétegen át - érheted el a táblákat, temp táblákat, stb, akkor lett volna mit keresni a dologgal.

    De ez a hajó elment, ma már nem nagyon írunk komplex logikákat SP-be, azt az adatelérési réteg felett lévõ üzleti logikába tesszük. Aminek meg van az a nem kis elõnye is, hogy civilizált módon lehet unit / funkcionálisan tesztelni. És csak az megy sp-be, ami már végképp elkerülhetetlen sebesség szempontjából.

    Ezért sincs szerintem túl nagy jelentõsége a javascriptes oracle-nek. Annál is inkább, mert Pl. azure alatt amúgy is ms-sql-t, esetleg postgrest vagy mysql-t használunk, nem Oracle-t. Ráadásul ma már sok minden nem is SQL-be megy hanem Cosmos-ba, Redis-be, vagy más NoSQL-be.
    Mutasd a teljes hozzászólást!
  • A MS-SQL-ben is volt egy idõben olyan gondolat, hogy .NET-ben lehessen tárolt eljárást írni, csak MS-éknek sikerült elég vacakul implementálni, ezért aztán nem annyira lett sikeres a dolog. Pedig alapvetõen nem lett volna az rossz, ha nem úgy oldják meg ahogy.

    Nem feltétlenül az volt a cél, hogy általános SP-ket írjál benne. Én pl egy nagy cégnél az Apple alőfizetők havi hosszabbításait kezelő, az Apple felé egy JSON szerű protokollon (mert miért lenne szabványos az Apple...) kommunikáló eljárást írtam benne. Pont jó volt a cégnek, hogy az SP meghívásával kezelte ezeket az előfizetéseket. Szóval leginkább arra jó, hogy a külvilág felé tudj DB-ből kommunikálni, vagy portolj valamilyen helyi ketyerével kommunikáló eljárást.
    Mutasd a teljes hozzászólást!
  • valóban nem ugyanaz a postgresql-ben a python, mint az oracle-ben a javascript:)

    (mellesleg van külsőleg fejlesztett java meg javascript a postgreshez)

    én nem igazán tudom elképzelni, hogy ezek hogyan tudnának hatékonyabbak lenni a pl/sql vagy plpg/sql-hez képest.

    aminek viszont szerintem lehet itt haszna, az az R.
    Mutasd a teljes hozzászólást!
  • A MS-SQL-ben is volt egy idõben olyan gondolat, hogy .NET-ben lehessen tárolt eljárást írni, csak MS-éknek sikerült elég vacakul implementálni, ezért aztán nem annyira lett sikeres a dolog. Pedig alapvetõen nem lett volna az rossz, ha nem úgy oldják meg ahogy.
    Mutasd a teljes hozzászólást!
  • Bár nem gondolom, hogy sokan tolonganának, hogy js-ben írják a procokat.
    Postgres-nél is van lehetőség pythonban is írni tárolt eljárásokat, de tudtommal még mindig a plpgsql az uralkodó nyelv ott is.

    Azért az nem egészen ugyanaz.

    Az Oracle-nél már elég régen foglalkoznak azzal hogy elég szorosan beintegráljanak nyelv futtató motort tárolt eljáráshoz (már 8i-ben is volt Java), biztos vagyok benne, hogy jóval hatékonyabb lesz mint a Postgres-es megoldás.

    Gyanítom, hogy ha ezt most marketing szinten is ennyire elkezdték nyomni, akkor a Javascriptes tárolt eljárások legalább annyira, vagy még hatékonyabbak lesznek mint a PL/SQL-es megfelelőik.
    Mutasd a teljes hozzászólást!
  • Értem persze, de ez nekem nagyon környezet idegen gondolat.

    Bár nem gondolom, hogy sokan tolonganának, hogy js-ben írják a procokat.
    Postgres-nél is van lehetőség pythonban is írni tárolt eljárásokat, de tudtommal még mindig a plpgsql az uralkodó nyelv ott is. 

    <off>
    mondjuk egyszer tényleg jól jött, hogy lehetett használni egy python package-t egy function-höz :)
    </off>
    Mutasd a teljes hozzászólást!
  • Hát, nagyvállalatoknál, bankoknál rengeteg Javascript fejlesztő van...

    Ha ezek PL/SQL helyett JS-ben írhatnak tárolt eljárásokat, az azért hidd el elég gyorsan el fog ott terjedni...
    Mutasd a teljes hozzászólást!
  • Szerintem azért nem tolonganak tömegek, hogy js-el szeretnének Oracle-ben dolgozni. De JSON feldolgozáshoz jól jöhet még
    Mutasd a teljes hozzászólást!
abcd