Ha nem lenne kulon parancs, hogya oldanal meg egy atutalast?
update szamlak set osszeg=osszeg-100 where user=1 update szamlak set osszeg=osszeg+100 where user=2
ha azonnal ervenyre jut a modositas, akkor lesz olyan pillanat, amikor senkinel nincs a penz! mi van ha ekkor megy el az aram? vagy ekkor adjak ki a select sum(osszeg) from szamlak utasitast?
(az mindenesetre megdöbbentő a számomra, hogy pontosan az a furcsa,ha magától is frissül egy tábla. Hihetetlen, hogy erre külön paracs kell. Nem az én világom, na)
... miután utána néztem a 'commit' utasításnak, megértettem a kérdést. Nem, nem használtam ilyet, most viszont hogy használok, a frissülés megtörtént, köszönöm!
Egy gyakorlati apróság: Tfh, a PL/SQL developerben az SQL Window-ba insert parancsokat osztogatok. Aztán lekérdezem a tábla tartamát és nem látom a frissülést. Rányomok a frissít gombra, aztán lekérdezek, még mindig nem frissül. Kicsit dolgozgatok mást, aztán megint megnézem a táblát: már frissült a tartalma. Most akkor mikor frissül?
create table movie (moviename varchar2(30) constraint pk_moviename primary key, showtime varchar2(30), ... ); insert into movie ('Terminator III', '3pm'); insert into movie ('Terminator III', '5pm'); Oracle returns error
merge into movie M1 using movie M2 on (M2.moviename = M1.moviename and M1.moviename = 'Terminator III') when matched then update set M1.showtime = '5pm' when not matched then insert (M1.moviename, M1.showtime) values ('Lord of the rings', '3pm');
Érdekes... mondjuk azt nem látom hirtelen, hogy mire kellett itt az M2.
Szuper. Akkor, ha jön egy új dátum, akkor először be kell illeszteni mint új value a dátum oszlopba. Azután jöhetnek azok az adatok, amiből egy dátum, város párhoz csak egy lehetséges. Ezeket a replace függvénnyel nem tudom berakni insert helyett?
Amit írsz, az elég izzadtságszagúnak tűnik, de én elhiszem neked, hogy nem lehet elegánsabban. Akkor rossz hírem van: ha nem lockolod az egész táblát (ami kb olyan, mint leveseskanállal enni a tölcséres fagyit), akkor elméletileg az is lehetséges, hogy sem az INSERT sem az UPDATE nem lesz sikeres, mivel közben valaki más törli a rekordot.
Szóval, nincs remény, nincs vmi ilyen: insert OR update? Keresgéljél a kézikönyvben, hátha fejlődött az SQL mióta én tanultam...
Akkor viszont mire jó a primary key, vagy az unique megszorítások? A 'primary key' olyan mint a 'uniq' és az 'index' együtt, a 'uniq' pedig azt akadályozza meg, hogy ugyanahhoz a város+dátum párhoz két (vagy több) rekord legyen.
Eddig azt gondoltam, hogy arra, hogy az adat frissítést értelemszerűen automatizálja: - ha nincs még olyan konstellációjú adat, akkor csinálok egyet, ha van, felülírom. Ha lenne ilyen 'INSERT or UPDATE' utasítás, akkor bizonyára így működne.
Oké, ha nincs ilyen, de akkor meg minek szorítunk meg, hacsak azért nem, hogy hibaüzenetet küldjön, ha többszörös adat akarna bekerülni a táblába? Azért.
Város-dátumonként. Amit írsz, az elég izzadtságszagúnak tűnik, de én elhiszem neked, hogy nem lehet elegánsabban. Szóval, nincs remény, nincs vmi ilyen: insert OR update? Akkor vgiszont mire jó a primary key, vagy az unique megszorítások? Eddig azt gondoltam, hogy arra, hogy az adat frissítést értelemszerűen automatizálja: - ha nincs még olyan konstellációjú adat, akkor csinálok egyet, ha van, felülírom. Oké, ha nincs ilyen, de akkor meg minek szorítunk meg, hacsak azért nem, hogy hibaüzenetet küldjön, ha többszörös adat akarna bekerülni a táblába?
Üdv, ismét van egy kemény problémám, legalábbis a magam perspektívájában.
Fix számú városhoz kell naponta egy adatot rögzítenem. Azt szeretném, hogy ha már van érték, írja felül a korábbi értéket, de ne az egész táblát helyettesítse, csak azt az egy rekordot: [dátum, város_index, érték], esetleg csak az értéket. tehát minden város_index,dátum konfigurációhoz max egy adat tartozzon. A dátumok ugyanakkor folyamatosan nőnek ugye.
Abből, hogy egy dátum-város párhoz csak egy adat létezhet, úgy érzem, tudnám használni primary_key-ként őket, csakhogy a dátumaim folyamatosan nőnek és amennyire olvastam a primary_key-eket nem is nagyon lehet változtatni. Ha viszont nem használom ki az rekordok egyediséget, akkor megtörténhet, hogy több adat kerül egy város_index, dátum párhoz, és akkor a bekerülés idejét is kéne tárolnom, hogy tudjam, melyik a releváns adat, ugye az újabb... ez meg marha nagy, lényegében felesleges adat tárolása/figyelése.
A harmadik lehetőség, hogy túlbonyoolítom és van pofon egyszerű megoldás. Hát ezért írok.
Ingres nekem is a szivem csücske, BTW ők találták ki tudtommal a hash-joint-t és CBO-t. Mivel Oraclenél tényleg nagyon jól sikerült a B*index és az RBO, jóval később mozgolódtak ilyen tereken is, és implementálták (Oracle 7-ben), kezdetben iszonyatos rosszul /egyik sem nyitott sikertörténetként, finoman szólva/.
Már-már közhely, hogy az IT tele volt/van okos jó ötletekkel, amik különböző életciklus-fázisokban kinyíródásra itéltetik az évek során. Mondjuk szerintem nem csak markentingen múlik, hanem vannak egyéb finomságok is, és meglehet például az is, hogy az Ingreses nemprogramozók is hibáztak, annó.
>Majd vesznek erősebb vasat
Na ebben a témában az Oracle is meglehetősen élenjár -> lásd például analizálás. ;)
>Az XML kicsit olyan, mint az atomerőmű. Lehet szeretni, lehet utálni, de hamarosan tarolni fog, és nem boldogulunk nélküle.
Mint kiderült, szerintem is nagyon tuti-dolog (más kérdés, hogy nem trivi a feldolgozása). És szerintem már most tarol, hisz a legkopaszabb config-file is hova tovább xml.
Hogy az XML iszonyat drága az teljesen nyilvánvaló. Ezt a szakma tudja 2 éve az adatbázisokkal kapcsolatban, és még régebben pl az XSLT-vel kapcsolatban. De a marketing mindent elsöpör. Nem akarok ezen a fórumon másik RDBMS-t fényesíteni, de az Ingres teschnológiában és user interface-ben (programozói) messze kimagaslott a mezőnyből, és mára csak egy szép emlék, mert szakemberek foglalkoztak vele, nem marketingesek.
Úszni az árral, a buzword-öknek megfelelően programozni, egyfajta gerinctelenség, de kifizetődő. Majd vesznek erősebb vasat. Ha kliensen lehet vista, akkor a tucatnyi SUN server szemünk sem rebben.
Csak senki meg ne lássa, hogy mozog egy Mac, vagy mit tud egy debian azon a szutyok pentiumon, amit már kidobtak, mert nam ment rajta a vindóz. :)
P.s.: Az XML kicsit olyan, mint az atomerőmű. Lehet szeretni, lehet utálni, de hamarosan tarolni fog, és nem boldogulunk nélküle.
Egyáltalán nem bántasz meg, hisz igazad van. Valóban lamer vagyok, de pont a lényeget másképp látom: Épp azért beszéltem rá őket, mert nem értek hozzá. Másképp: Fizetnek nekem azért, mialatt tanulom. Így egész jól hangzik, nem?
Ha viszont így vesszük, akkor meg tök igazad van, és egyből másképp látszik a dolog! :)
hogy odacipelek egy csomó adatot a kliensre, és ő ott egy algoritmussal feldolgozza, aztán kibőki, hogy 5 ! Az általam szebbnek tartott megoldás során az algoritmust viszem az adatokhoz, és a drótba már csak az 5 kerül.
>>>>>>>>>>>>>>
Az elv helyes (minimalizálni a hálózati forgalmat), de az esetleges rossz implementációért nem feltétlen kell mindig a ref cursort okolni, szvsz... ;)
>>>>>>>>>>>>>>
Ha ref cursort használsz, könnyedén elképzelhetünk olyan SELECT-et, amiben csapatnyi UNION van, kazal táblán operálnak, egyenként is sok k-nyi a WHERE.
>>>>>>>>>>>>>>
Speciel nekem ez a lehetőség éppen hogy tetszik. :o) Nyílván OLTP-alkalmazásnál lehetnek problémák az ész nélküli felhasználásával. De ez megint nem a ref cursor módszernek a hibája. Másfelöl rossz kódot könnyen lehet írni Oracle-ben ref cursor nélkül is. ;)
>>>>>>>>>>>>>>
Ezt a tömböt procedurálisan egyszerű feltételek mentén esetlegesen végrehajtott egyszerű SELECT-ekkel esetleg töredék idő alatt feltölthető.
>>>>>>>>>>>>>>
Igen ezt senki nem vitatja. Én csak azt mondom, hogy a konkrét szituban több mindent kell mérlegelni. És az egyes konkrét esetektől függő lokális specialitásokról még nem is volt szó... ;)
>>>>>>>>>>>>>>
ora_in_server_side ( p_in IN XMLType, p_out OUT XMLType );
>>>>>>>>>>>>>>
Egy-két éve szinte teljesen igazat adtam volna neked. Ma már úgy látom /tapasztalat alapján/, hogy az XML-feldolgozás nagyon költséges /mert rendkívül erőforrás igényes és a létező legdrágább rdbms-oldali a konkrét esetben/ és épp ezért mindennél óvatosabban kell vele bánni. A konkrét Oracle-funkcionalitás tényleg szivet melengetően gyönyörű önmagában, de vannak jelentős járulékos költségei a használatának. BTW: a compress-decompress sincs ingyen és ráadásul szintén a drága processzor (+memória) oldalon.
Azt akartam mondani, hogy a ref_cursor jellemző felhasználása, hogy odacipelek egy csomó adatot a kliensre, és ő ott egy algoritmussal feldolgozza, aztán kibőki, hogy 5 ! Az általam szebbnek tartott megoldás során az algoritmust viszem az adatokhoz, és a drótba már csak az 5 kerül.
A másik - általunk boncolgatott szempot - a tárterület kezelése, végül is a ref_cursor egy memória tömbre mutató pointer, csak az interface-e más. :) Ha ref cursort használsz, könnyedén elképzelhetünk olyan SELECT-et, amiben csapatnyi UNION van, kazal táblán operálnak, egyenként is sok k-nyi a WHERE. Az optimizer már messziről feltartja a kezét, és leszáll a csendes éj, mire elkezdenek belőle csordogálni az adatok. Ezt a tömböt procedurálisan egyszerű feltételek mentén esetlegesen végrehajtott egyszerű SELECT-ekkel esetleg töredék idő alatt feltölthető.
És a mostani divatnak megfelelően mit szólsz ehhez:
ora_in_server_side ( p_in IN XMLType, p_out OUT XMLType );
Szerintem csinos. Ha ezt az egyet megírom, minden kliens igényt kiszolgálhatok vele. :) A paraméter persze lehet BLOB, ami úgy áll elő, hogy XMLType -> CLOB -> compress -> BLOB. Nem vonzó ?
Maximálisan tiszteletben tartva a véleményedet, eltérő vélekedést fogalmaznék meg.
>...elválasztod a guit az üzleti logikától...
Igen-igen. A GUI-t (megjelenítést) igenis el kell választani az üzleti logikától. De az üzleti logika sem egy egységes monolitikus tömb (adat+folyamat). Továbbá attól még az adatokat el kell érni és ettől még a ref cursor technika szerintem nem feltétlen kidonbandó cucc; azaz vizsgálni kell egyéb szempontokat, szvsz
Szerintem két témáról van szó, amit érdemes külön tárgyalni:
1. Adatelérés
Ha a userek nem egyetlen standalone alkalmazáson keresztül érik el az adatbázis-táblákat, hanem például direktben is, akkor következő fejlesztéskor igen nehéz megmondani / felmérni mivel jár a struktúra-módosítás, miket kell majd letesztelni, hogy a fejlesztés legalább transzparens / komaptibilis legyen a userek életére. Azaz ha nincs interface akkor következésképp nehéz alatta implementációt váltani (OO-paradigma alapján). Ha van ref cursoros tárolt eljárás (SOA-világban mondhatjuk alkalmazás-szintű RDBMS-szolgáltatás) akkor elfedhető a userek elöl a konkrét tábla-struktúra, és ha egy adatot valami miatt már máshonnan kell venniük, nem nekik kell tudniuk erről a vonatkozó infóról.
2. Interface
>Ha a mai divatnak megfelelően tervezel architektúrát, interface-eket
Kérdés ez alatt mit értünk. Én két dolgot tudok elképzelni: adatszintű és szolgáltatásszintű integrációt (ha az adatok több adatbázisban vannak). Adatszintű integráció során egyik adatbázisból dblinken keresztül matatjuk a többi adatbázist (nekünk kellő adatokért). Ez szerintem ma már nem követendő út. Marad a szolgáltatás szintű integráció, amikor pl.: szabványos elemi tárolt eljárásokon keresztül érjük el az adatokat /amiket persze lehet aggregálni magasabb szintre, akár Java-t is bevetve/. akkor vagy a programozó allokál tárterületet magának és tölti fel /amit te preferálsz/, vagy ezt rábízza az rdbms-re (select kiadásával), majd a dinamikusan kialakult resultsetre pointert ad vissza, amit mindenki tud használni, tetszőleges adtmennyiségre: leszámítva persze a másik instance-t ;) Amire ekkor érdemes törekedni, hogy az instance-ok autonómok legyenek (minél kevésbé függjön belső működésük más rendszerektől), és lazán csatolódjanak (pl.: aszinkron csatolású kopasz file-interface, vagy tőlem akár MOM/=Message Oriented Middleware/) a többiekhez. A dblink ugye pont nem ilyen (az kötelező online szinkron-kapcsolat, a világ leggyengébb performanciájával)
A műlt csökevénye. Én speciella sosem szerettem, és mindenkit igyekeztem lebeszélni a használatáról. Ha a mai divatnak megfelelően tervezel architektúrát, interface-eket, szépen elválasztod a guit az üzleti logikától, akkor abban nincs helye ref_cursornak. Szerintem olyan beidegződés, ami abból az időszakból maradt meg, amikor a feldolgozó programok futását tucatnyi listázó program követte, ami többféle rendezettségben ontotta a papír hegyeket.
ebbol az a legviccesebb ha a user altal a UI-on beirt keresofeltetel is siman bele lesz konkatenalva az sql-be. peldat inkabb nem irok mi mindenre jo a dolog.
Az általam rendkívül utált ref_cursor-okat ki lehet cserélni VARRAY-ra, ha nem néhány milliós az eredmény tábla. Ennek a VARRAY-nak a feltöltése procedúrális, esetenként sokkal hatékonyabb lehet, mintha egy SELECT-be kell begyömöszölni mindent. Ha jól emlékszem a C-nek volt valami nyűgje a VARRAY-okkal. teljes méretben tologatta a dróton akkor is, ha a deklarált félmillió sor helyett csak 1-2 sor van benne. Java esetében ilyet nem tapasztaltam. Már ha rossz példa kell. :)
Több csúnya Pro*C-s projektet láttam. Ami performanciát egyéb előnyt a C-vel nyertek, azt elvesztették (bőségesen) RDBMS és/vagy application-maintenance oldalon. Ha van kedved, írjál légy szíves néhány példát, a rossz megoldásokból mindig lehet tanulni... én például azt utálom, amikor 'nincs kedvük' a népeknek bind-változót használni egy WHERE-feltételben vagy INSERT-ben, hanem szépen az sprintf-fel literálként rakják bele az aktuális értéket a dinamikus SQL-be... az ilyeneknek azután beszélhetek a 'parsing optimalization'-ról...
Szerintem nincs ultimate tökéletes megoldás. A dolog sava borsát a részletek adják mind eset (te portolhatósági követelményed) szinten, mind szempontok+azok súlyozása szintjén, várhatóan szubjektiv tényezőkkel is megspékelve. Én arra gondoltam eredendően, hogy új projektek statisztikailag nem relevánsan nagyobb mennyiségben választják a Pro*C-t. De ez inkább csak érzés részemről, mint objektive alátámasztott konkrét információ.
Azért két adalék, hogy ne csak bullshiteljek... ;)
- Java is elérhető (minimum)
- Több csúnya Pro*C-s projektet láttam. Ami performanciát egyéb előnyt a C-vel nyertek, azt elvesztették (bőségesen) RDBMS és/vagy application-maintenance oldalon. Igaz mindez régebben volt: azóta például a hazai Oracle (és IT-s) kultúra is sokkal mélyebb megalapozottabb lett Magyarországon (ahogy én érzékelem).
