Szia tnsname.ora. Köszönöm a gyors és főleg használható választ. Szerencsére az adatbázisunk verziója 9i, úgyhogy utánanézek az Általad vázolt lehetőségeknek. Remélem a Neten találok elég infot a dologhoz. Köszi még1x. Üdv, Márk
A saját tapasztalatomra hagyatkozva gondolom, hogy a role-on keresztüli jogosultság lesz a gond. Az mondjuk nem derült ki pontosan, hogy már a procedure fordítása sem sikerült, vagy csak futtatáskor volt hibaüzenet? Utóbbi esetben valóban máshol kellene keresni a problémát.
>ha azt mondanátok, hogy létezik megoldás, mert szerintem nemigen,
Ne légy pesszimista... ;)
Ha az adatbázis verziója minimum 9i, akkor van egy speciális adatszótárnézet V$SESSION_LONGOPS és abban egy TIME_REMAINING mező... Csodákat ne várj, de az idő haladtával, a végrehajtás befejeződéséhez egyre közelebb kerülve egyre pontosabb lesz az érték... Az mondjuk hátránya a megoldásnak, hogy időközönként le kell kérdezni az értéket, ami szintén erőforrásigényes...
http://www.ss64.com/orav/V$SESSION_LONGOPS.html
Ha szeretsz sokat programozni le lehet tárolni a kritikus sqlek végrehajtási idejét és aztán azt lekérdezve tudsz csíkot húzni... Minél gazdagabb körítéssel (rekordszám, párhuzamosan aktív userek száma stb.) tárolod e segédadatokat - időben visszafele minél hosszabb idősorban; annál precizebb lesz a csíkhúzásod...
Sziasztok! A következőben kérném segítségeteket: adva van egy Linux alatt futó Oracle Application Server és ezen egy több milliós rekordszámú, pár száz táblából álló adatbázis. Weben keresztül végzünk lekérdezéseket XP-s kliensekről, és némelyik igen összetett, noha csak viszonylag egyszerű SELECT-eket tartalmaz. Ez a lekérdezés-tömeg néha a 10 percet is meghaladja. Szerintetek létezik-e arra valamilyen megoldás, hogy ha a user elindítja a lekérdezést egy FORM SUBMIT-jára kattintva, hogy egy indikátor visszajelezzen, hogy mennyi a becsült hátralévő idő a lekérdezés befejezéséig? Tehát, hogy egyértelműbb legyen a kérdés: a webböngészőben kellene valami számláló, vagy futó csík, ami viszonylag pontosan jelzi, hogy mikorra várható a böngészőben a lekérdezés eredménye. (Bocsi, ha triviális lenne a kérdés; nem értek a PL/SQL-hez, Oracle adatbázisok kezeléséhez. Webfejlesztő vagyok, de Oracle-vel eddig nem találkoztam.) Nekem az is nagy segítség lenne, ha azt mondanátok, hogy létezik megoldás, mert szerintem nemigen, vagyis eddig nem sikerült rájönnöm, hogy hogyan lehetne a böngészőt rávenni arra, hogy egy lekérdezés állapotát megjelenítse. Köszönöm a válaszotok!
Szia, 1.pontosan erre gondoltam. De ezt az xml-t, vagy bár mi mást objektumot beletehetnéd egyetlen mezőbe. De az erre a mező-re írt funkcióidat akkor se tudod, egy az egyben beilleszteni az sql lekérdezőidbe, anélkül, hogy valami sebesség problémáról nem beszélnél. Sikeres objektum kezelő DB ma még nincs. Ha mégis lenne, szóljatok, mert kipróbálnám. Édesviz
Tárolt eljárásban csak direktbe grantolt objektum hivatkozható, role-on keresztüli nem. A jelenség legalábbis erre utal, hogy "simán" lefut, eljárásból nem.
Szerintem nem annyira tuti... a proci általában nem az aktuális felhasználó, hanem a procedure tulajdonosának jogaival fut; továbbá olyat is hallottam már, hogy role-on keresztül megadott jogok néha 'kevésbé érvényesülnek', mint a direktben megadottak.
Egy olyan problémám lenne, hogy van egy adatbázisom, amihez több felhasználó tartozik, és akikhez több tábla, procedure stb. tartozik...
TOAD-ot használok, és olyan gondom lenne, hogy az egyik felhasználó alatt írtam egy procedure-t amelyik adatokat nyer ki a saját ill. egy másik felhasználó tábláiból, de valamiért nem tud lekérdezést végezni, és az alábbi hiba üzenetet küldi:
PL/SQL: ORA-00942: table or view does not exist
De ha ugyanazt a lekérdezést lefuttatom ugyanazon a felhasználó alól az SQL Editorban, akkor hiba nélkül lefut....
Tehát a jogok tuti grant-olva vannak....
Ha valakinek van valami ötlete, bármi írjon, előre is KÖSZÖNÖM
Az XML eddig még nem említett másik nagy előnye a szintaktikai (file utolsó bitje is megérkezett-e) és némi szemantikai (filekonzisztencia)ellenőrizhetőség (pl.: típusmegfelelés)
1.a kérdezőnk válaszolt, a szétbontás altáblákra tetszett neki.
2.Tranzakcionális kezelés alatt azt értettem, hogy az adathalmaz on-line sokat változik, azaz nem lekérdezésről, hanem konkurrens adat változásokról van szó. Tehát lehet, hogy más eszközzel is meg lehetett volna azt a rendszert írni. Szeretném mindenkinek a figyelmét felhívni, a sima táblázatos modellen kivül, az ORACLE ad hierarchikus hozzáférést, prefix, és postfix fa bejárásra is. Ez pl a DB2 általam használt verzióiból, és a feladatomhoz természetesen hiányzott.
2. az xml adatstrukturáról annyit, hogy egy szószátyár, objektum leíró rendszer. Előnye, hogy rengeteg kész szoftver van a kezelésére, szabványosított adatcserét tesz lehetővé rendszerek, alrendszerek között. Hátránya, hogy lassú, processzor igényes. Amiből pedig a mostani munkámban látszólag elégnek kellen lenni. Tbájt méretü rendszer, 3-5 ezer online felhasználó, nagygépek, közepes szerverek sokasága, intranet alkalmazások. Édesviz
1. Én is azért kérdeztem a feladat méretére, mert anélkül meglehetősen problémás korrekt tanácsokat adni. Az is igaz, hogy ha a feladat megoldása már túljutott egy szinten, a kérdezőt (bocsánat, hogy most nem keresem vissza a nevét) valószínűleg nem érdeklik az elméleti megfontolásaink: neki most 1000 oszlop feletti táblára van szüksége. Mivel ez tudtommal view-ban sem megvalósítható, peche van. De a teljes újratervezésnél valószínűleg gyorsabb, ha több fizikai táblába tördeli a logokai tábláját és programból kezeli a sok "altáblát". Szegény kérdezőnek még nem volt ideje reagálni a válaszainkra, úgy elmerültünk a tervezési kérdésekben :)
2. Ha jól emlékszem, valami cégtörzs volt kapcsolatrendszerrel, meg ügyintézőkkel körítve. Emlékeim szerint hierarchikus adatbázisban volt, aminek az ilyen típusú dolgok igen jól mennek ugyebár. Többszáz felhasználó volt és természetesen tranzakcionálisan is használták, de jellegéből adódóan főleg lekérdezésre. A dolog régebben történt, még 8.1.6-ra ment a migráció, nem volt éppen trivi az 1GB lenyelése. De így is sokkal olcsóbban jöttek ki, mintha maradnak a régi platformon és mindenért keményen csengetnek. A mentését nem ismerem, de elképzelésem szerint akár offline is menthették.
>Ezert villantottam... Világos, persze. A "Lehet-e szükség 999 db oszlopnál többre is?" kérdés azonban egy önmagában is érdekes téma, a felmerült alapproblémától elvonatkoztatva is: a hozzászólásaimat már inkább ennek tükrében írtam...
Egyetertek abban, hogy minden problemat meg kell vizsgalni, es a megfelelo modellt megtalalni. Az aktualis problemara en is tuti valamilyen xml iranyba indulnek el.
Viszont az hogy a kerdezo erosen ragaszkodott az 1000+ oszlopos tablahoz, nekem arra utalt, hogy az alapok sincsenek meg neki nagyon. Ezert villantottam fel egy leegyszerusitett normalizalt format, hogy lassa mi a masik veglet.
>Mutassak peldat edifact atutalasi megbizas formatumarol? Elhiszem látatlanban is :o), és igazad is van. De talán ez is csak erősíti az állításomat, hogy nemcsak korrekten normalizált majd 'denormalizált' relációs adatmodellekről kell(ene) kizárólagosan beszélni. Nem feltétlen követendő példák kell legyenek sem a múltbeli sem a még 'tervezőasztalon' vagy legalábbis nagyobb arányú elterjedés elött lévő jövőbeli extremitások (100% pure OO, speciális dw-tervezési -> hogy még eddig nem említett további adatmodellezési módszertanokat is említsünk), és érdemes őket mélyebben megérteni akár a maguk képlékenységében is, bárminemű elvetés elött...
Azok a penzugyi rendszerek azert neznek ugy ki, mert kb a 70-es evekben vagy elobb terveztek oket, es alapvetoen gondolom cobolban implementaltak. Akkor meg max egyetemeken volt relacios adatbazis.
Sziasztok, lenne az 1000 oszlop, adabázis kezeléshez némi hozzáfűzni valóm:
1., az ezer oszlophoz: próbálkozott az a szervező egy Codd féle, harmadfokú normál formát kialakítani? Ha annyira struturált az adat, próbálkozott-e hierarchikus modellel, az is megy az ORACLE-ban? Végül is arról se volt szó hány sora van annak táblának.
2., Az a nagy gépes adatbázis, ami 40 Mb-ből 1 Gb lett az mi volt, és mi lett? Hány egyidejű felhasználója volt?, Szükség volt tényleg tranzakció kezelésre? Szükség volt adatkonzisztencia meg tartásra? Szükség volt inkrementális mentésre? Ennyi adat memória rezidensen befér a PC-be is, még az enyémbe is. Édesviz
>Úgy látom megfogott a téma (vagy 1 órát pörgött rajta az agyad :)
Tényleg megfogott, mert bár évek óta fórumozok és levlistázok a témában, de nem nagyon emlékszem, hogy mindez téma lett volna (olyannyira, hogy az általam látogatott két magyar szakmai levlistára (sql, oracle) is forwardoltam a thread érdekesebb részét)
Még a félig strukturált XML is eléggé szőrmentén került elő...
BTW: nagy örömmel láttam, hogy igaz csak műegyetemi (adatbázis)jegyzet formájában, igaz nem túl nagy fejezetben de végre magyar nyelven is foglalkoznak a témával rendes megalapozással, a korábbi elméleti alapokhoz illeszkedően...
>Ha belegondolsz, az 1000 oszlop kihasználása vagy az időt az oszlopokban vezetni ugyanilyen probléma.
Nem igazán értem miért mondod. - (Nem feltétlen sql-)programok sok adatot tudnak tölteni adattáblá(k)ba (nemcsak kézzel lehet rögzíteni ;) - Ha a rekordkulcsokra minden hónapban számolódik pl.: bonyi algoritmussal valamilyen infó/státusz/havi érték akkor jó eséllyel százalékosan nagy kitöltöttségű tud lenni a kérdéses fucsa táblastruktúra. (az most offtopic, hogy helyes-e ilyen státuszt tárolni, de támpont lehet például az a szitu, hogy ha változik és/vagy rossz érték számolódott évközben aktuálisan, akkor is ha kiment például ügyfél felé ==> _kötelező_ tárolni) - Még ha ritkás is a mátrix, a null nem feltétlen okoz nagy gázt tárolás oldalon. - Két dimenziós táblára sql-t megfogalmazni több embernek is megy (még akár nem-programozónak is ;) Ha meg lassabb, hát lassabb: valamit valamiért
>hogy még mindig megbántam (1-2 év múlva), ha olyan architektúrát használtam, ami nem bírt el legalább tízszeres növekedést.
Nagyon nehéz téma évekre előre ilyesmit tervezni/belőni a várható életciklust + költségeket figyelembevéve. Sokszor az is fontos lehet, hogy egy jó projekt ne azon fulladjon be, mert eleve túlbiztosításra kerül, irdatlan költségigénnyel, amivel persze nem azt mondom, hogy 'nulla forinttal majd csak lesz valahogyan' alapon brute force kell belevágni egy projektbe)
>kit érdekel ma már a diszk 10 GB alatt???
Evvel nem értek egyet. Ugyanis a 24/7-ben működő vállalatok többnyire nem PATA vinyókkal dolgoznak, hanem komoly biztonságos, skálázható, távolról menedzselhető storage-kkal /ami jelentheti például azt is, hogy egy nappal előre tudják, hogy holnap(!!) melyik vinyót kell megdöglés miatt online kicserélni/. Ezen storage-ok (szekrény+vinyók) ára még középkategória esetén is aranyárban vannak, ráadásul irgalmatlanul fejlődnek illetve megfordítva avulnak el és/vagy nőhetők ki.
A másik ami eszembe jutott több helyen is olvasható, hogy hogyan kell várható adatbázis méretet (bázis+növekmény) kalkulálni. Oracle esetén ez közismerten nagyon macerás bonyi algoritmussal megy, aminek a vége úgy is az, hogy szorozd meg kettővel a kapott eredményt. ;) Én emiatt is ökölszabályként azt szoktam mondani, hogy ha a valós érték az általam gondolt fele és duplája közé fog esni, akkor már nem kalkuláltam rosszul ;) Ez elsőre nevetségesen tág intervallumnak hangzik, de még így is könnyű mellélőni sokszor...
>De nekem még mindig csak a bajom volt az olyan táblákkal, amik sok azonos típusú oszlopot tartalmaztak (pl. kérdés1, kérdés2, stb.)
Nyílván nem a jövő alternatívája a vázolt extrém táblastruktúra. Én mindösszesen azt mondom, hogy még ezt sem szabad izomból elutasítani: érdemes néha konkrét tervezési megfontolás _után_ elvetni csak...
Úgy látom megfogott a téma (vagy 1 órát pörgött rajta az agyad :)
Mivel fejlesztőből lettem DBA, időnként igencsak elcsodálkozom, hogy némely fejlesztő miből gondolja, hogy az alkalmazását soha nem kell majd az idővel változó igényekhez igazítani. Eddigi (nem túl hosszú) tapasztalatom alapján azt mondhatom, hogy még min dig megbántam (1-2 év múlva), ha olyan architektúrát használtam, ami nem bírt el legalább tízszeres növekedést. Ha belegondolsz, az 1000 oszlop kihasználása vagy az időt az oszlopokban vezetni ugyanilyen probléma. Nyilvánvaló, hogy a relációs modell közel sem optimális a tárolást tekintve. Erre egy példa: valami régi nagygépes adatbáziskezelőből oracle-be nyomtak egy 40MB-os(!) adatbázist, ami ettől majdnem 1GB-ot foglalt el, és nem volt benne sok szabad hely. OK, ebből 300MB volt a SYSTEM, 100MB TEMP és UNDO. Ez még mindig 15x-ös növekedést jelent. Viszont így már olcsón (extra licenszek nélkül) rá tudtak tenni egy háromrétegű alkalmazást, ami sokkal jobban követte a felhasználói igényeket (nem csak a cégét, hanem azokét is, akik használták), és kit érdekel ma már a diszk 10 GB alatt???
Nyilván az adott feladattól függ, hogy megéri-e pl. széles táblákkal dolgozni. Meg attól is, hogy a "szép" megoldásra van-e elég erőforrás. De nekem még mindig csak a bajom volt az olyan táblákkal, amik sok azonos típusú oszlopot tartalmaztak (pl. kérdés1, kérdés2, stb.)
>El nem tudom képzelni, hogy egy 1000mezős táblára értelmezhető és könnyen változtataható(!) lekérdezéseket lehetne csinálni.
Azért lássuk be a relációs adamodellezésnek is vannak korlátai. Nyílván ez a matematikailag legmegalapozottabb, legrégebb óta legjobban használható valamint a későbbiek során a legjobb performanciát nyújtó megoldás).
De!
A 'gigantikus' oszlopszám akkor is megmarad igénynek (idő haladtával, még nőhetnek is az ilyen igények, lásd még bürokrácia). Sehogy se egyszerű a kezelése. A struktúra-módosítás és főleg verziózásuk rdbms esetén közel nem-triviális. Nem mindegy, hogy mező azért null mert lehet null, avagy elfelejtették kitölteni (ugye különféle űrlap-verzióknál) És így tovább... Lehet, hogy van eset amikor a komplexitás túlburjánzását megakadályozandó megéri a természetesebb emberi szemlélethez közeledni, esetleg épp a lekérdezés-performancia kárára.
És akkor prezentálnék egy virtuális öngyilkosság-számba menő hozzászólást ;)
Az ilyesmi űrlap-feladathoz mindenképp számításba jöhet a félig-struktúrált XML. És a való magyaroszági(!) életből is hozható példa: hiteligénylés -> többszáz mező, folyamatosan változó adatstruktúra (verziózott xsd ;) hol szigorúbb, hol enyhébb pulzáló adatmegkövetelési igény stb.
Mi a nagy előnye? Jó funkcionalitás, korrekt adatrendundancia, jól tömöríthető tárolás, viszonylag hatékony és már kitalált adatelérés.
Mi a hátránya? Brutális processzor és memória-igény hardver-oldalon. Azért lássuk be a rekurzív xml-parse nem a világ legtriviálisabb legatomibb művelete...
Egyébként, ha és már a 'halál' táblaszervezési formátumok: akkor nem tudom mennyire ismert itt a Eurocard/Mastercard (az egyik legnagyobb bankkártya-társaság) transaction clearing/settlement táblaszervezése. Egyetlen 'main-'tábla, nested oszlopok tán max három szinten. És úgy kell kifejteni az adott oszlopot, hogy a magasabb szinten lévő illetve előrébb lévő oszlopok speciálisan megadott bitjeiből kell kikalkulálni, hogy milyen mező milyen paraméterezéssel is fog következni... Tranzakciótípusonként más-más ugye. Totális kétdimenziós variábilitás.
Az első gondolatom az volt, hogy ez security ok miatt lehetett csak ilyen 'jó' a struktúra-megválasztás. Mivel három böhöm nagy vastag könyv írja le a táblaspecifikációt, mire ezt valaki korrekten implementálja, egyszerűbb ha McJob-ban gyüjtögeti a lóvét, nem rendszer attack-kal. ;)
>El nem tudom képzelni, hogy egy 1000mezős táblára értelmezhető és könnyen változtataható(!) lekérdezéseket lehetne csinálni.
Nagyon érdekes a téma... ;)
Tapasztalatból mondom, hogy vannak olyan feladatok/implementációk, ahol bizony nagyon sok oszlopra van szükség. Gondolj például arra amikor valaki egy hatalmas - számára így "beszédes" - kétdimenziós crosstab(=Excelben->pivot) táblában gondolkodik (amit, ha ma már esetleg támogat is az Oracle /ezt most nincs kedvem verifikálni/, nagyon sokáig, kétmenetes dinamikus sql generálásos módszerrel támogatott csak sql-szinten). Nyílván nem a relációs adatmodellezés 'csúcsa', de mivel természetes emberi korlátokat figyelembevevő megoldás, meglehet -> érdemes számolni vele...
Láttam olyat is, hogy az idődimenzió volt a vizszintes tengelyen az oszlopokban(!!!), és újabb oszlopok hozzáadásával nőtt az idővel a tábla... Sőt! Migráltam is ilyet Oracle alá (ami első ránézésre annyira azért nem volt trivi, 999 oszloposra szétdobott táblákat, adatszótár segítségével oszlop-sor transzformálni)
Nem tudom mennyire közismert a SAS (www.sas.com), ami egy másik 'hightech' dimenzió az Oracle-hez képest, mind termékpalettát, mind árakat tekintve (ami miatt is igen kevéssé elterjedt itthon), például adatbázis-megoldásában kvázi egyenrangúvá teszi az oszlopokat és a sorokat, mind elérés (programozható oszlopelérés, makróváltozóval), mind korlátok szempontjából.
El nem tudom képzelni, hogy egy 1000mezős táblára értelmezhető és könnyen változtataható(!) lekérdezéseket lehetne csinálni. Ráadásul nem is valószínű, hogy van értelme: az oszlopszám növekedésével az adatmodell átláthatósága jelentősen csökken. Halálosztó adatmodellje sokkal flexibilisebb és nem kell változtatni, ha új kérdést akarsz tenni az űrlapra - elég csak az új kérdést leírni a kérdések táblában. A relációs adatbázisokat pont ilyen adatmodellekhez találták ki, ezért nagyon nem fekszik nekik az 1000 oszlop. Eddig a legtöbb oszlop amit láttam egy táblában, az kevéssel 300 alatt volt, de már az is egy csomó adatot duplikált - ezáltal a szépséget a sebesség oltárán feláldozva. De ez egy szép nagy (terrás) adattárház közepében csücsült, ezért megbocsátható, hogy még aznap szerették volna megkapni a select eredményét... Ha egy tábla lehetőleg egy valós objektumot reprezentál, az oszlopok pedig ennek az jellemzőit, akkor elég valószínű, hogy egy 1000 jellemzős valami nem lesz oszthatatlan: lehet találni olyan alobjektumokat, amikből felépül, és ezeket kell leírni, meg hogy hogyan is építik fel az objektumot.
Az engem is rettenetesen érdekelne, hogy hogyan tudod a széles (1000 oszlopos) táblát gyorsan lekérdezni (1 körben), ha joinolós változatot (by halálosztó) csak 2 körben. Egyátalán hogyan történne ez a 2 körös verzió és hogyan folyik most az 1 körös?
Amúgy milyen nagyságrendekről beszélgetünk? Hányféle kérdőívtípus van? Hány sor van ebben az 1000oszlopos táblában (vagyis hány kitöltött kérdőívetek van)? Hány mező szokott lenni egy kérdőíven?
The absolute maximum number of columns in a table is 1000. However, when you create an object table or a relational table with columns of object, nested table, varray, or REF type, Oracle Database maps the columns of the user-defined types to relational columns, in effect creating hidden columns that count toward the 1000-column limit.
Szia, természetes, hogy a kulcs rész ismétlődik. De a válaszok jókora részét se érdemes külön mezőbe tenned. Mit érsz 1000 varchar(2) mezővel, amiben 'I', 'N', vagy üres. Konkatenáld össze a válaszokat, substr-rel pedig kiértékelheted. Édesviz
Ha kell irnod egy fuggvenyt, ami bemenetkent kapja az urlapmezo sorszamat, es a feletelt (legyen egyszeruseg kedveert egyenlosegi feltetel) akkor hogyan kodolod le?
"amikor a leválogatási szempontokat meghatározzuk, akkor annak itt egy olyan rekordcsoportra kell vonatkoznia, amely rekordcsoport jelentős része nem rendelkezik a leválogatási szemponthoz tartozó információval. Ezért csak két körben lehet meghatározni a leválogatandó rekordokat."
Ez alatt mit ertesz? Legyenek a mezok veznev, kernev, neme, a kerdoivek aiv, biv, civ.
Valaszok tabla KerdesID IvID Valasz ------------- -------- ---------- 1 1 Kovacs 2 1 Elek 3 1 Ferfi 1 2 Nagy 2 2 Lilla 3 2 No 1 3 Titok
Ha meg akarjuk tudni mely kerdoiveket toltottek ki ferfiak:
select k.* from kerdoivek k, valaszok v, kerdesek kr where v.kerdesID = kr.kerdesID and v.IvID = k.IvID and kr.Kerdes='neme' and v.Valasz='ferfi'
Ebben nem lesznek benne amikre nem toltottek ki nemet, de arrol nem is tudjuk. Ha az kell hogy ferfi vagy ures, akkor el kell olvasni a doksiban az outer join vagy az union cimszavakat.
Amikor kitöltött űrlapokat akarunk feldolgozni, akkor előfordul, hogy az űrlapnak ezernél több mezője van. Az igaz, hogy a keresett űrlapok leválogatásánál nem kell az összes mezőt megjeleníteni, de a megjelenítendő mezők összetétele esetenként változik.
A halaloszto által javasolt megoldásban azt látom problémásnak, hogy amikor a leválogatási szempontokat meghatározzuk, akkor annak itt egy olyan rekordcsoportra kell vonatkoznia, amely rekordcsoport jelentős része nem rendelkezik a leválogatási szemponthoz tartozó információval. Ezért csak két körben lehet meghatározni a leválogatandó rekordokat.
Az edesviz által javasolt megoldás jónak tűnik; különösen, ha rögzítjük, hogy mind a két tábla ugyanazt az ID-t használja.
