Új hozzászólás Aktív témák
-
bpx
őstag
válasz Flashback #1706 üzenetére
ilyenkor az a helyzet, hogy ez adatbaziskezelonkent valtozik es nem tudhatjuk mire gondoltal, ezert irtam egy olyat, ami hozzam a legkozelebb all
de egyebkent MS SQL-ben is van [link]
ha regebbi verzio, akkor a ROUND-ot is lehet hasznalni [link]
a harmadik parametere ha nem 0, akkor nem kerekit, hanem siman csak levagja -
bpx
őstag
mysql rejtelmeit nem igazán ismerem, de ennyit sikerült összehozni
mysql> select date(date_sub(now(), INTERVAL DAYOFWEEK(now())+5 DAY)), date(date_sub(now(), INTERVAL DAYOFWEEK(now())-2 DAY));
+---------------------------------------------------------+---------------------------------------------------------+
| date(date_sub(now(), INTERVAL DAYOFWEEK(now())+5 DAY)) | date(date_sub(now(), INTERVAL DAYOFWEEK(now())-2 DAY)) |
+---------------------------------------------------------+---------------------------------------------------------+
| 2013-04-15 | 2013-04-22 |
+---------------------------------------------------------+---------------------------------------------------------+"WHERE mezo1 > X-1. hét első napja AND mezo2 < X-1. hét utolsó napja."
nem a teljes hét kell?
mezo1 >= X-1. hét első napja AND mezo1 < X. hét első napja[ Szerkesztve ]
-
bpx
őstag
na, jó hogy kérdezed, mert nem hibátlan
a +5 -2 az működik a többi napon is (kivéve 1-et)
azért pont ennyi, mert a hét első napja a DAYOFWEEK szerint az vasárnap, és korrigálni kella vasárnappal viszont pont emiatt gond van...
de most rátaláltam a csodás WEEKDAY() függvényre, aminél nem kell korrigálni, és a hét minden napján jó:
select date(date_sub(now(), INTERVAL WEEKDAY(now())+7 DAY)), date(date_sub(now(), INTERVAL WEEKDAY(now()) DAY));
-
bpx
őstag
igen, es ez az, ami nincs sajnos
ami van, ahhoz kell korites, es tudni kell, mit fog visszaadni a query
ugyanez van Oracle-ben is, EXECUTE IMMEDIATE-tel kb. akarmit vegre lehet hajtani, de csak PL/SQL-ben, es ha van kimenete, ahhoz bizony programozni kell, hogy lassak belole valamit
ha meg elore nem ismert a kimenet strukturaja, hat hagyjuk...
az sp_executesql ahogy nezem, az is ugyanilyennem tudom mekkora az adathalmaz, es hogy kritikus folyamat, vagy eleg az "egyszer fusson le es kesz", de erre a legegyszerubb modszer szerintem mindenfele eval kinlodas nelkul, hogy nem az adatbazisban rakom ossze a query-t dinamikusan es futtatok mindent, hanem a kliens (pl. egy shell script) elkeri a futtatando query-ket es szepen beadagolja
pl. van egy script, ami lekeri a queryket, es futtatja oket psql-el, a kimenetet meg kitolja mondjuk CSV fajlba (vagy amibe kell)
vegen meg a fajlokra mehet a grafikon generatornem tul szep, de legalabb egyszeru
-
bpx
őstag
válasz Speeedfire #1887 üzenetére
"Subqueries cannot be used in the FROM clause of a view. "
-
bpx
őstag
válasz dellfanboy #1900 üzenetére
"select *from tábla_xxxxxx"
igen, rosszul irtad
@ kell _ helyettselect *from tábla@aaaaaa
+ a dblink neve aaaaaa, mivel az xxxxxx az a TNS nev a mintad alapjan
[ Szerkesztve ]
-
bpx
őstag
na ezt például kifejezetten nem szeretem a mysql-ben, hogy egyáltalán engedi a group by-t így használni...
(a másik amit utálok, ha nincsenek kiírva az aliasok mindenhol )
egyébként nem csak a vehiclename-mel van gond ha megnézed, hanem a minutes, seconds, milliseconds sem jóSELECT
d.Name,
t.Minutes, t.Seconds, (t.Milliseconds/1000) AS Milliseconds,
x.besttime AS besttime,
r.TrackTitle,
v.VehicleName
From
tracking t,
driver d,
tracks r,
vehicle v,
(select a.driverid, min((a.Minutes*60)+(a.Seconds)+(a.Milliseconds/1000)) as besttime from tracking a group by a.driverid) x
WHERE
d.id = t.driverid
AND t.driverid = x.driverid
AND t.trackid = '1'
AND t.trackid = r.id
AND t.vehicleid = v.id
AND (t.Minutes*60)+(t.Seconds)+(t.Milliseconds/1000) = x.besttime
order by x.besttime; -
bpx
őstag
válasz dellfanboy #2012 üzenetére
create database link B connect to user identified by pw using 'A';
select * from tabla@B; -
bpx
őstag
válasz csabyka666 #2124 üzenetére
Van ugye a "where lower(oszlop) like '%alma%'" modszer, de ha valami okosabb kell, akkor vannak erre RDBMS-specifikus eszkozok, pl. [link]
-
bpx
őstag
pont az amit ir a hiba
csak classid szerint megy a group by, ilyenkor a tobbi oszlopra "osszesito" fuggveny kell, pl. COUNT, MAX, vagy azokra is group by-olni kell
az a baj a lekerdezessel, hogy mivel a classification oszlopra egyik sincs, igy annak erteke nem determinisztikus
mysql sajnos megenged ilyen lekerdezest, mas adatbaziskezelok szerencsere nem -
bpx
őstag
válasz kenesei1982 #2148 üzenetére
most akkor MySQL vagy MSSQL support kell?
-
bpx
őstag
válasz Apollo17hu #2199 üzenetére
igy esetleg? ugy emlekszem lehet ilyet
AND NVL(t1.calendar_date, to_date('20131231', 'yyyymmdd')) = to_date('20131231', 'yyyymmdd')
AND NVL(t2.calendar_date, to_date('20131231', 'yyyymmdd')) = to_date('20131231', 'yyyymmdd')[ Szerkesztve ]
-
bpx
őstag
válasz PumpkinSeed #2237 üzenetére
Az, hogy odamásolsz pl. egy CSV file-t és tudsz belőle úgy lekérdezni, mintha közönséges tábla lenne.
-
bpx
őstag
válasz PumpkinSeed #2281 üzenetére
első találat
-
bpx
őstag
válasz PumpkinSeed #2286 üzenetére
Azért, mert alapértelmezett esetben a TO_CHAR dátum bemenet esetén a lehetséges leghosszabb kimenetre készülve rak paddinget (extra space-ek), ezért amikor a te 'THURSDAY'-t vársz, ott valójában 'THURSDAY '-t kapsz, mert a 'WEDNESDAY' a leghosszabb, és minden napot 9 karakterre egészít ki emiatt.
Ha ezt nem szeretnéd, akkor a 'DAY' helyett használj 'FMDAY'-t, amiben az FM kikapcsolja a paddinget.
Ezen kívül:
- az UPPER felesleges, mert a 'DAY' miatt eleve nagybetűsen kapod az eredmény ('day' - kisbetű)
- ha a TO_CHAR-t a megfelelő NLS paraméterrel kiegészíted, akkor rögtön magyarul kapod a napot
- az INITCAP függvénnyel lehet a szavak kezdőbetűjét nagybetűre cserélni, ha ez az igényPl:
SQL> SELECT INITCAP(TO_CHAR(TO_DATE('1994-01-06','YYYY-MM-DD'),'FMDAY', 'NLS_DATE_LANGUAGE = HUNGARIAN')) AS VALAMI FROM DUAL;
VALAMI
------------
Csütörtök[ Szerkesztve ]
-
bpx
őstag
válasz dellfanboy #2333 üzenetére
where oszlop between to_date('2014-01-01', 'YYYY-MM-DD') and to_date('2014-02-01', 'YYYY-MM-DD')
-
bpx
őstag
válasz dellfanboy #2336 üzenetére
amikor futtatsz egy lekérdezést, ahhoz az adatbázis végrehajtási tervet készít, és az optimizer az összes lehetséges tervet megvizsgálja, és azokból választja ki a szerinte optimálisat
ha mondjuk így néz ki az sql (Oracle), hogy:select /*+ ordered use_hash(tabla1 tabla2) */ oszlop1, oszlop2, ... from tabla1, tabla2, tabla3 ...
akkor a /*+ ... */ közti "kommentek" valójában optimizer hintek, amivel befolyásolhatod hogy milyen terv készüljön
az ordered azt jelenti, hogy a tábláknál a join sorrendje az lesz, ahogy le van írva az sql szövegében, és nem az adatbázis dönti el, tehát a fenti példában először veszi a tabla1-et, utána a tabla2-t, majd a tabla3-at
a use_hash meg azt jelenti, hogy a tabla1-nél es tabla2-nél hash joint fog használni (míg a hint nélkül lehet, hogy nested loops join vagy merge join lenne)azt meg, hogy miért jó a fromba beágyazott select, nem tudom
sokszor meg lehet oldani anélkül is, ha viszont kell, akkor meg van sokkal olvashatóbb módszer is: with .. as ..
pl. (persze itt pont nem kell, meg az egyszerűsége miatt nincs is nagy különbség, de most ennyire telik tőlem):select * from ( select * from hr.employees where hire_date > date '2005-01-01') e2005
where e2005.salary > 15000;
with e2005 as (select * from hr.employees where hire_date > date '2005-01-01')
select * from e2005 where e2005.salary > 15000; -
bpx
őstag
válasz PumpkinSeed #2378 üzenetére
all_tables
a user_tables csak a saját táblákat mutatja -
bpx
őstag
válasz dellfanboy #2382 üzenetére
na tehát akkor:
user_tables = saját tábláid
all_tables = olyan táblák, amelyek az aktuális felhasználó számára elérhetőek (amelyek lehetnek sajátjai, vagy másé)
dba_tables = összes tábla az adatbázisbanaz utolsót viszont csak akkor tudod lekérdezni, ha kapsz megfelelő jogosultságot
[ Szerkesztve ]
-
bpx
őstag
válasz DopeBob #2511 üzenetére
MySQL-es példát mutatsz, de CONNECT BY-t szeretnél használni, ami az "igazi" Oracle-ben van, MySQL-ben nincs, így maradjunk az Oracle-nél. A példádat kicsit kiegészítettem, mert ha csak két szintes a hierarchia, akkor túl triviális, még CONNECT BY sem kell.
create table table1 (id varchar2(10), part varchar2(100), qty int);
insert into table1 (id, part, qty) values ('1', '1--1', 2);
insert into table1 (id, part, qty) values ('1', '1--2', 4);
insert into table1 (id, part, qty) values ('1', '1--3', 8);
insert into table1 (id, part, qty) values ('1', '1--4', 5);
insert into table1 (id, part, qty) values ('1--1', '1--1--1', 2);
insert into table1 (id, part, qty) values ('1--1', '1--1--2', 2);
insert into table1 (id, part, qty) values ('1--1', '1--1--3', 2);
insert into table1 (id, part, qty) values ('1--2', '1--2--1', 2);
insert into table1 (id, part, qty) values ('1--3', '1--3--1', 2);
insert into table1 (id, part, qty) values ('1--4', '1--4--1', 3);
insert into table1 (id, part, qty) values ('1--4--1', '1--4--1--1', 7);
commit;Lekérdezés + eredmény:
select id, part, qty,
(select exp(sum(ln(t2.qty)))
from table1 t2
start with t2.id = t1.id and t2.part = t1.part
connect by prior id = part
) mqty
from table1 t1
start with id = '1'
connect by id = prior part;
ID PART QTY MQTY
---------- -------------------- ---------- ----------
1 1--1 2 2
1--1 1--1--1 2 4
1--1 1--1--2 2 4
1--1 1--1--3 2 4
1 1--2 4 4
1--2 1--2--1 2 8
1 1--3 8 8
1--3 1--3--1 2 16
1 1--4 5 5
1--4 1--4--1 3 15
1--4--1 1--4--1--1 7 105Ha csak azok érdekelnek, amelyek a hierarchia utolsó szintjén vannak:
select id, part, qty, mqty from (
select id, part, qty,
(select exp(sum(ln(t2.qty)))
from table1 t2
start with t2.id = t1.id and t2.part = t1.part
connect by prior id = part
) mqty,
connect_by_isleaf leaf
from table1 t1
start with id = '1'
connect by id = prior part)
where leaf = 1;
ID PART QTY MQTY
---------- -------------------- ---------- ----------
1--1 1--1--1 2 4
1--1 1--1--2 2 4
1--1 1--1--3 2 4
1--2 1--2--1 2 8
1--3 1--3--1 2 16
1--4--1 1--4--1--1 7 105[ Szerkesztve ]
-
bpx
őstag
válasz bambano #2605 üzenetére
Window function használatával sem fog a 20 millió rekordon végigmenni, ugyanúgy ki tudja választani index mentén az első 3 darabot, és egy ilyen egyszerű példában nincs különbség.
Ugyanakkor én inkább használnám az egyszerűbb módszert. A window function akkor lenne hasznos igazán, ha lenne PARTITION BY, de nincs. Ezen kívül a becsült kardinalitás a window functionnel sokkal pontatlanabb, így sokkal nagyobb az esély egy kevésbé hatékony végrehajtási tervre.
-
bpx
őstag
válasz bambano #2608 üzenetére
OK, akkor kiegészíteném annyival, hogy Oracle-ben nincs különbség.
SELECT /*+ GATHER_PLAN_STATISTICS */ t.aru_nev, t.aru_egysegar FROM
(SELECT aru_nev,aru_egysegar, rank() OVER (ORDER BY aru_egysegar DESC)
AS sorrend FROM aruk) t WHERE t.sorrend < 4 ORDER BY t.aru_egysegar
Plan hash value: 68470586
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 2 | VIEW | | 1 | 1000K| 3 |00:00:00.01 | 4 |
|* 3 | WINDOW NOSORT STOPKEY | | 1 | 1000K| 4 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 5 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 1000K| 5 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("T"."SORREND"<4)
3 - filter(RANK() OVER ( ORDER BY INTERNAL_FUNCTION("ARU_EGYSEGAR") DESC )<4)Az első query-t egy az egyben másoltam, a másodiknál a limitet át kellett írnom, mert az itt nincs.
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM (SELECT
aru_nev,aru_egysegar FROM aruk ORDER BY aru_egysegar DESC) aruk_kivonat
where rownum < 4 ORDER BY aruk_kivonat.aru_egysegar ASC
Plan hash value: 2883829479
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 3 |00:00:00.01 | 4 |
| 1 | SORT ORDER BY | | 1 | 3 | 3 |00:00:00.01 | 4 |
|* 2 | COUNT STOPKEY | | 1 | | 3 |00:00:00.01 | 4 |
| 3 | VIEW | | 1 | 3 | 3 |00:00:00.01 | 4 |
| 4 | TABLE ACCESS BY INDEX ROWID| ARUK | 1 | 1000K| 3 |00:00:00.01 | 4 |
| 5 | INDEX FULL SCAN DESCENDING| I_ARU_AR | 1 | 3 | 3 |00:00:00.01 | 3 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(ROWNUM<4)0,01 másodperc, 4 darab blokk érintésével megoldotta mindkettő. Egyedüli látványos különbség, hogy az elsőnél mindenhol 1000K a becsült sorok száma.
A 2 query egyébként nem ekvivalens, rank() helyett row_number()-rel lenne az.
-
bpx
őstag
válasz bambano #2610 üzenetére
Nem tettem tönkre, ezt egyszerűen így kell leírni, mert sajnos nincs LIMIT. A WHERE előbb van, mint az ORDER BY, a másodikban levő subquery azt jelenti, hogy "olvass fel <4 sort a táblából és rendezd", és nem pedig azt, hogy "kérem rendezés után az első <4 sort".
ez csak abban az egy esetben lehet ugyanolyan eredményű, ha az oracle képes olyan mélyen értelmezni a lekérdezést, hogy a külsö selectben használt where rownum<4 klauzát képes bevinni a belső selectbe.
Hasonló, de a sorok számára vonatkozó feltételeket speciálisan kezeli, ezek a végrehajtási tervben megjelenő STOPKEY műveletek, amelyek csak addig futtatják a gyerekeiket, amíg el nem érik a megadott limitet. Tehát valóban az történik, hogy úgy kezd neki, mintha az egészet fel kellene olvasni, de 3 sornál megáll. Az adatbázis az egyéb feltételeket is simán mozgatja szintek között, ha szerinte úgy hatékonyabb, azokra nincs külön művelet.
A subquery-t ha lefuttatom magában, nyilván végigmegy 1 millió sorra, hiszen nem lesz ott a külső szűrés, ami leállítja 3 sornál.
-
bpx
őstag
válasz dellfanboy #2633 üzenetére
where
extract(day from date_from) = 1
and extract(day from date_to + 1) = 1
and trunc(date_from, 'MM') = trunc(date_to, 'MM') -
bpx
őstag
válasz supercharley #2634 üzenetére
select datum, azonosito, sum(darab) over (partition by azonosito order by datum, azonosito range between unbounded preceding and current row) from adattabla
order by datum, azonosito; -
bpx
őstag
válasz supercharley #2637 üzenetére
akkor itt a buta verzió:
select a1.datum, a1.azonosito, (select sum(a2.darab) from adattabla a2 where a2.azonosito = a1.azonosito and a2.datum <= a1.datum) from adattabla a1
order by a1.datum, a1.azonosito; -
bpx
őstag
válasz dellfanboy #2641 üzenetére
pl. február:
where
date_to is null
and trunc(date_from, 'MM') = date'2014-02-01' -
bpx
őstag
Egy megoldás már le lett írva, így csak a hibára reagálnék. Azért nem ad eredményt, mert pl. annak, hogy WHERE ROWNUM = 2, nincs értelme, soha nem fog eredményt adni. A ROWNUM eredményhalmazra vonatkozik, és nem táblára. A ROWNUM értéke folyamatosan növekszik az eredményhalmaz sorainak számával együtt. A ROWNUM = 1 azért működik, mert az első sorra teljesül, hogy az az első sor. A ROWNUM = 2 azért nem ad eredményt, mert az első sorra nem teljesül, hogy az a második sor, így nem kerül be az eredményhalmazba, és a ROWNUM értéke sem fog növekedni, így nem lesz eredmény sem.
Na, lassú voltam.
[ Szerkesztve ]
-
bpx
őstag
Mivel nem írtál adatbáziskezelőt, automatikusan feltételezem, hogy szabad a pálya és lehet analitikus függvényeket használni (Oracle).
select
b.id, b.name, a.value, a.timestamp
from
b
join
(
select
id, value, timestamp
from
(
select
id, value, timestamp,
rank() over (partition by id order by timestamp desc) as rn
from
a
)
where
rn = 1
) a on (b.id = a.id); -
bpx
őstag
válasz lordring #2979 üzenetére
Az SQL Server is tudja már 2008-tól az ehhez szükséges aggregációs kiegészítéseket. Kicsit eltördeltem, hogy látszon mit módosítottam:
SELECT
T0.[ItemCode], T0.[Dscription], T0.[Quantity], T0.[Price], T0.[Currency],
sum(T0.[LineTotal]), -- eredeti helyett sum, ez valojaban csak az utolso sorban lesz osszeg
sum(T0.[TotalFrgn]), -- eredeti helyett sum, ez valojaban csak az utolso sorban lesz osszeg
T2.[CardName], T0.[ShipDate], T1.[CardCode]
FROM
CSI1 T0 INNER JOIN OITM T1 ON T0.ItemCode = T1.ItemCode
INNER JOIN OCRD T2 ON T1.CardCode = T2.CardCode
WHERE
T0.[ShipDate] >=[%0]AND T0.[ShipDate] <=[%1] AND T2.CardName = '[%3]'
-- es itt jon a lenyeg
GROUP BY
GROUPING SETS((),(T0.[ItemCode], T0.[Dscription], T0.[Quantity], T0.[Price], T0.[Currency], T2.[CardName], T0.[ShipDate], T1.[CardCode] ));
Új hozzászólás Aktív témák
- Kínai, és egyéb olcsó órák topikja
- PlayStation 5
- iPhone topik
- Elkészült Oroszország első litográfiai berendezése
- Az EU szerint kartelleztek az indítóakkumulátorok piacán
- Jövedelem
- Mibe tegyem a megtakarításaimat?
- Horgász topik
- Villanyszerelés
- MSI blog: válasszunk notebookot akciósan!
- További aktív témák...
- Professzionális fémházas 10. gen Dell Latitude 7410,14" Full HD,i7-10810U,16GB DDR4,1TB M.2 SSD
- REZSI csökkentős OLCSÓ Mini Gamer !!!
- TicWatch Pro 2020 okosóra
- Eladó Palit RTX 4070 Dual 12GB GDDR6X videokártya
- Fujitsu Lifebook E546 , 14" Kijelző, I3-6100U, 8GB DDR4, 128GB SSD, WIN 10, Számla, garancia
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen