- Android alkalmazások - szoftver kibeszélő topik
- 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
Új hozzászólás Aktív témák
-
#2100
bozsozso
őstag
Apollo17hu
#2099
bozsozso
őstag
válasz
Apollo17hu
#2099
üzenetére
Na meg is van, köszönöm a segítséget, mert Te jutattál el a megoldáshoz:
SELECT date_format(STR_TO_DATE("28.01.2020", "%d.%m.%Y"),"%Y%m%d");Eredmény:20200128
Nagyon nagy segítség volt a linkelt függvény oldal ahol ki is tudtam próbálni. Nem ismertem ezt az oldalt.
-
#2098
bozsozso
őstag
Apollo17hu
#2097
bozsozso
őstag
válasz
Apollo17hu
#2097
üzenetére
Ez működik csak mint írtam nekem a dátum ilyen formában van az adatbázisban:
28.01.2020 -
#2096
bozsozso
őstag
Apollo17hu
#2095
bozsozso
őstag
válasz
Apollo17hu
#2095
üzenetére
Köszönöm az LPAD függvény az jó lesz, de a DATE_FORMAT-nál nem tudok rájönni hogyan tudnám megfordítani a dátumot. Ugyanis a nekem nap.hónap.év formában van. Jó lenne ez is ha meg tudnám fordítani a dátumot.
-
#2003
laracroft
senior tag
Apollo17hu
#2002
laracroft
senior tag
válasz
Apollo17hu
#2002
üzenetére
Köszönöm a gyors választ
Értem a lényeget, de sajnos az egymásba ágyazott szintaktikához is elég koki vagyok
Amit elértem az csupán az, hogy sorrendbe tudtam rakni a rekordokat úgy, hogy lássam melyik rekordot kell kivonnom (1.) melyikből (2.) .SET @sor_szam = 0;
select ACCOUNT,DATETIME, (@sor_szam:=@sor_szam + 1) AS num from NAPLO
where ACCOUNT='2801'
ORDER BY DATETIME descErre kérnék még tőletek segítséget.
köszi -
#1999
MineFox54
őstag
Apollo17hu
#1997
MineFox54
őstag
válasz
Apollo17hu
#1997
üzenetére
Köszönöm.
Nos, lenne még egy kérdésem.
Azt kellene megtudnom hogy az éppen vizsgált sor hányadik helyen szerepel, ha a táblát szűrjük bizonyos feltételekre.Tehát kifejtve:
tábla:id|sorrendalkoto|feltétel
1|1250|false
2|1235|true
3|1345|true
4|561|false
5|6235|trueTegyük fel, van egy select-em, amivel ebből a táblából olvasok adatokat. Ebbe a selectbe szeretnék generálni egy olyan mezőt, amellyel megtudom, hogy: egy
WHERE feltétel=true ORDER BY sorrendalkoto descfeltételek alapján hanyadik helyen szerepel a táblában. Fontos lenne hogy on-the-run működjön a dolog.
Várt result:id|sorrendalkoto|helyezés
5|6235|1 -
#1998
MineFox54
őstag
Apollo17hu
#1997
MineFox54
őstag
válasz
Apollo17hu
#1997
üzenetére
Igen, a GROUP BY megoldás, de a feldolgozási oldalon macerásabb (nem csak egy echo-ba megy
). Mindegy, megcsináltam, így marad. -
#1971
Keem1
veterán
Apollo17hu
#1970
Keem1
veterán
válasz
Apollo17hu
#1970
üzenetére
Mindig tanul az ember valamit!
-
#1880
Headless
őstag
Apollo17hu
#1879
Headless
őstag
válasz
Apollo17hu
#1879
üzenetére
Mint írtam megeshet, hogy nem lesz experience, viszont nem egészen így képzeltem el, nem akarnám listába rakni a projekt neveket. De holnap tanulmányozom jobban, hogy tanulhassak is belőle.
-
#1878
Headless
őstag
Apollo17hu
#1877
Headless
őstag
válasz
Apollo17hu
#1877
üzenetére
Igen rájöttem. Szerkesztés lejárt.
-
#1872
Headless
őstag
Apollo17hu
#1871
Headless
őstag
válasz
Apollo17hu
#1871
üzenetére
Sajnos nincs minden felhasználónak tapasztalata így akkor ez nem opció ha jól gondolom. Pedig pontosan valami ilyesmit szerettem volna.
Chesterfield: Ez pontosan ugyanazt adja vissza amit írtam is, de ez nem az amire gondoltam.
-
#1834
Chesterfield
őstag
Apollo17hu
#1833
Chesterfield
őstag
válasz
Apollo17hu
#1833
üzenetére
Köszi, lenne még egy kérdésem
Hogy tudnám itt csak az évszámot kilistázni?
SELECT IndepYear, count(IndepYear) FROM world.country
group by IndepYear order by count(IndepYear) desc limit 1;Mert most az évszámot, és a countot is megkapom.
-
#1832
Chesterfield
őstag
Apollo17hu
#1831
Chesterfield
őstag
válasz
Apollo17hu
#1831
üzenetére
Inkább elmondom, hogy mit szeretnék:
listázza az összes várost, és azoknál a városoknál, amik fővárosok, írja ki az országnevet is. -
#1803
biker
nagyúr
Apollo17hu
#1802
biker
nagyúr
válasz
Apollo17hu
#1802
üzenetére
Köszi a tippet
Nem szép, de legalább ocsmány, és működik
timestamp>>dátum:óra:perc>>levágás>>időlevonás>>unixtimeUPDATE fitness_users_berletek SET berlet_erv =
(UNIX_TIMESTAMP(DATE_ADD(DATE(DATE_FORMAT(FROM_UNIXTIME(`berlet_erv`), '%Y-%m-%d %H:%i:%s')), INTERVAL - 61 MINUTE))) -
#1785
martonx
veterán
Apollo17hu
#1784
martonx
veterán
válasz
Apollo17hu
#1784
üzenetére
A tökéletes példa arra, hogy miért nem így kellett volna a táblát felépíteni, hanem egy a többhöz kapcsolattal külön táblába tenni a Zone-okat.
-
#1781
laracroft
senior tag
Apollo17hu
#1777
laracroft
senior tag
válasz
Apollo17hu
#1777
üzenetére
Szia!
Kipróbáltam a kódot, de sajnos nem tűnik jónak
Olyan rekordokat is kiad, amelyeknek több mint 5 zónájuk is ki van töltve.
Közben rájöttem, hogy nem voltam teljesen korrekt a feladat leírásában sem, bocsánat.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)
Így nézett ki most a lekérdezés: (Így gondoltad?)
SELECT
UGYFEL.LINE AS VONAL,
UGYFEL.COMPSZAM AS COMPSZAM,
UGYFEL.NAME1 AS NEV,
UGYFEL.ADDRESS3 AS IRSZAM,
UGYFEL.ADDRESS1 AS VAROS,
UGYFEL.ADDRESS2 AS UTCA
from UGYFEL
LEFT JOIN COMP
ON UGYFEL.LINE = COMP.LINE
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.ZONE4 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE5 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE6 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE7 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE8 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE9 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE10 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE11 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE12 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE13 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE14 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE15 LIKE "%PROC%" THEN 1 ELSE 0 END +
CASE WHEN COMP.ZONE16 LIKE "%PROC%" THEN 1 ELSE 0 END < 5)
order by VONAL -
#1780
laracroft
senior tag
Apollo17hu
#1777
laracroft
senior tag
válasz
Apollo17hu
#1777
üzenetére
Köszi kipróbálom
-
#1727
don_peter
senior tag
Apollo17hu
#1726
don_peter
senior tag
válasz
Apollo17hu
#1726
üzenetére
Ez sajnos nem fut le, de értem a gondolat meneted..
Próbálkozom, hátha tudom javítani a kódot. -
#1725
don_peter
senior tag
Apollo17hu
#1724
don_peter
senior tag
válasz
Apollo17hu
#1724
üzenetére
Van UNION..
Utána nézek...
Ha van egy megoldásod, akkor az is jöhet..
Köszi.. -
#1716
don_peter
senior tag
Apollo17hu
#1715
don_peter
senior tag
válasz
Apollo17hu
#1715
üzenetére
Bár a lekérdezésed lefut és majdnem jó is csak valamiért szelektál.
Nem az összes bejegyzést figyeli.Most ezt írtam és használom ez jól működik, legalább is úgy tűnik:
SELECT * FROM
(SELECT t.id, t.title, fu.datum, u.nick
FROM forum_uzenetek fu
LEFT JOIN topik t
ON fu.topik_id = t.id
JOIN users u
ON u.id = fu.user_id
ORDER BY fu.datum DESC) AS a
GROUP BY id ORDER BY datum DESC LIMIT 8 -
#1714
don_peter
senior tag
Apollo17hu
#1712
don_peter
senior tag
válasz
Apollo17hu
#1712
üzenetére
Igen az nem jó, ezt én is tudom ezen tovább is léptem már.
Most már az egész lekérdezést nézem nem csak részleteket.
Sok a subselect és ez megnehezíti a lekérdezést. -
#1713
don_peter
senior tag
Apollo17hu
#1712
don_peter
senior tag
válasz
Apollo17hu
#1712
üzenetére
Makszimum 8 topik jelenik meg az utolsó bejegyzések alapján csökkenő sorban.
-
#1710
fordfairlane
veterán
Apollo17hu
#1707
fordfairlane
veterán
válasz
Apollo17hu
#1707
üzenetére
MySQL tud analitikus függvényeket?
Tudomásom szerint egyiket sem ismeri.
-
#1709
don_peter
senior tag
Apollo17hu
#1707
don_peter
senior tag
válasz
Apollo17hu
#1707
üzenetére
Ezt a nyelvet már nem ismeri.
Legalább is ebben a formában.
Köszi azért, el voltam vele kicsit
-
#1708
don_peter
senior tag
Apollo17hu
#1707
don_peter
senior tag
válasz
Apollo17hu
#1707
üzenetére
A limit 8 azt jelenti, hogy csak 8 record-ot kérjen le. Esetünkben a 8 legfrissebbet.
-
#1705
don_peter
senior tag
Apollo17hu
#1704
don_peter
senior tag
válasz
Apollo17hu
#1704
üzenetére
Köszönöm, ez így 3.8-4mp-ről 0.18-0.22mp-re csökkentette a lekérdezési időt.
A csoportosítást lehet még tovább bonyolítani?
Ha mondjuk még kíváncsi lennék a bejegyzést készítő felhasználó nevére? -
#1619
sonar
addikt
Apollo17hu
#1618
sonar
addikt
válasz
Apollo17hu
#1618
üzenetére
Ez a bajom, hogy nem engedi kétszer joinolni a tbl_team-et
SELECT * FROM tbl_meccs_summary
INNER JOIN tbl_team_table ON tbl_meccs_summary.home=tbl_team_table.id_team
INNER JOIN tbl_team_table ON tbl_meccs_summary.away=tbl_team_table.id_team
Error Code: 1066. Not unique table/alias: 'tbl_team_table' -
#1503
cidalain
veterán
Apollo17hu
#1501
cidalain
veterán
válasz
Apollo17hu
#1501
üzenetére
ja valószínűleg az lesz, az átgondolt tábla verzió, még egy kicsit finomítva
egyszerűbb kezelni sokkal, bár több bájt letárolni.
(nekem nem devizacuccokkat kell tárolni, csak ez volt egy nagyon hasonló példa)jelenleg van egy adott tábla formátum, de az egész rendszert újraírom, mert a legutóbbi koncepció már lassan 5 éves, és azóta egy csomó minden változott, és a jelenlegi verziójú adatbázis nem nagyon rugalmas.
és a rugalmasságot viszont csak az "átgondolt" szerkezetű táblával tudom biztosítani.
-
#1500
PazsitZ
addikt
Apollo17hu
#1496
PazsitZ
addikt
válasz
Apollo17hu
#1496
üzenetére
Ha kevés field van akkor végül is mehwet a union is. De szvsz én akkor már nem join-olgatnék subquery-t.
(SELECT id , val1 FROM sample WHERE val1 IS NOT NULL AND val1<>'' ORDER BY id DESC LIMIT 1)
UNION
(SELECT id , val2 FROM sample WHERE val2 IS NOT NULL AND val2<>'' ORDER BY id DESC LIMIT 1)
UNION
(SELECT id , val3 FROM sample WHERE val3 IS NOT NULL AND val3<>'' ORDER BY id DESC LIMIT 1)result:
4 ló
5 3
5 12345 -
#1497
cidalain
veterán
Apollo17hu
#1496
cidalain
veterán
válasz
Apollo17hu
#1496
üzenetére
"Ez a kimenet szerintem nem megvalósítható, mert a lastvalue mezőben eltérő adattípusok szerepelnének."
ezt nem értem, mert mindegyik val adat típusa VARCHAR(25).A másik jó, és azt csinálja amit gondolok, csak 6 darab select van benne.
annyiban különbözik ettől, hogy itt 3 result-ot kell feldolgozni, ott meg csak 1-et.SELECT id,val1 FROM sample
WHERE val1 <> ""
ORDER BY id DESC
LIMIT 1SELECT id,val2 FROM sample
WHERE val2 <> ""
ORDER BY id DESC
LIMIT 1SELECT id,val3 FROM sample
WHERE val3 <> ""
ORDER BY id DESC
LIMIT 1melyik optimálisabb? egy olyan adattáblán lenne használva amiben van 50-100.000 sor!
-
#1494
cidalain
veterán
Apollo17hu
#1493
cidalain
veterán
válasz
Apollo17hu
#1493
üzenetére
igen
-
#1443
Jim-Y
veterán
Apollo17hu
#1442
Jim-Y
veterán
válasz
Apollo17hu
#1442
üzenetére
Közben úgy próbálkozom, hogy
left outer joinnal hozzákötöttem a ranges (t2) táblát, majd megírom az eredményt, de cca 45 perc míg lefut a procedure
SELECT
R.range_id
,R.range_from
,R.range_to
,IFNULL(S.numbers,0) as numbers
FROM t2 R LEFT OUTER JOIN
(SELECT
...
FROM t1, t2) S ON S.range_id = R.range_id; -
#1396
Jim-Y
veterán
Apollo17hu
#1395
Jim-Y
veterán
válasz
Apollo17hu
#1395
üzenetére
Szia, igen jól működik köszönöm
http://sqlfiddle.com/#!2/588bd6/14 -
#1354
szmegma
aktív tag
Apollo17hu
#1351
szmegma
aktív tag
válasz
Apollo17hu
#1351
üzenetére
Kuldtem uzenetet.
-
#1350
szmegma
aktív tag
Apollo17hu
#1348
szmegma
aktív tag
válasz
Apollo17hu
#1348
üzenetére
Eloszor erre valaszolnek, mert lehet talaltam egy hibat a CASE-ben.
Azt szurjuk ugye, hogyworkers_finish_timestamp > estimated_completion_time
AND
workers_start_timestamp < desired_start_time
THEN => 'nem vallalhatja el' <= igaz, ha az AND elotti es utani resz IGAZ
ELSE => 'elvallalhatja' <= igaz, ha az AND elotti es/vagy utani resz HAMISDE! Ez nem minden esetben mutatja a helyes kimenetet (szabad vagy nem szabad a munkas). Pl.:
1, mukodik - kod szerint nem vallalhatja el es ez IGAZ
IF workers_start_timestamp(06:30) < desired_start_time(08:00) <= igaz
AND workers_finish_timestamp(11:30) > estimated_completion_time(10:00) <= igaz2, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(10:00) < desired_start_time(06:00) <= hamis
AND workers_finish_timestamp(15:00) > estimated_completion_time(07:00) <= igaz3, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(08:30) < desired_start_time(08:00) <= hamis
AND workers_finish_timestamp(14:30) > estimated_completion_time(11:00) <= igaz4, mukodik - kod szerint elvallalhatja es ez IGAZ
IF workers_start_timestamp(15:00) < desired_start_time(07:00) <= hamis
AND workers_finish_timestamp(17:00) > estimated_completion_time(13:00) <= igaz5, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(07:30) < desired_start_time(09:00) <= igaz
AND workers_finish_timestamp(10:30) > estimated_completion_time(15:00) <= hamis6, mukodik - kod szerint elvallalhatja es ez IGAZ
IF workers_start_timestamp(13:30) < desired_start_time(09:00) <= hamis
AND workers_finish_timestamp(17:30) > estimated_completion_time(11:00) <= igaz7, nem mukodik - kod szerint elvallalhatja es ez NEM IGAZ
IF workers_start_timestamp(16:00) < desired_start_time(16:00) <= hamis
AND workers_finish_timestamp(19:00) > estimated_completion_time(19:00) <= hamis8, mukodik - kod szerint elvallalhatja es ez IGAZ
IF workers_start_timestamp(12:30) < desired_start_time(10:30) <= hamis
AND workers_finish_timestamp(15:30) > estimated_completion_time(12:30) <= igazPapirra levezettem par peldat es melle irtam par kezdesi es befejezesi idopontot es a keplet ezek felet jol kezelte, a masik felet rosszul, azert is merultem el jobban benne.
Amit leirtam igazam van, vagy hulyeseget beszelek? -
#1347
szmegma
aktív tag
Apollo17hu
#1343
szmegma
aktív tag
válasz
Apollo17hu
#1343
üzenetére
...a workers_starting és workers_finishing mit jelent?
A workers_starting az a munkas elso foglalt idopontjat jelzi (pl., 2013-09-10 08:00:00), a workers_finishing pedig a munkas utolso foglalt idopontja (pl., 2013-09-10 11:00:00). Szoval ha csak o lenne egyedul a cegnel, es vki rendelest akarna leadni 11:00 orara, akkor a fenti pelda alapjan leadhatja, mivel a munkas 11 orakor mar raer.
Magyarul, az adott munkas CSAK a workers_starting és workers_finishing idokozott nem er ra, elotte es utana raer.Megcsinaltam amit irtal WHERE kriteriumot es ezt dobta a MySQL eredmenykent:
array(11) {
["booking_id"]=>"4"
["cheking_time"]=>"11:30"
["jobs_id"]=>"4"
["starting_timestamp"]=>"1366884000"
["number"]=>"8"
["workers_id"]=>"2"
["workers_start_hour"]=>"09:30"
["workers_finish_hour"]=>"18:30"
["workers_working_date"]=>"2013-04-25"
["interval_start"]=>"2013-07-28"
["interval_end"]=>"2013-08-28"
["oszlop"]=>"true"
}Ha jol ertem, akkor ez mar CSAK ["oszlop"]=>"true" erteku munkast dob vissza? Magyarul aki biztos nem er ra.
Idokozben kiderult itt egy ujabb dolog. Megpedig, hogy nem csak egyetlen idopontot kell vizsgalnia a keresnek, hanem ido intervallumot.
Szoval nem csak a 8 orai pillanatot kell ellenorizni, hanem a kivalasztott munka hosszatol fuggoen, a 08:00-tol, a munka befejezeseig terjedo intervallomot kellene vizsgalni.
Tehat amikor kivalasztja vki a 08:00, akkor mar adott, (korabban beallitott) hogy meddig fog a munka tartani.
Pl., 3 oras, tehat 08:00 es 11:00 ora kozotti idopontokat kell vizsgalni, hogy ne fedje legalabb egy munkas foglaltnak jelzett idointervallumjat.Remelem ez az apro valtozas tul sokat nem erinti az eddig elkeszitett projectet.
Ha a fenti kod jol mukodik, vagyis az elgondolasod szerint, akkor most mi a kovetkezo lepes?Koszonom.
-
#1342
szmegma
aktív tag
Apollo17hu
#1341
szmegma
aktív tag
válasz
Apollo17hu
#1341
üzenetére
Na ez erdekes. Termeszetesen igazad lett, a CASE nem veszi be a FROM_UNIXTIME(workers_finishing,'%H%i')*1 egyeni elnevezeset.
Plusz syntax hiba is volt.Elso verzio: osszes oszlop = TRUE, ha megforditom a kacsacsort, akkor is TRUE!
$cheking_time = '7:30';
(CASE WHEN
'1 < ".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'Masodik verzio: osszes oszlop = TRUE, am ha megforditom a kacsacsort, akkor FALSE lesz
$cheking_time = '7:30';
(CASE WHEN
1 < ".$cheking_time."
THEN
'true'
ELSE
'false' END) AS 'oszlop'Harmadik verzio: oszlop1 = FALSE, oszlop2 = FALSE, oszlop3 = TRUE, oszlop4 = FALSE
$cheking_time = '19:30';
(CASE WHEN
FROM_UNIXTIME(workers_finishing,'%H%i')*1 > '".$cheking_time."'
AND
FROM_UNIXTIME(workers_starting,'%H%i')*1 < '".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'Mint lathato, mostmar a SELECT resz mukodik.
Az uj kod:
SELECT
booking_sheet.booking_id,
jobs_sheet.booking_id,
jobs_id,
starting_timestamp,
number,
workers_id,
workers_starting,
workers_finishing,
FROM_UNIXTIME(workers_starting,'%Y-%m-%d') AS workers_working_date,
DATE(CURDATE()+1) AS interval_start,
DATE_ADD(CURDATE()+1, INTERVAL 31 DAY) AS interval_end,
(CASE WHEN
FROM_UNIXTIME(workers_finishing,'%H%i')*1 > '".$cheking_time."'
AND
FROM_UNIXTIME(workers_starting,'%H%i')*1 < '".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'
FROM
jobs_sheet
INNER JOIN
booking_sheet
ON
jobs_sheet.booking_id=booking_sheet.booking_idA korabbi kerdesedre valaszolva, bevittem a SELECT-be azt a 31 napos idointervallumot (interval_start es interval_end), amibol szurnie kellene, hogy mely napokon van legalabb egy szabad ember 08:00-kor.
Vegulis a lenyege ennek az lenne, hogy egy arrayba gyujtse ossze ezeket a napokat.A 100 lepesbol tizet megtettunk!
A FROM utan kellene letrehozni azokat az allekerdezeseket ugye? Olvasgattam utana, de ez a "SELECT beagyazasa masik lekeresbe" tema nem konnyen emesztheto szamomra.
Meg azt sem tudom, hogy az INNER JOIN kapcsolat jo ide? Olvastam LEFT, RIGHT, FULL, NATURAL es INNER tipusokrol, de nem tudom, mikor melyik ajanlott.
Esetleg elobb a WHERE utasitasokat kellene meghatarozni?Koszonom.
-
#1340
szmegma
aktív tag
Apollo17hu
#1339
szmegma
aktív tag
válasz
Apollo17hu
#1339
üzenetére
Nagy szenvedessel eddig jutottam a koddal:
$cheking_time = '7:30';
$info_get = "
SELECT
jobs_id,
starting_datetime,
number,
workers_id,
FROM_UNIXTIME(workers_starting,'%H%i')*1 AS workers_start_hour,
FROM_UNIXTIME(workers_finishing,'%H%i')*1 AS workers_finish_hour,
FROM_UNIXTIME(workers_starting,'%Y-%m-%d') AS workers_working_date,
DATE(CURDATE()+1) AS interval_start,
DATE_ADD(CURDATE()+1, INTERVAL 31 DAY) AS interval_end,
(CASE WHEN
'workers_start_hour < ".$cheking_time."' AND 'workers_finish_hour > ".$cheking_time."'
THEN
'true'
ELSE
'false' END) AS 'oszlop'
FROM
booking_sheet
INNER JOIN
jobs_sheet
ON
booking_sheet.booking_id=jobs_sheet.booking_id
";Viszont a segedoszlop nem mukodik. Mindenre "false"-t dob. Pedig a negy bejegyzett mukak kozul egyik igaz a kriteriumra. Nem tudtam rajonni miert.
A FROM utani resz pedig meg ennyire sem ment.
Eddig legalabb jo uton halodok?Koszonom.
-
#1338
szmegma
aktív tag
Apollo17hu
#1337
szmegma
aktív tag
válasz
Apollo17hu
#1337
üzenetére
"Ha tényleg ennyire 0-ról indulsz, akkor ez nagyon necces."
Sajnos ez igaz, de konnyen tanulok es akarok is tanulni. Olvasgatom a SQL lekerdezesek foldi halandoknak 2009 c. konyvet es mar sok ujdonsagot tudtam meg.
Pl., az a NATURAL JOIN is onnan szarmazik, ami annyit tesz, a ket osszekapcsolando tablaban, ugyeber minimum egy mezo nevenek meg kell egyezni mindket tablaban. Itt jon a kepbe a natural join, ha CSAK egy mezo neve egyezik meg es pont az amelyiken at vezerelni akarjuk a lekerdezest, akkor lehet hasznalni a natural join-t."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"
Sajnos ez igy nekem tul magas, nem tom mi az a segedoszlop. Megprobalok hetvegen melyebben utana olvasni de igy az elso kereses a google-vel, nem eredmenyezett kielegito talalatot.
Koszonom.
-
#1327
szmegma
aktív tag
Apollo17hu
#1326
szmegma
aktív tag
válasz
Apollo17hu
#1326
üzenetére
Az elso bekezdesed elso fele kesz van. Pont en is igy talaltam ki tegnap melo kozben, hazajottem es meg is csinaltam.
A masodik fele, a lekerdezes, mar nehezebb, mivel csak tablakat tudok osszekapcsolni, mezoket nem tudom, hogy kell.Jelenleg itt tartok, ezzel megkapok minden infot amire szuksegem van, csak nem tudom, hogyan tovabb:
SELECT jobs_id,starting_datetime,number,workers_id,workers_starting,workers_finishing,regularity FROM booking_sheet NATURAL JOIN jobs_sheetSzoval megkapom az osszes munkas beosztasat az ID-vel egyutt, hogy mettol-meddig nem er ra, mivel dolgozik, ezutan, hogyan kell lekerdezni, hogy mondjuk az osszes munkas kozul van-e legalabb egy olyan, aki az elkovetkezendo 1 honapi datumokon raer, vagyis nem dolgozik 08:00-kor es csak azokat a datumokat listazza ki?
Jelenleg igy nez ki a jobs_sheet adatbazis:
CREATE TABLE IF NOT EXISTS `jobs_sheet` (
`jobs_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`booking_id` int(10) unsigned NOT NULL,
`workers_id` int(10) unsigned NOT NULL,
`workers_starting` datetime NOT NULL,
`workers_finishing` datetime NOT NULL,
PRIMARY KEY (`jobs_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=5 ;
INSERT INTO `jobs_sheet` (`jobs_id`, `booking_id`, `workers_id`, `workers_starting`, `workers_finishing`) VALUES
(1, 1, 1, '2013-01-15 07:30:00', '2013-01-15 11:30:00'),
(2, 2, 2, '2013-02-11 11:30:00', '2013-02-11 14:30:00'),
(3, 3, 1, '2013-04-05 05:30:00', '2013-04-05 11:30:00'),
(4, 4, 2, '2013-04-25 09:30:00', '2013-04-25 18:30:00');A masodik bekezdesedet, sztem hagyjuk, eloszor mukodjon ez elobbi es utana lehet gondolkodni, hogyan kellene modositani, hogy az ismetlodeseket is figyelembe vegye.
Koszonom a segitsegedet. -
#1321
szmegma
aktív tag
Apollo17hu
#1320
szmegma
aktív tag
válasz
Apollo17hu
#1320
üzenetére
Termeszetesen tobb mezo van, csak a lenyegeseket irtam be.
A datumokat egy php funkcio generalja, mindig az aktualis nap es az azt koveto 30 nap datumait listazza ki a selectbe.
A szoveges leiras passzol, mivel a 10 karakteru szamok (1358236800) timestamp ertekek, ezek taroljak a full idot: 2013-01-15 08:00:00
Az elozo irasomat megprobalom leegyszerusiteni:Egy selectben levo ora erteket kivalasztva (pl. 08:00), fusson vegig a munkasok adatain, hogy 8 orakor melyik datumokon (maximum 30 napra elore) van legalabb egy szabad ember?
Elso variacio (hasra utott ertekek alapjan):
Ha 2013-08-08 napjan 6 orakor az elso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Ha 2013-08-08 napjan 9 orakor a masodik munkas dolgozik es 11 orakor fejezi be, akkor o nem szabad.
Ha 2013-08-08 napjan 8 orakor az utolso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Vegignezte a munkasokat, hogy ki-mikor dolgozik es a 2013-08-08 datum nem szabad, mivel mindenki foglalt a kivalasztott oraban (08:00).
Igaz, hogy a masodik munkas nem dolgozik 8 orakor, hanem 9-kor kezd, de 1 orat kell szamolni mindket iranyba, amit foglaltnak veszunk.Masodik variacio (hasra utott ertekek alapjan):
Ha 2013-08-08 napjan 6 orakor az elso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Ha 2013-08-08 napjan 10 orakor a masodik munkas dolgozik es 11 orakor fejezi be, akkor o szabad.
Ha 2013-08-08 napjan 8 orakor az utolso munkas dolgozik es 9 orakor fejezi be, akkor o nem szabad.
Vegignezte a munkasokat, hogy ki-mikor dolgozik es a 2013-08-08 datum szabad, mivel a masodik munkas nem dolgozik a kivalasztott oraban (08:00).Igy mar tisztabb?
Elarulom, hogy az adatbazis tablak mezoi meg nem veglegesek; folyamatosan szerkesztem, ha mashogy jobbnak latom.
Pl., ezt a +- 1orat is amit az elso variacioban emlitettem, vhogy mashogy fogom megoldani, valoszinuleg eltavolitom a finishing_datetime mezot, mivel felesleges, hiszen a kezdo idopontbol egy orat le kell vonni, ehhez a munka hosszat hozzaadni + meg 1 orat es mar meg is van egy munkas napi idolefedettsege.Koszonom.
-
#1260
Brown ügynök
senior tag
Apollo17hu
#1259
Brown ügynök
senior tag
válasz
Apollo17hu
#1259
üzenetére
A stock_intake tábla egy store_id-t is tartalmaz. Na, inkább megmutatom a táblákat.
intake
id, name, store_id, available, created, updatedintake_item
id, intake_id, product_id, quantityreservation
id, name, created, completedreservation_item
id, reservation_id, intake_id, product_id, quantityproduct_history
id, product_id, intake_id, reservation_id, store_id, createdMost úgy oldottam meg, hogy a product_history táblába felvettem a mennyiséget és a teljesülés dátumát (amikor ténylegesen ki/bevitték a raktárba az árut). Kvázi tehát kétszer lesz meg az adat, de nem tudtam máshogy megoldani, hogy a teljesülés dátuma szerint rendezze a bevitel és kivétel sorait a lekérdezésben. A product_history a változtatások után:
product_history
id, product_id, intake_id, reservation_id, store_id, quantity, created, completedA lekérdezés:
SELECT h.id, h.completed, quantity, r.name reservation_name, i.name intake_name,
i.created intake_created, r.created reservation_created
FROM stock_product_history h
LEFT JOIN stock_intake i ON i.id = h.intake_id
LEFT JOIN stock_reservation r ON r.id = h.reservation_id
AND r.completed BETWEEN :from AND :to
WHERE h.product_id = :productId
AND h.store_id = :storeId
AND h.completed BETWEEN :from AND :to
ORDER BY h.completed -
#1256
Brown ügynök
senior tag
Apollo17hu
#1254
Brown ügynök
senior tag
válasz
Apollo17hu
#1254
üzenetére
Így már csak azokkal a beviteli és foglalási sorokkal tér vissza amik a megadott intervallumba esnek. Csak az a baj, hogy nem a product_history tábla created oszlopa szerint rendezi őket (gondolom a group by miatt). Úgy látom szinte az összes adatot be kell szúrnom az intake és a reservation táblából, hogy időrendben meg tudjam jeleníteni a mozgásokat... Köszi a segítséget!
SELECT *
FROM stock_product_history h
LEFT JOIN stock_intake_item it ON it.product_id = h.product_id
AND h.reservation_id is NULL
AND it.intake_id IN (SELECT id
FROM stock_intake
WHERE available BETWEEN :from AND :to
AND store_id = :storeId)
LEFT JOIN stock_intake i ON it.intake_id = i.id
AND i.available BETWEEN :from AND :to
LEFT JOIN stock_reservation_item ri ON ri.product_id = h.product_id
AND ri.reservation_id = h.reservation_id
LEFT JOIN stock_reservation r ON r.id = ri.reservation_id
AND r.completed BETWEEN :from AND :to
WHERE h.product_id = :productId
AND h.store_id = :storeId
GROUP BY ri.id, i.id
ORDER BY h.created ASC -
#1253
Brown ügynök
senior tag
Apollo17hu
#1252
Brown ügynök
senior tag
válasz
Apollo17hu
#1252
üzenetére
A végcél az, hogy adott időszakra vonatkozóan megkapjuk egy termékről a raktári beviteleket (intake) és a teljesített foglalásokat (reservation) ami ez esetben a raktár kivétel lesz. Az i.available jelzi, hogy mikor van az áru ténylegesen a raktárban, a r.completed pedig azt, amikor teljesült a foglalás vagyis elvitték az árut. Foglalni a bevitelből lehet, tehát az intake_id a reservation táblában megvan.
-
#1250
Brown ügynök
senior tag
Apollo17hu
#1249
Brown ügynök
senior tag
válasz
Apollo17hu
#1249
üzenetére
Valóban. Jelenleg úgy van megoldva, hogy egy sorban vagy az intake_id vagy a reservation_id mező van kitöltve a stock_product_history táblában. Megnéztem, ha egy oszlopba írom őket egy másikba meg a típust adom meg és úgy kérdezem le, akkor is ugyanaz lesz az eredmény (gondolom az előző ok miatt). Igazából egy cikktörténetet szeretnék lekérdezni az intake(_item) és a reservation(_item) táblák csatolásával. Hogy alakítsam át a lekérdezést vagy a stock_product_history táblát, hogy úgy működjön, ahogy szeretném? Meg lehetne ezt oldani stock_product_history tábla nélkül is?
-
#1248
Brown ügynök
senior tag
Apollo17hu
#1247
Brown ügynök
senior tag
válasz
Apollo17hu
#1247
üzenetére
INNER-rel jó is lenne de akkor a reservation(_item) tábla sorait akkor nem kapcsolja hozzá.
-
#1226
laracroft
senior tag
Apollo17hu
#1225
laracroft
senior tag
válasz
Apollo17hu
#1225
üzenetére
Köszi!
Kicsit átalakítottam és jónak tűnik... -
#1192
Jinxb1rd
addikt
Apollo17hu
#1191
Jinxb1rd
addikt
válasz
Apollo17hu
#1191
üzenetére
Hm, nem is tudtam, hogy ilyenek is vannak. Megnézem majd. Köszi!
-
#1152
#68216320
törölt tag
Apollo17hu
#1151
#68216320
törölt tag
válasz
Apollo17hu
#1151
üzenetére
Sajnos kiderült, hogy nagy mennyiségű adat esetén piszkosul erőforrás igényes lesz. Feleslegesen számol átlagot minden listázásnál. Akkor számoltatok csak vele, mikor új értékelés érkezik és az eredményt eltárolom a borhoz update-el. Onnét már sima ügy lesz csak olvasni, mikor kell.
-
#1130
DanielK
addikt
Apollo17hu
#1127
DanielK
addikt
válasz
Apollo17hu
#1127
üzenetére
és martonx!
Nagyon köszönöm szépen!Tanultam, ne aggódj! Dolgoztam ezerrel rajta, bő 2 órája ezen agyaltam, majdnem meg is volt... Ezt össze tudtam vetni a sajátommal és rájöttem, hogy hol volt a hiba.
De nem akartam ide írni, nehogy valakit össze zavarjak ezzel. -
#1129
martonx
veterán
Apollo17hu
#1127
martonx
veterán
válasz
Apollo17hu
#1127
üzenetére
No látom megelőztél, ráadásul komplett megoldással. Akkor emberünk copy-paste-val megoldja a háziját, és megint nem tanul semmit
-
#1044
laracroft
senior tag
Apollo17hu
#1039
laracroft
senior tag
válasz
Apollo17hu
#1039
üzenetére
Szia!
Köszönöm kimerítő válaszod!
Egyenlőre syntax error-t kapok a:COUNT(*) over (PARTITION BY ugyfel.account, ugyfel.line) AS darab
FROM ugyfel, naplokód környékére... Átnéztem a mysql ezen parancsára vonatkozó szintaxist, de szerintem ennek jónak kéne lenni. Tanácsodra elhagytam az order by parancsot is, de nincs változás...
vmi ötlet? -
#997
laracroft
senior tag
Apollo17hu
#995
laracroft
senior tag
válasz
Apollo17hu
#995
üzenetére
Köszi a válaszokat és a helyesírási tanácsot is
-
#996
Sk8erPeter
nagyúr
Apollo17hu
#995
Sk8erPeter
nagyúr
válasz
Apollo17hu
#995
üzenetére
"aposztróf kell, nem?"
Alapértelmezésben tök mindegy, ez MySQL.
http://dev.mysql.com/doc/refman/5.0/en/string-literals.html(#992) laracroft :
"egyenlőre" ----> "egyelőre"
-
#881
Speeedfire
félisten
Apollo17hu
#880
Speeedfire
félisten
válasz
Apollo17hu
#880
üzenetére
Hanyagolom inkább ezt.
Végre van egy kis szabadidőm, elkezdtem tervezni a saját oldalamat.
A postokhoz a hozzászólásokat úgy akarom kezelni, mint itt a PH!-n van. Tehát ha valaki hozzászól egy cikkhez vagy valamihez, akkor az a fórumban fog megjelenni. Ezt nem tudom még, hogy kössem össze post-forum.
A forum valahogy így nézne ki:
//itt ha a parent értéke 0 akkor az a fő kategóriában van, ha nem akkor a megadott forum id alá tartozik
//nem jöttem rá, hogy itt mi legyen még, kellene még egy sor aminek postid a neve, ha 0 akkor az nem post. Viszont így hogy kötöm össze a post táblával?
id | Egysoros poszt | 1 | 1201231231 | 3 | 2 -
#879
Speeedfire
félisten
Apollo17hu
#878
Speeedfire
félisten
válasz
Apollo17hu
#878
üzenetére
És ezeket az értékeket, hogy írnám át? Számomra még mindig nem tiszta a kép.
Hirdetésenként van 7 kategória, kiemelésenként van 2. Az 7*2 féle kiemelés. -
#877
Speeedfire
félisten
Apollo17hu
#876
Speeedfire
félisten
válasz
Apollo17hu
#876
üzenetére
Hát, én ezt mindig nem értem, hogy ez az egyetlen_tabla honnan származtatik.
-
#875
Speeedfire
félisten
Apollo17hu
#874
Speeedfire
félisten
válasz
Apollo17hu
#874
üzenetére
Pont ezt írtam fentebb, hogy a hirdetes táblából nekem mindenki kell. A kiemeles_fizetve táblából pedig megtudom, hogy kik azok akik kivannak emelve.
-
#869
Speeedfire
félisten
Apollo17hu
#867
Speeedfire
félisten
válasz
Apollo17hu
#867
üzenetére
Hát, mert most akkor emiatt csináljak még egy táblát?
Biztos meglehet oldani, csak kicsit kacifántosan.
Lehet, hogy a left join után kellene tennem még egy select-et, ami csak az aktuális kiemeléseket íratja ki. Utána meg már csak a maradék kell.
Sk8erPeter: Apollo17hu pedig érti.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#866
Speeedfire
félisten
Apollo17hu
#865
Speeedfire
félisten
válasz
Apollo17hu
#865
üzenetére
2 tábla mindenféleképp kellene, 1 tábla kevés az adatok miatt.
-
#840
sonar
addikt
Apollo17hu
#838
sonar
addikt
válasz
Apollo17hu
#838
üzenetére
Zsiir! A group by nem jutott eszembe.
-
#824
martonx
veterán
Apollo17hu
#822
martonx
veterán
válasz
Apollo17hu
#822
üzenetére
Látod nem is volt nagy cucc beüzemelni. Ezért igazán kár volt a fórumban idétlenkedni. Ráadásul mint annyiszor, most is egy minimális guglizás megoldotta a dolgot.
Egyébként igen azt jelenti, hogy minden win induláskor a MySQL szerver is elindul a háttérben. Ez valamennyi erőforrást lefoglal. Egy régi P4-es celeron kb. használhatatlanná válik tőle, egy core i7-es 8Gb rammal meg észre sem veszi.
-
#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? -
#820
martonx
veterán
Apollo17hu
#819
martonx
veterán
válasz
Apollo17hu
#819
üzenetére
amikor telepítetted a mysql-t, és nyomkodtad a next-et, volt egy olyan rész, hogy user, meg jelszó. Ez ha jól rémlik defaultban root és nincs hozzá jelszó. Illetve volt egy olyan rész is, hogy fusson-e szolgáltatásként a rendszerrel együtt a mysql, vagy mindig kézzel akarod indítgatni. Azt hiszem itt is a default, hogy fut a rendszerrel együtt.
A server meglepő módon gondolom localhost.
). Mindegy, megcsináltam, így marad.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! GIGABYTE H77-DS3H H77 chipset alaplap garanciával hibátlan működéssel
- Konzol felvásárlás!! Playstation 5, Playstation 5 Pro
- AKCIÓ! Dell Precision 5820 XL Tower PC - Xeon W-2123 112GB RAM 512GB SSD 1TB RX 580 8GB Win 11
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest