Új hozzászólás Aktív témák
-
Frigo
őstag
-
Lortech
addikt
A lekérdezés eredményének egyik mezője? Egyik, mint tetszőleges mezője vagy egyik, mint 1 adott mezője.
A lekérdezés eredményén (kurzor) végiggyalogolsz egy ciklussal, és a megfelelő mező(ke)t megvizsgálod instr függvénnyel.
Hatékonyabb lenne, ha eleve az sql tartalmazza a vizsgálatot a where-ben a like klózzal.
Nem tudom, hogy ezzel segítettem-e, mert 38 féleképpen lehet értelmezni a mondatodat, pontosítás kéne pont bemenet és elvárt végeredmény tekintetében.Thank you to god for making me an atheist
-
bpx
őstag
a dátumokat simán ki lehet vonni egymásból, amiből szám lesz
1 egész jelent 1 napotSQL> select to_date('2011-10-12 08:00:00', 'YYYY-MM-DD HH24:MI:SS') - to_date('2011-10-01 19:00:00', 'YYYY-MM-DD HH24:MI:SS') from dual;
TO_DATE('2011-10-1208:00:00','YYYY-MM-DDHH24:MI:SS')-TO_DATE('2011-10-0119:00:00
--------------------------------------------------------------------------------
10.5416667aztán ezt lehet még szépíteni ha szeretnéd, pl. trunc()
-
martonx
veterán
Oracle-ül nem tudok, de a megvalósítás elvi alapja bármilyen SQL-en (már amelyik ismeri a join-t):
1. csinálsz egy táblát, amibe belerakod 3 évre visszamenőleg az összes napot. Ha már csinálsz egy ilyen táblát, pár évre előre sem árt belerakni a napokat. Esetedben nem kell a munkanapokkal, hétvégékkel, munkaszüneti napokkal foglalkozni, én ettől függetlenül javasolnám, hogy ezeket is kezeld le benne. Ha már rászánod az időt, a későbbiekben még jól jöhet. A szökőévekre azért figyelj oda mindenképpen.
A táblát én úgy csinálnám, hogy beállítok egy kezdő évet, majd while ciklusokkal léptetve az évet, és a napokat, szépen teleinsertálnám a napokkal.
2. A létrejött naptár táblát joinolod a lekérdezendő táblához, mégpedig az alapján, hogy az adott nap közé esik-e az intervallumodnak. Ha több esik közé az is jó (Descarte-szorzat ugye). Az így kapott selectet countozod, groupolod a napokra és voilá.Az 1-es pont szép, elegáns megvalósítása eltarthat egy darabig (SQL guruságtól függően több perctől több óráig), de megéri a fáradtságot, mert utána mindenféle a 2-eshez hasonló okosságra fel tudod használni a naptár tábládat.
Én kérek elnézést!
-
bpx
őstag
lehet, de ehhez nem kell újra feltalálni a kereket:
SQL> create table test1(name varchar2(10));
Table created.
SQL> insert into test1 values('Spongyabob');
1 row created.
SQL> insert into test1 values('Patrik');
1 row created.
SQL> insert into test1 values('Tunyacsáp');
1 row created.
SQL> commit;
Commit complete.
SQL> select listagg(name,',') within group (order by name) as nevek from test1;
NEVEK
------------------------------
Patrik,Spongyabob,TunyacsápEz mondjuk 11.2-es feature, ha ennél régebbi az Oracle, akkor google: oracle string aggregation
[ Szerkesztve ]
-
bpx
őstag
megfelelő indexeket létrehozni, statisztikát gyűjteni
végrehajtási tervet megnézni
session trace, majd ott megnézni, hogy mi veszi el sok időtha ezek megvoltak, na akkor lehet hintelni
legvégső esetben hidden paraméterek, ha valami nagyon specifikus a probléma[ Szerkesztve ]
-
bpx
őstag
ha bekapcsolod, aprólékosan minden egyes aktivitást, várakozást feljegyez egy trace fájlba, amit később ki lehet értékelni
pl. tkprof-fal lehet ember által emészthető formára hozni, ahol lehet látni pl. minden egyes sql utasításra, hogy milyen tervvel futott, és a terv egyes lépései mennyi ideig tartottak#1026: a view nem más, mint egy elmentett lekérdezés aminek neve van, semmivel se gyorsabb se mysqlben, se Oracle-ben, csak kényelmesebb
[ Szerkesztve ]
-
rum-cajsz
őstag
Oracleben van lehetőség a Materializált Nézetekre, amivel valóban lehet gyorsítani a selectedet, de ezt körültekintően érdemes használni.
De a legfőbb kérdés, hogy mire akarod használni az adott selectet. A hálózati forgalom pl. minimalizálható, ha nézetet használsz, ám ha ezt a lekérdezést egy sql*plusban adod ki, akkor nem lesz különbség a két (select contra view) között.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Nem írtad az adatbázist! Oracle-ben pl. az ALL_IND_COLUMNS nézetből lekérdezheted:
select
INDEX_NAME,
LPAD(TABLE_NAME,17) TABLE_NAME,
LPAD(COLUMN_NAME,15) COLUMN_NAME,
LPAD(COLUMN_POSITION,5) COLUMN_POSITION
from ALL_IND_COLUMNS
WHERE TABLE_NAME = upper('&tablename')
order by INDEX_NAME,COLUMN_POSITION;=Kilroy was here============================ooO=*(_)*=Ooo=======
-
rum-cajsz
őstag
Csak azokat a mezőket érdemes indexelni, amire keresni akarsz.
Ha a kereséseid több mezőre egyidejűleg történnek, akkor érdemes több mezőre összetett indexet tenni, sőt ha valamilyen függvényt használsz, akkor függvény alapú indexet érdemes használni.
Minél több indexed van, annál lassabb lesz az insert és a delete, mert a sorok felvételével és törlésével egyidejűleg az indexsorok létrehozása is létrejön, törlődik.
Ha többféle lekérdezés is történik a táblán, akkor érdemes lehet több oszlopra is indexet tenni a lekérdezések függvényében.
Összetett index esetén csak akkor fog működni az index alapú keresés, ha az első oszlop legalább benne van a feltételek között.És azért van ilyen neved (SYSxxxxx), mert nem nevezted el az indexet létrehozáskor (pl. primary key definiálásakor), ilyenkor egy rendszer által generált néven jön létre az index.
=Kilroy was here============================ooO=*(_)*=Ooo=======
Új hozzászólás Aktív témák
- Filmvilág
- BestBuy ruhás topik
- Vezetékes FÜLhallgatók
- Robotkart irányított a majom a kínai Neuralink agyi chipjével
- A fociról könnyedén, egy baráti társaságban
- Motorola Moto G24 Power - hol van az erő?
- Motoros topic
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Kerékpárosok, bringások ide!
- Napelem
- További aktív témák...
- Orange Pi Zero H2 Plus 512Mb RAM + 4Gb MicroSD kártyával
- Bomba ár! HP EliteBook 830 G6 - i7-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!
- Bomba ár! Dell Latitude 5580 - i5-G6 I 8-16GB I 256 SSD I 15,6" FHD I HDMI I CAM I W10 I Garancia
- SIS300 agp videokártya
- 46mm Chronos Orák-UJ-Olcsón!