- Motorola Edge 40 - jó bőr
- Bemutatkozott a Fairphone 6
- Samsung Galaxy Watch7 - kötelező kör
- Megjelent a Poco F7, eurós ára is van már
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Honor Magic V2 - origami
- iPhone topik
- Xiaomi 14 - párátlanul jó lehetne
- Hammer 6 LTE - ne butáskodj!
- Eltűnhet a Dinamikus Sziget
Új hozzászólás Aktív témák
-
#2095
Apollo17hu
őstag
bozsozso
#2094
Apollo17hu
őstag
válasz
bozsozso
#2094
üzenetére
Dátumformátumra a DATE_FORMAT(), előnullázásra pedig az LPAD() függvényt tudod használni. MySQL-t nem ismerem, de szerintem ott is elvárás, hogy az oszlopnév első karaktere csak szöveges lehet.
-
#2076
Apollo17hu
őstag
laracroft
#2075
Apollo17hu
őstag
-
#2002
Apollo17hu
őstag
laracroft
#2001
Apollo17hu
őstag
válasz
laracroft
#2001
üzenetére
Nem ismerem a MySQL szintaktikát, de úgy lehetne, hogy rászűrsz name = 'Hát Izsák' -ra, a kapott rekordok mellé pedig számlálót képzel analitikus függvénnyel [rank(), rownum() stb.] a datetime mező csökkenő sorrendje szerint. Ha ez kész, akkor a számláló 1-es és 2-es értékét tartod meg, ezt a két dátumot kell kivonnod egymásból (előbbiből az utóbbit).
-
#1997
Apollo17hu
őstag
MineFox54
#1996
Apollo17hu
őstag
válasz
MineFox54
#1996
üzenetére
SELECT
SUM(CASE WHEN keresett = 7 THEN 1 ELSE 0 END) AS "7cnt",
SUM(CASE WHEN keresett = 14 THEN 1 ELSE 0 END) AS "14cnt",
SUM(CASE WHEN keresett = 22 THEN 1 ELSE 0 END) AS "22cnt"
FROM tabla...vagy próbálkozhatsz a PIVOT funkcióval is.
Amúgy biztos nem egy mezei
GROUP BY keresett-re lenne szükséged? -
#1970
Apollo17hu
őstag
Keem1
#1968
Apollo17hu
őstag
Szia!
Még annyi, hogy az OR operátor használata bizonyos esetekben lassíthatja a leválogatást, ezért - ahol lehet - célszerű CASE WHEN -nel kiváltani. Pl. így:
SELECT * FROM tabla WHERE
CASE
WHEN mezo2=0 AND mezo1 LIKE 'kifejezes%' THEN 1
WHEN mezo2=1 AND mezo1 LIKE 'kifejezes' THEN 1
END = 1 -
#1873
Apollo17hu
őstag
Headless
#1872
Apollo17hu
őstag
válasz
Headless
#1872
üzenetére
Hát akkor kösd gyengén. LEFT JOIN vagy valami ilyesminek hívják...
Annál a júzernél, akinek nincs tapasztalata, üres lesz a mező.SQL-ben valahogy így nézne ki:
SELECT DISTINCT project_candidates.project_id
,users.name
,LISTAGG(experiences.experience, ', ') WITHIN GROUP (ORDER BY experiences.experience) OVER (PARTITION BY users.id) AS "experience_list"
FROM project_candidates
,users
,experiences
WHERE 1=1
and project_candidates.user_id = users.id
and users.id = experiences.user_id(+) -
#1871
Apollo17hu
őstag
Headless
#1869
Apollo17hu
őstag
válasz
Headless
#1869
üzenetére
Ha minden usered rendelkezik legalább egy tapasztalattal (experience), akkor a 3. táblát hozzákötheted erősen a másik kettőhöz, majd az experience mezőből ezzel egy szeparátorral elválasztott felsorolás mezőt tudsz képezni. Azt tudom, hogy mezei sql-ben kell egy DISTINCT ilyenkor még a lekérdezésbe. Mysql-t nem vágom.
-
#1833
Apollo17hu
őstag
Chesterfield
#1832
Apollo17hu
őstag
válasz
Chesterfield
#1832
üzenetére
SELECT city.Name,
CASE WHEN city.ID = country.Capital THEN country.Name END
from world.city
left join world.country
on city.CountryCode = country.Code; -
#1831
Apollo17hu
őstag
Chesterfield
#1830
Apollo17hu
őstag
válasz
Chesterfield
#1830
üzenetére
Ha törlöd a WHERE záradékot, akkor listázza mindet.
-
#1788
Apollo17hu
őstag
NoX
#1786
Apollo17hu
őstag
Ha az "adatok" mező minden egyes rekordban tartalmazza az 'Iskolai végzettség:', 'Foglalkozás:', 'Anyja neve:' és 'Szem.ig.sz:' karaktersorozatokat, akkor az INSTR() függvénnyel meg tudod keresni, hányadik karakter az 'Anyja neve:' kezdete, hányadik a 'Szem.ig.sz:' kezdete, a kettő közötti karaktersorozatot pedig SUBSTR() függvénnyel ki tudod vágni. Ez lesz az anyja neve (amiből az 'Anyja neve:' karaktersorozat levágása már egy fokkal egyszerűbb).
-
#1784
Apollo17hu
őstag
laracroft
#1781
Apollo17hu
őstag
válasz
laracroft
#1781
üzenetére
Azon rekordokat keresem, akinek a COMP táblájának ZONE1-ZONE16 mezőjeiben szerepel a PROC szó ÉS a 16 zónából 5-nél kevesebb mezőben van egyáltalán valamilyen érték (Nem csak PROC szó szerepelhet a mezőkben)
...
WHERE COMP.ZONE1 || "." ||
COMP.ZONE2 || "." ||
COMP.ZONE3 || "." ||
COMP.ZONE4 || "." ||
COMP.ZONE5 || "." ||
COMP.ZONE6 || "." ||
COMP.ZONE7 || "." ||
COMP.ZONE8 || "." ||
COMP.ZONE9 || "." ||
COMP.ZONE10 || "." ||
COMP.ZONE11 || "." ||
COMP.ZONE12 || "." ||
COMP.ZONE13 || "." ||
COMP.ZONE14 || "." ||
COMP.ZONE15 || "." ||
COMP.ZONE16 LIKE "%PROC%" AND
CASE WHEN COMP.ZONE1 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE2 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE3 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE4 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE5 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE6 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE7 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE8 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE9 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE10 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE11 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE12 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE13 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE14 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE15 IS NOT NULL THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE16 IS NOT NULL THEN 1 ELSE 0 END < 5 -
#1777
Apollo17hu
őstag
laracroft
#1776
Apollo17hu
őstag
válasz
laracroft
#1776
üzenetére
Nem tudom, hogy mysql-ben van-e CASE WHEN, de ha igen, akkor:
WHERE
...
CASE WHEN COMP.ZONE1 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE2 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE3 LIKE "%PROC%" THEN 1 ELSE 0 END +
...
CASE WHEN COMP.ZONE16 LIKE "%PROC%" THEN 1 ELSE 0 END < 5...tehát képzel egy 16 tagú összeget, és megnézed, hogy kisebb-e 5-nél.
-
#1726
Apollo17hu
őstag
don_peter
#1725
Apollo17hu
őstag
válasz
don_peter
#1725
üzenetére
Az előbb lehet, hogy részben hülyeséget írtam, de valahogy így gondoltam:
SELECT c.* FROM
((SELECT a.id, a.title, a.datum, a.nick FROM
(SELECT t.id,
t.title,
fu.datum,
u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON t.id = fu.topik_id
JOIN users u
ON u.id = fu.user_id
WHERE t.topik_csoport_id = 9) AS a
GROUP BY a.id) b
UNION
(SELECT t.id, t.title, 1000-01-01 as datum, NULL as nick FROM topik t) seged) c
GROUP BY c.id
ORDER BY c.datum DESC...tehát minden topikhoz létrehozol egy 1000-01-01 dátumra vonatkozó hsz.-t, ami csak akkor számít a sorrendben, ha nincs rajta kívül más hsz. (tehát ha üres a fórumtéma).
-
#1724
Apollo17hu
őstag
Apollo17hu
őstag
Ha van UNION utasítás MySQL-ben, akkor megoldás lehet, hogy összefűzöd egy olyan lekérdezéssel, amiben minden topik szerepel, de mondjuk 999999-es id-val (amit konstansként adsz meg).
Vagy átírod az egészet úgy, hogy a topikhoz kötöd gyengén a dolgokat, nem pedig azt kötöd gyengén a hsz.-ekhez.
-
#1715
Apollo17hu
őstag
don_peter
#1714
Apollo17hu
őstag
válasz
don_peter
#1714
üzenetére
Akkor két allekérdezés kell:
- az egyikben listázod topikonként a legfrissebb hsz.-ek dátumát,
- a másikban pedig leszeded topikonként a userek legfrissebb hsz.-eit.Ezt a kettőt topik-topik és dátum-dátum kötéssel kötve ezt kapod:
SELECT topik_datum.title,
topik_user_datum.nev,
topik_datum.updatum
FROM (SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.title) AS topik_datum,
(SELECT t.id AS tid,
u.nick AS nev,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id
GROUP BY t.id,
u.id) AS topik_user_datum
WHERE topik_datum.tid = topik_user_datum.tid
AND topik_datum.updatum = topik_user_datum.updatum
ORDER BY topik_datum.updatum DESC LIMIT 8Hogy milyen gyorsan fut le, az jó kérdés, de analitikus függvények nélkül ennél jobbat nem tudok.
-
#1711
Apollo17hu
őstag
don_peter
#1709
Apollo17hu
őstag
-
#1707
Apollo17hu
őstag
don_peter
#1706
Apollo17hu
őstag
válasz
don_peter
#1706
üzenetére
MySQL tud analitikus függvényeket? Ha igen, akkor én valahogy így csinálnám:
SELECT x.*
FROM (SELECT t.id AS tid,
t.title AS title,
fu.datum AS updatum,
u.nick AS nev
rank() OVER (PARTITION BY t.id ORDER BY fu.datum DESC) AS sorrend
FROM forum_uzenetek AS fu,
topik AS t,
users AS u
WHERE fu.topik_id = t.id
AND u.id = fu.user_id) AS x
WHERE x.sorrend = 1Amúgy az a nyolcas limit mi akar lenni a lekérdezéseidben?
-
#1704
Apollo17hu
őstag
don_peter
#1698
Apollo17hu
őstag
válasz
don_peter
#1698
üzenetére
Ha topikonként a legfrissebb bejegyzésre van szükséged, akkor valahogy így kellene:
SELECT t.id AS tid,
t.title AS title,
MAX(fu.datum) AS updatum
FROM forum_uzenetek AS fu,
topik AS t
WHERE fu.topik_id = t.id
GROUP BY t.id,
t.titleEz mondjuk nem MySQL, de a kétszeri sorbarendezést (ORDER BY) kiváltja egy aggregáló függvény, ami valószínűleg gyorsít rajta.
-
#1501
Apollo17hu
őstag
cidalain
#1499
Apollo17hu
őstag
válasz
cidalain
#1499
üzenetére
Optimalizáláshoz nem értek, de munkahelyemen előfordul, hogy aktuális devizaértékekkel kell számolni.
Ehhez egy olyan táblánk van, ami minden nap eltárolja a napi középárfolyamokat. Lényegében úgy néz ki a tábla, mint a te átgondolt táblád, csak nem percenként van szükség az árfolyamra, hanem naponta.
-
#1496
Apollo17hu
őstag
cidalain
#1491
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 -
#1442
Apollo17hu
őstag
Jim-Y
#1441
-
#1395
Apollo17hu
őstag
Jim-Y
#1394
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.
-
#1392
Apollo17hu
őstag
Jim-Y
#1390
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.
-
#1378
Apollo17hu
őstag
bpx
#1377
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.)
-
#1351
Apollo17hu
őstag
szmegma
#1350
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.
-
#1349
Apollo17hu
őstag
szmegma
#1347
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).
-
#1348
Apollo17hu
őstag
szmegma
#1347
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.
-
#1343
Apollo17hu
őstag
szmegma
#1342
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.
-
#1341
Apollo17hu
őstag
szmegma
#1340
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].
-
#1339
Apollo17hu
őstag
szmegma
#1338
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á.
-
#1337
Apollo17hu
őstag
szmegma
#1327
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...
-
#1326
Apollo17hu
őstag
szmegma
#1321
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.
-
#1320
Apollo17hu
őstag
szmegma
#1317
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...
-
#1259
Apollo17hu
őstag
Brown ügynök
#1256
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.
-
#1258
Apollo17hu
őstag
Brown ügynök
#1256
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.
-
#1254
Apollo17hu
őstag
Brown ügynök
#1253
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.
-
#1252
Apollo17hu
őstag
Brown ügynök
#1250
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.
-
#1249
Apollo17hu
őstag
Brown ügynök
#1248
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.
-
#1247
Apollo17hu
őstag
Brown ügynök
#1246
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.
-
#1235
Apollo17hu
őstag
spammer
#1233
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.
-
#1225
Apollo17hu
őstag
laracroft
#1217
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 -
#1151
Apollo17hu
őstag
#68216320
#1147
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.
-
#1127
Apollo17hu
őstag
DanielK
#1126
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 -
#1058
Apollo17hu
őstag
laracroft
#1044
Apollo17hu
őstag
-
#1039
Apollo17hu
őstag
laracroft
#1034
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ó.
-
#1002
Apollo17hu
őstag
laracroft
#998
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 -
#1001
Apollo17hu
őstag
laracroft
#998
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ó?
-
#995
Apollo17hu
őstag
laracroft
#992
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 -
#880
Apollo17hu
őstag
Speeedfire
#879
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.
-
#878
Apollo17hu
őstag
Speeedfire
#877
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. -
#876
Apollo17hu
őstag
Speeedfire
#875
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.
-
#874
Apollo17hu
őstag
Speeedfire
#869
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 -
#867
Apollo17hu
őstag
Speeedfire
#866
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.
-
#865
Apollo17hu
őstag
Speeedfire
#864
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.
-
#828
Apollo17hu
őstag
Soak
#827
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!
-
#822
Apollo17hu
őstag
Apollo17hu
#821
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? -
#819
Apollo17hu
őstag
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?
Új hozzászólás Aktív témák
Hirdetés
- Okos Otthon / Smart Home
- S.T.A.L.K.E.R. 2: Heart of Chornobyl
- Mobilinternet
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Parfüm topik
- Mibe tegyem a megtakarításaimat?
- sziku69: Fűzzük össze a szavakat :)
- Diablo IV
- One otthoni szolgáltatások (TV, internet, telefon)
- Motorola Edge 40 - jó bőr
- További aktív témák...
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
- LG 25GR75FG - E-Sport Monitor - FHD 360Hz 1ms - NVIDIA Reflex + G-sync - AMD FreeSync - HDR 400
- Samsung Galaxy S23 Plus 256 GB Kártyafüggetlen 1Év Garanciával
- 119 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!) (ELKELT)
- Xiaomi Redmi Note 14 Pro 256GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest