- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
-
Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
ph Az ASTRIA 600 ARGB ráadásul a hűtési teljesítmény szempontjából sem szégyenkezhet.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
Apollo17hu
őstag
Sziasztok!
Telepítettem a MySQL szervert, hozzá pedig a DreamCoder for MySQL eszközt. Utóbbiban próbálnám beállítani a kapcsolatot, de lövésem sincs, hogy kellene:
Nem tudom, mi a Login, a Server-nél pedig semmit sem tudok betallózni. Mi a teendő ilyenkor? -
Apollo17hu
őstag
válasz Apollo17hu #821 üzenetére
Rágugliztam: ki kellett szedni a Direct mellől a pipát.
Amúgy ez a rendszerrel együtt futva azt jelenti, hogy a Win minden egyes indításakor automatikusan elindul a MySQL szerver is a háttérben? -
Apollo17hu
őstag
select u.id
,u.username
,r.friend_id
,r.typeofrelation
from users u
,relations r
where 1=1
and u.id = r.users_id
and r.friend_id = 5
and r.typeofrelation = 1Ha a két táblában további mezők is szerepelnek, ami miatt duplikálódás fordulhat elő, akkor azokat ne sorold fel a SELECT-ben, hanem használj DISTINCT-et!
-
Apollo17hu
őstag
válasz Speeedfire #864 üzenetére
Nem lehetne egy táblával megoldani a dolgot? A kiemelés táblából generálnád az egészet úgy, hogy akinél nincs töltve a "mettol", "meddig" és "hely_erteke" mező, azoknak - ahogy írtad - 1000-et adnál, a többieknek pedig a "hely_erteke" mező értékét.
-
Apollo17hu
őstag
válasz Speeedfire #866 üzenetére
De miért ne lehetne egy olyan tábla, hogy:
id | user_id | sorrend | mettol | meddig | hely_erteke
...és ebből generálnád a tényleges sorrendet az utolsó 4 mező alapján.
-
Apollo17hu
őstag
válasz Speeedfire #869 üzenetére
Hát, mert most akkor emiatt csináljak még egy táblát?
Egyetlen táblával gondoltam az egészet:
id | user_id | sorrend (Kell egyáltalán ez a mező?) | mettol | meddig | hely_erteke | ...
SELECT id
,user_id
,CASE WHEN mettol <= sysdate AND meddig > sysdate
THEN hely_erteke
ELSE 1000 -- Vagy sorrend mező?
END
,...
FROM egyetlen_tabla
ORDER BY 3 -
Apollo17hu
őstag
válasz Speeedfire #875 üzenetére
Ebben benne van mindenki. Aki ki van emelve, annál a "mettol", "meddig" és "hely_erteke" töltött, a többinél null. Ha null, akkor 1000-et kap a sorrend felállításakor. Ha ki van emelve, akkor a "hely_erteke" mező értékét kapja.
Nem kell táblákat kötögetni, csak egy elágazást berakni a SELECT utáni felsorolásba.
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz Speeedfire #877 üzenetére
id | user_id | (sorrend) | mettol | meddig | hely_erteke | ...
Ez az egy táblád lenne. Lényegében a "hirdetes_tabla" táblád kiegészítve a "mettol", "meddig" és "hely_erteke" mezőkkel a "kiemeles_tabla" tábládból, ami így feleslegessé válik.
Ennél egyszerűbben nem tudom. -
Apollo17hu
őstag
válasz Speeedfire #879 üzenetére
Ahogy a "kiemeles_tabla" tábládban írod, úgy.
Ez a sok kategória meg kétféle kiemelés nekem új, így valószínűleg jobb is, hogy külön táblába szedted őket, de ebben nincs tapasztalatom, hogy melyik az erőforrás-igényesebb megoldás.
-
Apollo17hu
őstag
válasz laracroft #992 üzenetére
Nem tudom leellenőrizni a szintaktikáját, de én így csinálnám (aposztróf kell, nem?):
SELECT t.leiras
,COUNT(*) || ' db'
FROM naplo AS t
WHERE
t.ido BETWEEN '2012-11-01' AND '2012-11-25'
AND t.leiras LIKE '%0-_s%'
GROUP BY t.leirasvagy így, ha 100 felett még menne akár millióig, de azokra nincs szükséged:
SELECT t.leiras
,COUNT(*) || ' db'
FROM naplo AS t
WHERE
t.ido BETWEEN '2012-11-01' AND '2012-11-25'
AND (t.leiras LIKE '%10-es%'
OR t.leiras LIKE '%20-as%'
OR t.leiras LIKE '%30-as%'
OR t.leiras LIKE '%40-es%'
OR t.leiras LIKE '%50-es%'
OR t.leiras LIKE '%60-as%'
OR t.leiras LIKE '%70-es%'
OR t.leiras LIKE '%80-as%'
OR t.leiras LIKE '%90-es%'
OR t.leiras LIKE '%100-as%')
GROUP BY t.leiras -
Apollo17hu
őstag
válasz laracroft #998 üzenetére
Töröm a fejem rajta, de kicsit homályos, amit írtál. Pontosan milyen eredményt szeretnél? (Olyan példa jó lenne, amilyet az előző kérdésedben írtál.) A "line" mező biztosan az ügyfelet azonosítja? Arra elég az "account", nem? A "line" gondolom, valamilyen rekordazonosító/bejegyzésazonosító, tehát erre nincs szükséged a lekérdezés eredményében. (Vagy igen?)
Egy ügyfélhez bármennyiszer tartozhat a 'Helyszínen' és 'Lellenőrizve' kifejezéseket tartalmazó bejegyzés vagy csak 1-1 (= 2) db? Tehát ügyfelenként csak 0, 1 és 2 érték várható?
-
Apollo17hu
őstag
válasz laracroft #998 üzenetére
Írtam egyet, talán használni tudod, bár én nem MySQL-t, hanem SQL-t használok:
SELECT sub2.account
,sub2.line
,CASE WHEN sub2.ido_helyszinen IS NOT NULL
AND sub2.ido_leellenorizve IS NOT NULL
AND sub2.diff_fl IS NOT NULL
THEN 2 -- ha helyszínen és leellenőrizve is van 15+ perc különbséggel
WHEN sub2.ido_helyszinen IS NULL
AND sub2.ido_leellenorizve IS NULL
THEN 0 -- ha helyszínen és leellenőrizve sincs
ELSE 1 -- minden más esetben
END db
FROM (SELECT sub1.account
,sub1.line
,sub1.ido_helyszinen
,sub1.ido_leellenorizve
,CASE WHEN (sub1.ido_helyszinen - sub1.ido_leellenorizve)*1440 > 15
THEN 'x'
END diff_fl
FROM (SELECT t.account
,t.line
,MIN(CASE WHEN t.leiras LIKE '%Helyszínen%'
THEN t.ido
END) ido_helyszinen
,MIN(CASE WHEN t.leiras LIKE '%Leellenõrizve%'
THEN t.ido
END) ido_leellenorizve
FROM naplo t
WHERE 1=1
AND (t.leiras LIKE '%Helyszínen%' OR t.leiras LIKE '%Leellenõrizve%')
GROUP BY t.account
,t.line) sub1) sub2[ Szerkesztve ]
-
Apollo17hu
őstag
válasz laracroft #1034 üzenetére
SELECT DISTINCT
ugyfel.account AS account,
ugyfel.line AS line,
ugyfel.name1 AS name,
ugyfel.address3 AS irszam,
ugyfel.address1 AS varos,
ugyfel.address2 AS utca,
COUNT(*) over(PARTITION BY ugyfel.account, ugyfel.line) AS darab
FROM ugyfel, naplo
WHERE naplo.account = ugyfel.account AND naplo.line = ugyfel.line AND ugyfel.name1 NOT LIKE "%teszt%"
ORDER BY darab DESCCOUNT(*) over(PARTITION BY ugyfel.account, ugyfel.line) jelentése:
Csoportosítod a rekordokat: az ugyfel.account + ugyfel.line kombó minden csoportot egyértelműen azonosít. A COUNT(*) ezekre a csoportokra vonatkozik. DISTINCT pedig azért kell, mert enélkül a csoportok minden egyes rekordja új sort generálna (azonos tartalommal).
megj.: Erre szerintem az ORDER BY darab DESC nem működik (bár én csak sima SQL-t használok). Allekérdezéssel ez is áthidalható.
[ Szerkesztve ]
-
Apollo17hu
őstag
-
Apollo17hu
őstag
válasz DanielK #1126 üzenetére
SELECT products.*, prices.price
FROM products
,prices
,(SELECT product_id, MAX(date) AS legfrissebb_datum
FROM prices
GROUP BY product_id) legfrissebb_arak
WHERE products.id = prices.product_id
AND products.id = legfrissebb_arak.product_id
AND prices.date = legfrissebb_arak.legfrissebb_datum -
Apollo17hu
őstag
válasz #68216320 #1147 üzenetére
egyik allekérdezés:
[borok] - [ertekelt_borok] -> SELECT pinceszet_id, AVG(ertek_szam) ...Ez megadja egy pincészetben a borok átlagminősítését.
másik allekérdezés:
[pinceszetek] - [ertekelt_pinceszetek] -> SELECT pinceszet_id, AVG(ertek_szam)Ez megadja egy pincészet átlagminősítését.
A kettőt pedig pinceszet_id -n keresztül összekötöd. A többi táblát ehhez csapod hozzá, ha kell belőle valami.
-
Apollo17hu
őstag
válasz laracroft #1217 üzenetére
MySQL-t nem tudom, de "sima" SQL-ben így lehetne (rendezést kiszedtem):
SELECT *
FROM (SELECT ugyfel.account AS account,
ugyfel.line AS line,
naplo.ido AS ido,
naplo.leiras AS leiras,
SUM(CASE WHEN naplo.leiras LIKE '%valami%' THEN 1 END) AS darab1
SUM(CASE WHEN naplo.leiras LIKE '%valami%' AND naplo.ido LIKE '2013-05%' THEN 1 END) AS darab2
FROM ugyfel,
naplo
WHERE naplo.account = ugyfel.account
AND naplo.line = ugyfel.line
GROUP BY ugyfel.account,
ugyfel.line,
naplo.ido
naplo.leiras
)
WHERE darab1 IS NOT NULL OR darab2 IS NOT NULL -- azon sorok kiszűrése, amelyek egyik feltételnek sem tesznek eleget -
Apollo17hu
őstag
válasz spammer #1233 üzenetére
Ha sima SQL lenne, akkor ennyi elég lenne:
SELECT column_name
FROM information_schema.columns
WHERE table_name='colors'
AND column_name LIKE 'color%'szerk.: Most nézem, hogy neked nemcsak a mezőnevek, hanem attribútumok is kellenének. Ha ezek az attribútumok benne vannak az information_schema.columns táblában, akkor elég felsorolnod őket, ha nem akkor a FROM után sorold fel az érintett táblákat, WHERE-ben pedig kösd össze őket.
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz Brown ügynök #1246 üzenetére
A LEFT JOIN miatt van: a stok_intake tábla minden rekordja bekerül. Használj helyette INNER JOIN-t, ami a táblák metszetét adja eredményül.
-
Apollo17hu
őstag
válasz Brown ügynök #1248 üzenetére
Akkor a stock_product_history táblában nincs olyan rekord, ahol az intake_id beköti a stock_intake, a reservation_id pedig a stock_reservation táblát.
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz Brown ügynök #1250 üzenetére
Kellene egy mező, ami megmondja, hogy a stock_product_history táblában mely intake_id-k mely reservation_id-kkal vannak kapcsolatban. (Kapcsolat esetén a mező értékének egyeznie kell a két rekordnál.)
Szerintem ezt lehet egyszerűsíteni, de nem teljesen értem, hogy mi a végcél. Talán egy olyan táblából kellene kiindulni, ahol az intake_id és a reservation_id egy soron szerepelnek, és csak akkor vannak töltve, ha a tényleges esemény (bevitel vagy foglalás) megtörtént. Nem tudom, hogy az események között van-e valamiféle időbeli sorrendiség, de előfordulhat, hogy mondjuk volt már foglalás, de azt nem vitték még be (ekkor utóbbi értéke null). Vagy az intake nem erre vonatkozik?
Ha ez tisztázódott, utána lehet a product, store stb. mezőket hozzáadni a modellhez.
-
Apollo17hu
őstag
válasz Brown ügynök #1253 üzenetére
Akkor szerintem 2 tábla kellene:
BEVITEL: termék | mikor | mennyit
FOGLALÁS: termék | mikor | mennyitEzeket "termék"-en keresztül kötöd össze, a két "mikor"-ra szűrsz, a "mennyit" mezőt pedig aggregálod (GROUP BY).
Egy táblában is meg lehetne oldani (ahogy neked most a főtáblád tárolja az adatokat) kötések nélkül:
TÁBLA: termék | bevitel_mikor | bevitel_mennyit | foglalás_mikor | foglalás_mennyit
Ebben az esetben viszont vagy a "bevitel_mikor" és "bevitel_mennyit" vagy a "foglalás_mikor" és "foglalás_mennyit" mezők értéke lenne null, tehát feleslegesen nőne az adatbázis mérete.
A lényeg, hogy termékazonosítón keresztül lenne célszerű kötni.
-
Apollo17hu
őstag
válasz Brown ügynök #1256 üzenetére
Első ránézésre nem igazán menő, hogy IN után allekérdezést használsz. Ha kicsit több időm lesz, megnézem a kódot, de ha az eredmény jó neked, akkor nagy gond nem lehet.
-
Apollo17hu
őstag
válasz Brown ügynök #1256 üzenetére
A stock_intake_item és a stock_intake táblát összevonhatnád. Utóbbi csak egy időpecsétet tartalmaz, felesleges szétszedni. Lenne a kettőből egy táblád, ami megmutatja, hogy adott napon adott termékből hány darab került be.
Hasonlóan kellene tenni a stock_reservation_item és stock_reservation táblákkal.
IN helyett elvileg JOIN-olhattad volna a stock_intake táblát. Úgy, ahogy a stock_reservation táblát is bekötötted.
-
Apollo17hu
őstag
válasz szmegma #1317 üzenetére
Megpróbáltam elgondolkodni rajta, de már ott elakadtam, hogy a szöveges leírás hogy passzol a példaértékekhez. A dátumokat honnan veszed? Bele van passzintva az azonosítókba? Ha igen, milyen szabály alapján? Szerintem több mezőben kellene tárolni az adatokat, de lehet, hogy csak én nem látom át...
-
Apollo17hu
őstag
válasz szmegma #1321 üzenetére
tisztább valamivel...
Én talán úgy csinálnám, hogy minden munkáshoz meghatároznám a szabad idő-intervallumokat (a +/-1 óra korrekcióval). Ez start_date és end_date párokat jelentene. Ezeket összesíteném (UNION?), majd erre az összesített halmazra futtatnám le a keresést, ami abból állna, hogy a kiválasztott időpont beleesik-e valamelyik intervallumba vagy sem. Ha igen, akkor nincs szabad időpont, ha nem (NULL), akkor van.
Az ismétlődéssel gondban vagyok. Azt valahogy úgy lehetne beépíteni, hogy az előre vizsgált pl. 1 hónapot le kell osztani azoknak a napoknak a számával, ami két ismétlés között eltelik, majd a hányadost kell felhasználni, de nem látom, hogy lehetne beépíteni a modellbe.
-
Apollo17hu
őstag
válasz szmegma #1327 üzenetére
Hát, ez sokkal bonyolultabb (legalábbis azon az úton, ahogy elindultunk), mint gondoltam.
A "munkás, munkaidő_start, munkaidő_end, foglalt_start, foglalt_end" listában minden sorra meghatároznám (segédoszloppal), hogy az adott sorban lehetséges-e a kívánt munkát (időpont alapján) végezni (IF, AND és OR megfelelő kombinációjával). Ezután munkások munkanapjaiként csoportokat készítenék analitikus függvénnyel, ami megmutatná, hogy adott munkás adott munkanapján van-e ütközés (az előbb létrehozott segédoszlop). Ahol nincs ütközés, azt a munkást, és azt a napot adná vissza az eredmény...
De néztem, hogy natural join-t használtál. (Eddig nem is hallottam róla.) Ha tényleg ennyire 0-ról indulsz, akkor ez nagyon necces. Ha valahogy össze is tudnánk rakni a modellt, lehet, hogy baromi lassan futna a lekérdezés, optimalizálásban pedig nem vagyok jártas...
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz szmegma #1338 üzenetére
MySQL-t nem vágom, de mezei SQL-ben vhogy így nézne ki:
SELECT munkás
,munkaidő_start
,munkaidő_end
,foglalt_start
,foglalt_end
,CASE
WHEN foglalt_start < vizsgált_időpont AND foglalt_end > vizsgált_időpont THEN
'x'
END AS segédoszlop
FROM [táblák]
WHERE [táblák kötése]
AND munkaidő_start < vizsgált_időpont
AND munkaidő_end > vizsgált_időpontSegédoszlop -ban 'x'-szel jelölöd, ha a munkás a vizsgált_időpont -ban foglalt.
A kód végén lévő két feltétel pedig csak azokat a munkásokat szűri, akiknek a munkaidejére esik a vizsgált_időpont.Az így kapott listában meg kell nézned, hogy van-e olyan munkás, akinél a segédoszlop értéke minden esetben NULL (vagyis egyik meglévő melója sem akadna a vizsgált_időpont -tal). Ehhez a fenti kódot allekérdezésbe kell majd rakni, és analitikus függvényt kell használni rá.
-
Apollo17hu
őstag
válasz szmegma #1340 üzenetére
A MySQL szintaxist nem ismerem, meg kéne próbálni, hogy a CASE WHEN-be először csak az egyik feltételt adod meg, és megnézni, hogy úgy kapsz-e TRUE értékeket. Ha nem, akkor valószínűleg nem tudja összehasonlítani a két időértéket, tehát az egyik valószínűleg nem time típusú változó.
Nekem az a furcsa, hogy a workers_start_hour -t és a workers_start_end -et ugyanebben a lekérdezésben generálod. Lehet, hogy ezek a CASE WHEN -ben még nem léteznek, ezért nem is tud velük mit kezdeni. Esetleg e kettő helyett beírhatnád a fölöttük lévő képleteket [FROM_UNIXTIME(workers_starting,'%H%i')*1 és FROM_UNIXTIME(workers_finishing,'%H%i')*1].
-
Apollo17hu
őstag
válasz szmegma #1342 üzenetére
Várjál, ez így még nem biztos, hogy jó. Nézem az új kódod: abban a workers_starting és workers_finishing mit jelent? A teljes vagy csak a foglalt munkaidő kezdetét és végét? Ha utóbbit, akkor jó, ha előbbit, akkor ki kell cserélni, mert a foglalt munkaidőt kell összevetni a checking_time -mal.
Ezután a lekérdezésed végére még szükség van WHERE-re, hogy csak azok a rekordok maradjanak a listádban, ahol a munkás teljes munkaidejébe beleesik-e a checking_time.
Vmi ilyesmi kell tehát a lekérdezésed végére:
WHERE teljes_munkaido_start < checking_time AND teljes_munkaido_end > checking_time
Ha pedig ezzel is kész vagy, egy olyan listát kapsz, amiben csak azok a munkások jelennek meg, akiknek a munkaidejére esik a checking_time. A munkásokhoz annyi rekord fog tartozni, ahány munkájuk van. Ha ezekből a munkákból akár csak egynél is 'x' szerepel a segédoszlopban, akkor a munkás foglalt.
-
Apollo17hu
őstag
válasz szmegma #1347 üzenetére
Ha jol ertem, akkor ez mar CSAK ["oszlop"]=>"true" erteku munkast dob vissza? Magyarul aki biztos nem er ra.
Nem, ["oszlop"] értéke lehet "false" is, ami azt jelenti, hogy a munkásnak ez a munkája nem ütközne abba a munkába, amit rá akarunk sózni. Viszont a munkásnak több munkája is van, és ha csak egynél is "true" értéket kapsz, az fogja azt jelenteni, hogy a munkásnak van olyan munkája, ami üti a rásózandó melót. De át is írhatod a "true" és a "false" értékeket pl. "not feasible" és NULL -ra vagy bármire, hogy hangsúlyosabban látszódjon.
Idokozben kiderult itt egy ujabb dolog. Megpedig, hogy nem csak egyetlen idopontot kell vizsgalnia a keresnek, hanem ido intervallumot.
Ezt úgy kellene megoldani, hogy az intervallum kezdetét és végét tárolod. Tehát mondjuk checking_start és checking_end meződ van. Az ["oszlop"] meződet kell csak módosítanod (ennek is adhatnál mondjuk egy ["check_worker_time"] vagy bármilyen, beszédes nevet) úgy, hogy a checking_start -ot a workers_start_hour -hoz, a checking_end -et pedig a workers_end_hour -hoz viszonyítod.
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz szmegma #1347 üzenetére
Gondolkodtam, hogyan kellene továbbhaladni. Lehet, hogy túlbonyolítom, de 2 halmazt (lekérdezést) kellene alkotni. Az eddigiekhez képest módosítani kell a meglévő lekérdezésen, lejjebb írom, hogyan:
1. azon munkások, akik munkaidején belülre esik a vizsgálandó időintervallum
2. minden munkás minden munkavégzését minősíteni aszerint, hogy üti-e a vizsgált intervallumot -> ["oszlop"]Az elsőnek vhogy így kell kinéznie:
SELECT DISTINCT workers_id
FROM ...
WHERE munkaido_start < checking_start AND munkaido_end > checking_endEz csak a munkások azonosítóit adja vissza, semmi mást, és másra nincs is szükség.
A második pedig az eddig megírt lekérdezésed módosítása. Annyit kell átírnod benne, hogy a WHERE -ből kitörlöd az eddigi szűréseket, helyette pedig beírod a CASE WHEN tartalmát (és így egyúttal az ["oszlop"] segédoszlopot ki is törölheted). Tehát így:
SELECT DISTINCT workers_id
FROM ...
WHERE munkafolyamat_start < checking_tart AND munkafolyamat_end > checking_endEz csak azokat a munkásokat listázza, akik már foglaltak a vizsgált intervallumot tekintve.
Ha sikerült előállítani a fenti két lekérdezést, akkor LEFT (vagy RIGHT) JOIN-nal kösd össze őket! Az 1. halmazból "kivonva" a 2. halmazt azokat a munkásokat kapod, akik ráérnek a vizsgált időpontban.
Így:
SELECT munkaideje_megfelel.workers_id
FROM (első lekérdezés kódja) AS munkaideje_megfelel
LEFT JOIN (második lekérdezés kódja) AS munkafolyamatat_uti
ON munkaideje_megfelel.workers_id = munkafolyamatat_uti.workers_id
WHERE munkafolyamatat_uti.workers_id IS NULLA JOIN-okban nem vagyok biztos, én más szintaktikát szoktam használni, de a lényeg sztem látszik.
Ha ez kész, akkor írom, hogyan csapd a workers_id mellé a szükséges infót (de erre már te is rá tudsz jönni).
-
Apollo17hu
őstag
válasz szmegma #1350 üzenetére
Igazad van. Az a probléma, hogy én csak arra gondoltam, hogy a vizsgálandó intervallum beleesik-e a már foglalt időintervallumba. Lehet viszont olyan eset is, amikor csak átfedés van.
Módosítsd úgy a feltételt, hogy a foglalt jelzést a következő jelentse:
(workers_start_timestamp > desired_start_time AND workers_start_timestamp < estimated_completion_time)
OR
(workers_finish_timestamp > desired_start_time AND workers_finish_timestamp < estimated_completion_time)Ennek már jónak kell lennie.
-
Apollo17hu
őstag
ez a feladat pl. arra is lefordithato, hogy generaljunk szamokat 1-31-ig es adjunk hozza ennyi napot a mostani datumhoz, ami tisztan SQL lenne
Pont ezt javasoltam neki én is, lévén MySQL-hez nem konyítok.
Az az Oracle-s kód a hsz.-ed végén tetszik, köszi. (Én mindig egy számokat tartalmazó segédtáblával oldottam meg eddig a hasonló problémákat.)
-
Apollo17hu
őstag
SELECT tabla_1.col1
,tabla_2.col2
,MIN(CASE
WHEN tabla_1.col_1 >= tabla_2.col_1 AND tabla_1.col_2 <= tabla_2.col_2 THEN
'I'
ELSE
'N'
END) flag
FROM tabla_1
,tabla_2
GROUP BY tabla_1.col1
,tabla_2.col2Itt nem 'TRUE' jelenik meg, hanem 'I', ha a 2. táblában legalább egy olyan tartomány van, amibe beleesik, 'N' pedig, ha nincs ilyen tartomány.
Nem ellenőriztem, próbálgasd...
Az elv az, hogy a Descartes-szorzatot a MIN() függvénnyel redukálod (méghozzá az 1. táblában szereplő sorok számára). A MIN() azért jó, mert az 'I' karakter előbb van az ABC-ben mint az 'N' karakter.
-
Apollo17hu
őstag
Akkor átírva a fentit ez jó?
SELECT t2.range_from
,t2.range_to
,MIN(CASE
WHEN t2.range_from >= t1.range_from AND t2.range_to <= t1.range_to THEN
'I'
ELSE
'N'
END) flag
FROM t1
,t2
GROUP BY t2.range_from
,t2.range_toszerk.: Tényleg jó a Fiddle, külön öröm, hogy van benne kódformázás is.
[ Szerkesztve ]
-
Apollo17hu
őstag
válasz cidalain #1491 üzenetére
valid id lastvalue
val1 4 ló
val2 3 3
val3 5 12345Ez a kimenet szerintem nem megvalósítható, mert a lastvalue mezőben eltérő adattípusok szerepelnének.
Helyette a másik kimenetre egy megoldás:
SELECT s.id, s.val1, "" AS val2, "" AS val3
FROM (SELECT max(id) AS last_id
FROM sample
WHERE val1 <> "") t
,sample s
WHERE s.id = t.last_id
UNION
SELECT s.id, "" AS val1, s.val2 AS val2, "" AS val3
FROM (SELECT max(id) AS last_id
FROM sample
WHERE val2 <> "") t
,sample s
WHERE s.id = t.last_id
UNION
SELECT s.id, "" AS val1, "" AS val2, s.val3 AS val3
FROM (SELECT max(id) AS last_id
FROM sample
WHERE val3 <> "") t
,sample s
WHERE s.id = t.last_id