- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Apple iPhone 16 Pro - rutinvizsga
- India felől közelít egy 7550 mAh-s Redmi
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Új hozzászólás Aktív témák
-
nyunyu
félisten
Erre nem lenne célszerűbb írni egy before insert (Oracle) vagy instead of triggert (MS SQL) * ami azt csinálja, hogy ha már van fej_id, tetel_id, ar, kedv értékekkel sorod, akkor annak mennyiségét, értékét megnöveli az újonnan beszúrandó mennyiséggel, mennyiség*árral?
Ha meg nincs, akkor beszúrja az új sort?Mondjuk a táblákra aggatott triggerek nem szokták növelni a DB logika átláthatóságát
*: pontos szintaxisuk nekem sincs meg fejben.
-
nyunyu
félisten
Jobban végignéztem a query elejét.
Egyszer a select által visszaadott oszloplistában létrehozol egy bank meg egy penztar oszlop aliast
Lejjebb meg hivatkozol egy bank meg egy penztar nevű táblára, amiket elneveztél t2 meg t4-nek.Nem szerencsés egy queryn belül ugyanolyan aliast definiálni, mint amilyen táblát/aliast használsz máshol.
-
nyunyu
félisten
WHERE t1.tipus='0'
AND t1.teljesites <= '2023-01-01'
AND t3.datum <= '2023-01-01'Wherehez írt feltételek erős szűrési feltételek.
Ha nincs t3-ból találat, akkor a t3.datum <='2023-01-01' ki fogja szűrni az egész t1 sorát, mintha erős join lenne.Próbáld meg áttenni a left joinolt táblákra vonatkozó feltételeket a left join ON-ja után:
LEFT JOIN bank AS t3 ON t3.bank_id=t2.bank_id AND t3.datum <= '2023-01-01'Where mögött csak az eredeti táblára, és hozzá erősen joinoltakra vonatkozó feltételek maradjanak.
-
pch
senior tag
Most már ennyire átírtam, hogy a pénztár s bank táblákat összejoin-oltam és azt tettem left joinba. De az eredmény ugyanaz..
SELECT t1.szamla_id, t1.vevo_id, t1.vnev, t1.brutto, (ROUND(IFNULL((SUM(t2.bevetel)-(t2.kiadas)),0),2)+ROUND(IFNULL((SUM(t4.bevetel)-(t4.kiadas)),0),2)) as fizetve
FROM kimszamla AS t1
LEFT JOIN (banklista AS t2,bank AS t3) ON (t1.szamla_id=t2.szamla_id AND t2.bank_id=t3.bank_id)
LEFT JOIN (penztarlista AS t4,penztar AS t5) ON (t1.szamla_id=t4.szamla_id AND t4.penztar_id=t5.penztar_id)
WHERE t1.tipus='0'
AND t1.teljesites <= '2023-12-01'
AND t3.datum <= '2023-12-01'
AND t5.datum <= '2023-12-01'
AND t2.kivezetes = 'V_SZ'
AND t4.kivezetes = 'V_SZ'
GROUP BY t1.vevo_id;Mintha lesz@rna left join vagy right join van inner join lenne. Az eredmény mindig ugyanaz
-
DeFranco
nagyúr
Nem fordítva írod?
select * from T1
left join T2 on T1.azon=T2.azonami az egyenlet bal oldalán van (T1) abból minden és T2-ből az egyező.
ha
left join T2 on T2.azon=T1.azonakkor minden T2-ből és T1-ből ami egyező
tehát nem mindegy mi van az egyenlet bal oldalán, az lesz a "minden"
-
fjanni
tag
Nem a számlálóállásokat kell összeadni, hanem az egyes számlálóállás különbözeteket, ezért kell a LAG függvény.
Zaehlerstand- LAG (Zaehlerstand) over (order by Zeit) as Consumption
Ez viszont már nem fut le valamiért az SQL Fiddle-ben.
Ez a hibaüzenet: DDL and DML statements are not allowed in the query panel for MySQL; only SELECT statements are allowed. Put DDL and DML in the schema panel. -
fjanni
tag
Ez szerintem nem jó, az időbélyeg a Zeit mezőben van, a sum(zeit) pedig az idő összesíti és nem a számláló különbözeteket.
Úgy érted SELECT YEAR(Zeit) as year, MONTH(Zeit) as month, sum (counterdif) as Consumption from table group by year, month ?
A probléma még mindig az, hogy amikor GROUP BY nélkül futtatom akkor helyesen a 12. hónapra teszi a Counter dif értékeket (amiket összesíteni kell), de ha group-olom, akkor miért teszi ezt az 1. hónaphoz? -
Petya25
őstag
Excelben ez két kattintás, a sort behúzod a sorokba, az oszlopot behúzod az oszlopba, a db-ot meg az értékbe.
Egy sima kis táblázat ahol pl nevenként vannak tárgyak felsorolva illetve hogy abból mennyi darab van nála.
ez lenne a cél:
név tárgy1 tárgy2 tárgy3
béla 4 2 5
lajos 0 3 9 -
-
nyunyu
félisten
SELECT nev,
sum(case when jelenlet NOT IN ('99') AND hianyzas NOT IN ('1') then 1 else 0) AS 'hianyzasoknelkul',
sum(case when jelenlet NOT IN ('99') then 1 else 0) AS 'hianyzasokkal'
FROM tabla
group by nev;Count a nemnull értékek számát adja vissza! (then 1 else null kellene hozzá)
Sum meg az összegét. -
-
nyunyu
félisten
Elég a kettő:
select t1.id, t1.szin, t2.id, t2.szin
from tabla1 t1
left join tabla2 t2
on t2.id = t1.id
and t2.szin = t1.szin
union
select t1.id, t1.szin, t2.id, t2.szin
from tabla1 t1
right join tabla2 t2
on t2.id = t1.id
and t2.szin = t1.szin;Sima union kiszűri az ismétlődéseket az eredménylistából. (union all megtartaná a közös találatok mindkét példányát.)
-
tm5
tag
Erről a PREGEXP-ről még soha nem hallottam SQL SELECTben. Milyen SQL szerverről beszélünk itt? Mert eléggé eltérő módon támogatják a regexp-et, vagy nem.
Valami ilyesmi kellene:
UPDATE cikk
SET information = <az EAN forrása>
WHERE information NOT LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]' -
nyunyu
félisten
Rendeléseket kérdezted:
Kellene egy lista amibe azon a rendelések vannak amin akad még tennivaló.Amit írtam queryt, az visszaadja mindegyik rendelést, amihez tartozik legalább egy kuldes_id=0 vagy szamla_id =0 tétel.
Ha a konkrét, még nem kész megrendelés tételeik is kellenek, akkor
select t1.rendeles_id, t2.tetel_id
... -
nyunyu
félisten
Akkor az IS NULL-okat cseréld = 0-ra
SELECT DISTINCT T1.rendeles_id
FROM rendeles AS T1
JOIN tetel AS T2
ON T1.rendeles_id=T2.rendeles_id
AND (T2.kuldes_id = 0
OR T2.szamla_id = 0)
WHERE T1.rendeles_id NOT IN (SELECT rendeles_tmp FROM user);Elég háklis szoktam lenni a rendszerszervezőkre, ha olyan mezőkre is specelnek NOT NULL constraint-t, ahol semmi keresnivalója.
Pláne, hogy a kuldes_id-nek, szamla_id-nek logikusan foreign keynek kellene lennie, ami a kuldes, szamla táblák id mezőjére mutat.
Ott meg szigorúan NULL a gyerek tábla mezője, ha éppen nem mutat a szülő egyik rekordjára se! -
nyunyu
félisten
Sokadik olvasatra sikerült megfejtenem, mit is akart jelenteni ez a sor:
AND rendeles_id NOT IN (SELECT IFNULL(rendeles_tmp,0) FROM user)Ha jól értem, amíg a felhasználó nyitott egy tranzakciót, akkor az user tábla rendeles_tmp oszlopba íródik be a félkész rendelés ID-je, és ott is marad, amíg be nem fejezi a vásárlást.
(Remélem egy másik "trigger" takarítja a szemetet utána!
Bár én azt nem triggerre bíznám, hanem explicite kiadnám a delete-et a program kódban.
Ha ilyenekre triggereket használtok, ott valami nagyon félrement az alkalmazás tervezésekor/implementálásakor.)Ekkor viszont a querym végére ezt egy WHERE-be kéne írni:
SELECT DISTINCT T1.rendeles_id
FROM rendeles AS T1
JOIN tetel AS T2
ON T1.rendeles_id=T2.rendeles_id
AND (T2.kuldes_id IS NULL
OR T2.szamla_id IS NULL)
WHERE T1.rendeles_id NOT IN (SELECT rendeles_tmp FROM user);IFNULL(rendeles_tmp,0): ezt meg eleve nem értem, miért kell a null értékeket nullára konvertálni?
Ki nem töltött érték/null az nem része a halmaznak (IN), de az ellenkezőjének sem (NOT IN).(Java programozóink szoktak vért izzadni, mert a DBben a null is értelmes érték.
Azt jelenti, hogy nincs adat.) -
nyunyu
félisten
Juj.
Először sorbarendezted+csoportosítottad a tételeket rendeles_id szerint, azután az ablakozós függvény a csoportokra külön-külön képezett egy eredményt, aztán az eredményhalmazt még egyszer átfésülted a having után írt feltételekkel?
Nem lenne egyszerűbb egy sima joinnal eleve azokra a tételekre szűrni, ahol a kuldes_id vagy szamla_id null?
SELECT DISTINCT T1.rendeles_id
FROM rendeles AS T1
JOIN tetel AS T2
ON T1.rendeles_id=T2.rendeles_id
AND (T2.kuldes_id IS NULL
OR T2.szamla_id IS NULL);Distinctet csak azért tettem bele, hogy a több hiányos tétellel rendelkező rendelések csak egyszer szerepeljenek a listában, anélkül annyiszor kapnád vissza az azonosítóját, ahány tétele rossz.
Így csak egyszer fog végigmenni a táblákon *, majd az eredmény sorbarendezése után kihagyja a duplikációkat.
* vagy azon se, ha a tetel tablan van egy összetett index a rendeles_id, szamla_id, kuldes_id trióra.
-
nyunyu
félisten
Szabvány szerint az IN-nek el kell fogadnia egy alquery eredményét is, amennyiben pontosan egy oszlop széles az eredménye, szóval nem értem miért akarod vesszővel felsoroltatni az UNION eredményét, ahelyett, hogy szimplán beírnád az IN utáni zárójelek közé az egész UNIONos queryt.
Ez egy teljesen valid query:
select *
from tabla
where id in (select id from tabla2 where ertek = 1
union
select id from tabla3 where ertek = 2
union
select id from tabla4 where ertek = 3);Végeredménye 0-3 sor lesz, attól függően hány ID van meg a tablaban.
(Oracle megenged több oszlop széles IN-t is, itt arra kell figyelni, hogy ugyanannyi oszlop legyen az IN két oldalán felsorolva:
where (a,b) in (select c,d from tabla);)Amit te szeretnél, az maximum dinamikus SQLlel oldható meg, amikor futási időben rakod össze stringként a queryt, aztán azt futtatod az erre szolgáló paranccsal (EXEC?), de annak meg jellemzően van valamennyi futási idő overheadje (Oraclenál ~1.5 másodperc?), szóval nem éri a nehezen összerakható, nehezen debugolható kóddal szívni, mert nem lesz gyorsabb.
-
baracsi
tag
Szóval nekem nincs két táblám
Nincs jelentősége annak, hogy bizonylatokból veszi az ember az adatokat vagy egy készletmozgás-történet táblából. Ezért kell valamilyen procedurális megoldás, hogy fel tudd dolgozni az adatokat.
Én úgy csináltam, hogy a függvény csinál 2 temp táblát fifo_bevet_vt és fifo_eladas_vt, az egyikbe legyűjtőm a bevételezéseket (leltárt és gyártást is figyel, de az jelen esetben lényegtelen és még egyszer mondom mindegy, hogy honnan vesszük az adatokat, bizonylat vagy mozgástörténet), a másikba az eladásokat adott termékre, mindkét tábla dátum, db és ár mezőket tartalmaz. Az adatok legyűjtése után elkezdem bejárni az eladásokat dátum szerint sorba rendezve majd veszem a mennyiségét és nézek hozzá egy bevétet, itt is mindig a legkisebb dátumú rekordokat figyelem és maximum az eladás mennyiségével csökkentem a fifo_bevet_vt db adatát (már ha van rajta annyi, mert ha nincs, akkor nulla lesz és nézem a következő bevét rekordot). Ha egy fifo_bevet_vt rekord mennyiség elfogy, akkor törlöm. Miután az eladásokat teljesen bejártam és elfogyasztottam a bevét rekordokat, a bevétes táblában csak azok a tételek maradnak, amelyek még nem lettek eladva a saját mennyiségével és árával és ebből már kiszámítható a FIFO átlagár.
A termék FIFO ára pedig egy egyszerű select-tel lekérhető
SELECT get_FIFO_ar(tkod) FROM cikk WHERE ...
Ezért mondom hogy ezt simán SQL-lel elég macerás megcsinálni.
A te esetedben bevét oldalra a 100-as kód a nyitókészlet, az mindenképpen kell, és kellenek hozzá 101-199 mozgások, eladás oldalra pedig mehetnek az eladások és igen, ha nincs olyan táblád, (pl. leltár), ami megmondja, hogy január elsején (vagy tetszőleges dátumra) adott termékre mennyi volt a FIFO ár akkor minden esetben az elejétől kell venni mindent. Ezért jó ha leltározás funkció van a programodban, mert akkor elég csak onnan nézni a bizonylatokat (leltár [mennyiség, ár] és leltár utáni bevétek, eladások) feltételezve azt, hogy a leltárban FIFO árral vannak letárolva az adatok.
-
baracsi
tag
De mi a kérdés, tehát akkor a FIFO működését érted, de nem tudod lemodellezni a működését? Szerintem csak simán nem fogod tudni SQL-lel megoldani, én legalábbis MySQL függvénnyel oldottam meg, mert a beszerzéseket szépen el kell fogyasztgatnod az eladások alapján, és ami marad készlet és beszerzési ár, abból kell meghatározni a FIFO-átlagárat.
-
nyunyu
félisten
Felaggregálod a T2-T3 és T4-T5 párosok maximumát szamla_id-kra, aztán azok közül veszed a nagyobbat?
SELECT T1.szamla_id,
T1.vevo_id,
T1.esedekes,
T1.brutto,
case when A.datum is null then B.datum
when B.datum is null then A.datum
when A.datum > B.datum then A.datum
else B.datum
end fizetve
FROM T1
LEFT JOIN (SELECT T3.szamla_id, MAX(T2.datum) datum
FROM T3
JOIN T2
ON T2.id = T3.fej_id
GROUP BY T3.szamla_id) A
ON A.szamla_id = T1.szamla_id
LEFT JOIN (SELECT T5.szamla_id, MAX(T4.datum) datum
FROM T5
JOIN T4
ON T4.id = T5.fej_id
GROUP BY t5.szamla_id) B
ON B.szamla_id = T1.szamla_id
WHERE T1.vevo_id = 'vevőazonosító'; -
Taci
addikt
Sosem találkoztam még vele, úgyhogy ránéztem. És itt azt taglalják, hogy az SQL_CALC_FOUND_ROWS általában véve lassabb, mint a két külön query (az eredeti + a count).
Plusz ahogy olvasom, a jövőbeli verziókból már ki is szedik a támogatottságát:
The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are deprecated as of MySQL 8.0.17 and will be removed in a future MySQL version.
És hogy a COUNT(*)-ot ajánlják helyette.Köszönöm azért a tippet, legalább láttam, hogy ilyen is van (lassan: volt).
Új hozzászólás Aktív témák
Hirdetés
- Vezetékes FEJhallgatók
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- Profi EKG-s óra lett a Watch Fitből
- Sütés, főzés és konyhai praktikák
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Autós topik
- Honor 400 Pro - gép a képben
- Delta Force (2024)
- Sorozatok
- Ingatlanos topic!
- További aktív témák...
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Samsung Galaxy Tab A8 (2021) , 3/32 GB,
- Csere-Beszámítás! Asus Rog Strix G731GU Gamer Noti! I7 9750H / GTX 1660TI / 16GB D4 / 512 SSD
- Honor 9X Lite 128GB, Kártyafüggetlen, 1 Év Garanciával
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest