Sziasztok, persze, hogy kontextus függő, pl egy sub select-ben exist mögött még lehetne * is, de ha simán áll egy view-ban, akkor a view is megváltozik. Nekem már volt olyan feladatom, hogy saját rendszernél, már működött vagy 3 éve, több százezer, közelítőleg milliónyi vegyes forrássorból kellett kikereseni a "select *" kifejezéseket. Az ártóakat, és nem ártóakat. Illetve volt olyan is, amikor megnyugodva jelenthettük, mint fejlesztők, hogy egyetlen társunk se esett avészes rövidítés bűnébe. Édesviz
Kontextustól függ. Pro*C-ben ilyenkor ORA-nemtudommennyi-t kapok, ha viszont egy SYSREFCURSOR-om van, amit a PL/SQL-től kaptam, és abból nem olvasok ki minden mezőt a FETCH-ben, az nem okoz gondot.
lehet a mező defaultja null, tehát az összes insert, update delete, futni fog,
csak a select * nem.
Én inkább egy párhuazmos táblát készítenék, kulcs duplikációval, és uj mezővel, mezőkkel. a trigger készítéshez pedig create or replace trigger utesítást ajánlanám
> Ha ennek a táblának a szerkezetét egy mezővel bővítjük, akkor elvileg az összes rá mutató hivatkozást is módosítani kell
Ez azért így, generikusan nem igaz, a következő esetekkel kell törődni: 1. SELECT * 2. INSERT, ha az új mező NOT NULL 3. Amikor az új mezőt adattal kell tölteni
Adott egy olyan nagyméretű alkalmazás, amely gyakorlatilag csak részlegesen átlátható. Ez az alkalmazás egy olyan Oracle adatbázist használ, amelyben az egyik adattábláról nem lehet biztosan tudni azt, hogy az alkalmazás mely részeiről történik rá hivatkozás. Ez a hivatkozás lehet rekord beszúrás és módosítás is.
Ha ennek a táblának a szerkezetét egy mezővel bővítjük, akkor elvileg az összes rá mutató hivatkozást is módosítani kell; ami alól szerintem csak egy olyan trigger használata mentesíthet, amely az adattáblára hivatkozásokat figyeli, és szintaktikailag hibás hivatkozások paramétereit átadja egy szintaktikailag helyes hivatkozásnak és a hiányzó paramétereknek NULL értéket ad. Ez a trigger csak akkor adna vissza hibaüzenetet, ha egy olyan adat hiányzik, amelynek nem lehet NULL értéket adni.
Köszi szépen a segítséget! Az "INSERT INTO tábla1 SELECT * FROM tábla2" meghozta a várt eredményt. De nem tudom, hogy korábban miért nem ment, pedig próbálkoztam... Mindenesetre már 16millió rekordnál elértem az Express változat korlátját, úgyhogy... ennyit erről...
Talán épp arra "gondol," hogy egy ilyen INSERT több sort is behozhat, ezért nem használható a RETURNING... csak akkor a szintaxisgráfot is úgy kellett volna megcsinálni, hogy ne sugalljon olyasmit, amit nem lehet...
Nem lenne külön adatbázisban, csak nem tudtam, hogy kell-e ez az infó. A create table as select működik, de nekem másra van szükségem. Nem jól fogalmaztam valószínűleg. Fel szeretnék tölteni egy adatbázist 50millió rekorddal, és van már egy 2milliós táblám. Ezt a 2millió rekordot szeretném többször beemelni egy másik táblába. Foxproból egy a 2millió feltöltése is nagyon sok idő volt, az sql szerver sokkal gyorsabban megcsinálná.
Üdv! Hogyan lehet 1 tábla tartalmát átemelni egy másikba? A copy valamiért nem akar összejönni. Egy adatbázisban vannak, mivel Oracle Express-el próbálkozom.
Akkor hogy tudnám visszakapni az id-t? ha insert ... values ... RETURNING ... akkor működik. ha insert ... select .... RETURNING ... akkor nem! Mit lehetne tenni?
lenne egy kérdésem: van egy táblám: auto_i2 ehhez szeretnék hozzáfűzni egy rekordot a AUTO_INCREMENT táblából úgy hogy a auto_i2 tábklában before insert trigger segítségével képződő id-t visszakapjam a logID -be. da sajnos a ORA-00933: SQL command not properly ended hibaüzenetet kapom. az insert kipróbált, működik, ha kihagyom a "RETURNING id INTO logID" -t
insert into auto_i2 ( SOMETHING ) select SOMETHING from AUTO_INCREMENT where id = 9 RETURNING id INTO logID; commit;
Üdv Mindenkinek! Oracle 10 Express-el kapcsolatban szeretnék segítséget kérni. Visual Foxpro 7-ből próbálgatom kezelni, de nem túl sok sikerrel. Sikerült nagynehezen ODBC-n összehozni a kapcsolatot, de a saját driverével nem ment, csak egy utólag letöltött, újabb alverzióssal. Létrehoztam egy táblát foxproból, amit onnan el is érek, de ha a webes felületén nézem az Oracle-t, ott nem találom a táblák között. Miért nem látom? Segítségeteket előre is köszönöm!
Igen, ráadásul gyakran szokott az lenni, hogy kérnek valamit, majd aztán valami máshoz is kell később a ugyanaz. Na ezért aztán nem is szoktam a helyel törődni, csak hogy letároljak minden olyat, ami esetleg máshoz is kellhet majd.
Ja és köszi a linket, mindjárt áttanulmányozom. :)
Hát igen, korábban általában mindig az szokott lenni az első kérdésem, hogy OLTP vagy DW a rendszer... DW-nél valóban más a leányzó a fekvése, ahogy te is érzékeltetted... :o)
Kicsit akkor elmagyarázom a környezetet. Logikai ugyan az adatbázis, de Adattárház szervezésű. Úgy néz ki a dolog, hogy este a képviselők szépen feltöltik az adataikat az adatbázisba, aztán mi jól áttöltjük az adattárázba. Eleve egy szörnyet kreáltunk sok redundanciával, úgyhogy mégegy tábla ide vagy oda nem számít. Az eljárás az áttöltés része lesz, szóval ha épp az borul meg azt egyrészt látjuk, plusz magától újraindul ha az oracle hibát ad. Viszont ezt a táblát jól össze tudom majd kötni más táblákkal és riportálgathatom az utolsó négy látogatás különböző eladásait, satöbbit nyugisan és gyorsan. Plusz abban is gondolkodnom kell, hogy a BO, amivel riportálunk, alapvetően egyszerű táblák egyszerű összekötéséből ért. Szóval igazából ez a segédtábla máshol is használva lesz, hely meg van. :)
>Igazából ez csak egy segédtábla lesz, ami alapján megnézem, hogy a különböző látogatásokkor volt-e eladás, vagy készletszámolás.
Na és ez biztos jó ötlet? Önmagában logikai adatbázis-tervezés miatti force-olt redundancia, nem ördögtől való, de... - Valami módon karban kell tartanod a segédtáblát is (tárolt eljárással), vélhetőleg elég gyakran. Ez is erőforrásigény ám. - Ha befigyel a tárolt eljárás, akkor minek az inicializáló sql-en gyötörni magatokat (persze érdekes és szép a feladat l'art pour l'art is... ;) Azt fel sem tételezem, hogy a segédtábla kreáló sql-t mindig futtatni akarnátok, amint a bolt,datum páros valamelyike keletkezik/módosul/törlődik /igaz van amikor még akár ez is belefér/. - _Annyira_ nem nagy nyereség érzésem szerint /mármint a kérdéses származtatott adatok ezen redundáns tárolása/, hogy megérjen egy külön segédtáblát, annak pontos adminisztrációjának nyügeivel.
>>...hogy a látogatások egy mezőben vesszővel elválasztva jelenjenek meg >szerintem hagyja ez nem nekünk való. :)) Akkor hagyjuk? ;) Pedig van rá elegáns megoldás, pl.: string aggregálás http://www.oracle-base.com/articles/10g/StringAggregationTechniques.php
A bolt, dátum egyedi azonosító. Viszont télleg az összes bolt kellene. Igazából ez csak egy segédtábla lesz, ami alapján megnézem, hogy a különböző látogatásokkor volt-e eladás, vagy készletszámolás. Majd aztán jól eldöntöm, hogy hányszor volt disztribúciója az adott terméknek a boltban.
Viszont az egyik komám is kapott egy érdekeset ma. Megintcsak a látogatás táblából, úgy kellene egy adott időszakra levállogatnia a látogatásokat, hogy a látogatások egy mezőben vesszővel elválasztva jelenjenek meg. Én mondtam neki, hogy szerintem hagyja ez nem nekünk való. :)) Mink csak egyszerű alapfokú sql-esek vagyunk, ráadásul autodidakták. Az összes jó kis megoldásotokat, amiket eddig adtatok nekem néha fel sem fogtam. De boldogan fogadtam a vállonveregetéseket, amiket most virtuálisan felajánlom nektek.
Hát nem tudom.... ;) Lehet, hogy reggel van még... ;)
Szerintem ha csak _egyetlen_ bolt utolsó négy látogatása kell (ahogy tisztességes OLTP-rendszerben valamelyest elvárható), akkor én szűrnék a boltra, csökkenően rendeznék a látogatásra, és venném az első négy rekordot. Valahogy így (nem teszteltem)
SELECT ROWNUM rn, kod, datum FROM ( SELECT kod,datum FROM BOLT b WHERE kod='szükésges bolt kódja' ORDER BY datum DESC ) WHERE rn<=4
Ami meggondolásra váró kérdések: - Mi van, ha a (kod,datum) nem unique? - Mi van, ha az _összes_ bolt utolsó négy látogatása kell, SQL-ben? - Mi van, ha analitikus függvény nélkül kellene? ;) -> ez nem biztos, hogy ostoba felvetés; hiszen pl.: bankoknál az ügyfelek utolsó két tranzakciójának lekérdezése sokmilliós táblákon/equijoinokon, egyrészt bír feladat lenni, másrészt bír elgondolkodtató lenni.
select * from ( select boltkod, datum, statusz, row_number() over (partition by boltkod order by datum desc) sorszam from latogatasok ) where sorszam <= 4 order by boltkod, sorszam /