- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- A legtöbb amerikai szerint a TikTok egy őket befolyásoló eszköz
- Mindenki AI-t akar, már 2025-re is eladták a HBM chipeket
- Mikrotik routerek
- Álláskeresés, interjú, önéletrajz
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Ubiquiti hálózati eszközök
- Netflix
- Windows 11
- Aliexpress tapasztalatok
Új hozzászólás Aktív témák
-
nova001
senior tag
válasz Sk8erPeter #1301 üzenetére
köszi tényleg...megtaláltam
-
Brown ügynök
senior tag
Adott egy adatbázis kb. 200 táblával, melyet egyszerre maximum 10-15 használnak. Az itt felsoroltak közül melyek okozhatják a "slow query"-ket (illetve, hogy a rendszer többször érezhetően kegyelemért könyörög)?
a) Az egyik tábla 23 millió rekordot tartalmaz (a többi, 2 kivételével általában pár tízezret)
b) Optimalizálatlan lekérdezések
c) Adatbázis tervezési hibák
d) InnoDB, MyIsam vegyesen
e) Elavult MySQL verzió (5.1.49)
f) A MySQL ennyit bír
g) Vashiány
h) C-vitamin hiány
[ Szerkesztve ]
"hacsak nem jön a jó tündér break utasítás képében..."
-
válasz Brown ügynök #1303 üzenetére
Elsőre szar lekérdezések (és indexek), illetve rosszul beállított szerver. Az a baj, hogy ezt már tényleg látni kellene.
-
martonx
veterán
válasz Peter Kiss #1304 üzenetére
Az f pont biztos nem, a g-t, h-t nem részletezted.
Én kérek elnézést!
-
Brown ügynök
senior tag
@Athlon64+, @martonx: Akkor jobban elmerülök az indexelésben. Ez az a pont amin most könnyen javíthatok. (Egyébként nem tudom milyen vas szolgálja ki a rendszert, ennek majd utánaérdeklődöm.)
"hacsak nem jön a jó tündér break utasítás képében..."
-
martonx
veterán
válasz Brown ügynök #1306 üzenetére
Mondjuk jobban utána gondolva az e pont azért okozhat némi teljesítmény problémát (MySQL sosem volt sebesség bajnok, pláne nem a korai verziói), illetve bizonyos esetekben a d pont is bezavarhat, bár ezt nem tartom túl valószínűnek.
Én kérek elnézést!
-
Jim-Y
veterán
Sziasztok. Adott a következő szituáció:
van egy tábla, ahol vannak bizonyos tulajdonságú rekordjaim, mondjuk legyen egy NUM nevű oszlop.
Szeretnék ezen csinálni egy olyan lekérdezést, hogy minden olyan sort szedjen ki, ahol NUM = 1, rendezze egy másik oszlop szerinti csökkenő sorrendbe, ÉS! (itt a probléma) csak az első 10%-ot listázza.Pl NUM = 1 sorból van 2000 db, ezeket rendezem egy másik mező szerint csökkenőbe, de ezekből csak 2000*0.1 darabot szeretnék listázni.
Ott akadtam el, hogy ha a LIMIT után egy változót teszek, akkor szintaktikai hibát dob. Hogy lehetne ezt megoldani id-kel való lavírozás nélkül? üdv
-
martonx
veterán
Híjnye, jól látom, hogy a MySQL-lel hivatalosan nem lehet %-ot megadni a Limitnek? Pedig ez PostgreSQL-ben, MS SQL-ben (gondolom Oracle-ben is) támogatott.
Mindegy itt egy kerülő megoldás:SELECT*
FROM (
SELECT list.*, @counter := @counter +1 AS counter
FROM (select @counter:=0) AS initvar, list
ORDER BY value DESC
) AS X
where counter <= (10/100 * @counter);
ORDER BY value DESCÉn kérek elnézést!
-
válasz Brown ügynök #1306 üzenetére
Ha már optimalizálás, ma találkoztam egy problémával, egy drop down list-et, amiben 2000 elem volt kb. 8000 SQL lekérdezéssel (mindegyikhez volt 4) töltött fel egy hülyegyerek. Újraírtam, hogy lejöjjön egyben.
-
Brown ügynök
senior tag
válasz Peter Kiss #1310 üzenetére
Ilyen lekérdezéssel szerencsére én még nem találkoztam.
@martonx: Átnéztem a táblákat és nincs olyan nagy vegyítés a motoroknál.
Egyébként októberben költözik a cucc modernebb vasra, addig nézek valami okosságot a MySQL optimalizációjáról szóló fejezetében.
"hacsak nem jön a jó tündér break utasítás képében..."
-
martonx
veterán
válasz Brown ügynök #1312 üzenetére
Azt azért tartsd észben, hogy a MySQL optimalizációnál erősen meglőnek, ha eleve nem jól beállítva telepítik fel.
Úgyhogy vagy neked kell egyben a rendszergazdának, DBA-nak is lenned, vagy utólag simán előfordulhat az az eset, hogy marhára nem fogsz tudni mit optimalizálni, mert a telepítéskor elcseszett setup miatt egyszerűen mindeféle diagnosztizáló funkció le van tiltva rajta.
És ezeken utólag nagyon nem szeretnek a rendszergazdák változtatni.Én kérek elnézést!
-
Brown ügynök
senior tag
válasz martonx #1313 üzenetére
A query loghoz nem férek hozzá, de szerintem ha szépen megkérem az adminisztrátort, rendelkezésemre bocsátja. Egyébként az "explain" kulcsszóval próbálkozom.
Egyébként ha egy táblába nagyjából azonos mennyiségben írunk és olvasunk, azt érdemes indexelni?
"hacsak nem jön a jó tündér break utasítás képében..."
-
martonx
veterán
válasz Brown ügynök #1314 üzenetére
Ez sok mindentől függ. Mennyire komplex például az index, mennyi indexed van a táblán stb...? Ha komplex, és sok az index akkor az írást lassítja.
Egy szimpla növekvő int index ellenben nem fog jelentős írás lassulást okozni.
Az írás tűnik lassúnak vagy az olvasás? Mert ha az olvasás a lassú, akkor viszont mindenképpen kell az index, különben nélküle meg megállna az élet. Még ha ez miatt némileg lassul is az írás.
Szóval igazán jó válasz nem biztos, hogy van a kérdésedre.
Kérdés az is, hogy mit értesz azonos mennyiségű írás, olvasásnak? Naponta 100 sort beírsz, és 100 sort ki is olvasol? Vagy hogy naponta 100-szor olvas valamit a táblából, és 100-szor ír valamit a táblába a db motor? Ez esetben a valamit az érdekes, hogy 100-szor beír 1 sort, vagy 100-szor beír 2000 sort?
Ez esetben pl. az írási stratégiáján a programnak érdemes lehet változtatni.Én kérek elnézést!
-
Brown ügynök
senior tag
válasz martonx #1315 üzenetére
Egy szimpla növekvő int index ellenben nem fog jelentős írás lassulást okozni.
Akkor ez azt jelenti, ha egy adatbázisban megfelelőn használjuk az idegen kulcsokat az nagy mértékben hozzájárul a teljesítmény növeléséhez?
Ahogy elnéztem egyébként, inkább az indexek hiánya lehet a ludas, mint a túl nagy száma. Úgy látom, ez egy összetett kérdés... Egyébként az program szinten nem akarok nagyon belenyúlni, mert elég mosott a kód. Igyekszem adatbázis oldalról javítani (ha lehet). Az igazi megoldást persze egy egészséges újraírás jelentené (és nem csak a lassú lekérdezések miatt).
"hacsak nem jön a jó tündér break utasítás képében..."
-
szmegma
aktív tag
Egy MySql gurura lenne szuksegem az alabbi problemammal kapcsolatban.
Van 3 tabla. A booking_sheet, jobs_sheet es workers_sheet.
A booking_sheet tartalmazza egy leadott megrendeles adatait:`booking_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`starting_datetime` int(10) unsigned NOT NULL,
`regularity` tinyint(2) unsigned DEFAULT NULL,
PRIMARY KEY (`booking_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;Tegyuk fel van 3 megrendeles (booking_id,starting_datetime,regularity):
1, 1358236800, 14
2, 1360584000, 7
3, 1365141600, NULLA jobs_sheet, a fonok booking_sheet altal kiosztott munka adatait tartalmazza. Beallitja a munka vegenek idopontjat es egy mukas ID-jet rendeli hozza:
`jobs_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`booking_id` int(10) unsigned NOT NULL,
`workers_id` int(10) unsigned NOT NULL,
`finishing_datetime` int(10) unsigned NOT NULL,
PRIMARY KEY (`jobs_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;Tegyuk fel van 3 ekeszitett rekord (jobs_id,booking_id,workers_id,finishing_datetime):
1, 1, 2, 1358251200
2, 2, 3, 1360594800
3, 3, 1, 1365163200A workers_sheet pedig a munkasok adatait tartalmazza:
`workers_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`workers_name` varchar(255) NOT NULL,
PRIMARY KEY (`workers_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;Tegyuk fel van 3 munkas (workers_id,workers_name):
1, Jozsi
2, Geza
3, BelaEgy megrendelo lapot keszitek, ahol orat es datumot kell kivalasztani az ugyfelnek.
Ha mondjuk kivalasztja a 08:00, akkor ugy kellene lefutnia egy keresnek, hogy 8 orakor melyik napon van legalabb egy szabad ember es azokat a napokat adja vissza a datumvalasztoba.
Csak, hogy ne legyen ilyen egyszeru, mint latjatok van egy regularity mezo, mely azt adja meg, hogy az elso kivant munkanap utan, hany nap mulva kell ujra az adott idopontban menni dolgozni.A fenti peldak szoveges formaban:
Az 1. szamu melot 2013-01-15 08:00:00-kor Geza kezdi, melynek befejezese 2013-01-15 12:00:00-kor es 14 naponkent ismetlodik, tehat 2013-01-29 08:00:00-kor ujra kezdi stb.
A 2. szamu melot 2013-02-11 12:00:00-kor Bela kezdi, melynek befejezese 2013-02-11 15:00:00-kor es 7 naponkent ismetlodik, tehat 2013-02-18 12:00:00-kor ujra kezdi stb.
A 3. szamu melot 2013-04-05 06:00:00-kor Jozsi kezdi, melynek befejezese 2013-04-05 12:00:00-kor es nem ismetlodik.Na mar most, ha vki a megrendelo lapon kivalasztja a 08:00, akkor lathato, hogy minden datum szabad esmegjelenitheto, hiszen legalabb egy munkas szabad barmelyik napon 8 orakor.
Szamomre ez a kerdes igencsak meghaladja a tudasom, pedig ezt a hetveget MySql tanulassal toltottem. Sok mindent tanultam, de ezt nem tudom megoldani egyedul.
Ha vki tudna segiteni, halas lennek.Koszonom.
TV: JZ1000
-
martonx
veterán
válasz szmegma #1317 üzenetére
Ez a szokásos, hogy kell a select * from táblát lefuttatni php-ben kérdések szintjét meghaladja
Két lehetőséged van:
1. használod az sqlfiddle-t, és létrehozod a táblákat, példa adatokkal, aztán várod a jószerencsét, hogy hátha valaki megszán, és helyetted beleteszi azt a pár órányi sql szakértői munkát.
2. eleve pénzt jánlasz ezért, és akkor biztosan lesz aki beleteszi azt a pár órányi sql szakértői munkát.Én kérek elnézést!
-
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...
-
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.
TV: JZ1000
-
biker
nagyúr
heeeelp
van egy 6000 nevet tartalmazó tábla.
ebből 5400 importkor rosszul került be, mert szóközzel kezdődik
nem [kovács béla] hanem [ kovács béla]
persze innentől borul a név szerinti rendezés (az új neveket már helyesen viszik fel)Hogyan lehet az első, és csak az első szóközt kiherélni paranccsal, mert félek, a kovács és a béla közti szóközt is cserélné
előre is köszi
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Sk8erPeter
nagyúr
Ahogy előttem már martonx említette:
http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_ltrim
mysql> SELECT LTRIM(' barbar');
-> 'barbar'Sk8erPeter
-
biker
nagyúr
válasz Sk8erPeter #1324 üzenetére
5385 sor érintett. ( a lekérdezés 0.0782 másodpercig tartott )
UPDATE users SET nev = LTRIM(nev); egész pontosan...[ Szerkesztve ]
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
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.
-
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.[ Szerkesztve ]
TV: JZ1000
-
Jim-Y
veterán
Sziasztok, nem lehet olyat csinálni MySQL-ben, hogy van egy selectem, számol egy count(*)-ot valamin, illetve egy filterezett értéket.
Tehát a query eredményében lesz egy count(*) mondjuk 50, és egy filterezett oszlop, ami ugye < mint a count, legyen ez mondjuk 30.
Én az resultsetben szeretnék egy olyan oszlopot, ahol ezek különbsége is látszik, tehát COUNT(*) - Filtered.
Ezt úgy próbáltam, hogy felvettem egy akármilyen mezőt a selectben, pl 'good', majd a HAVING után próbáltam ennek értékül adni a fenti kivonás eredményét.Jó, noob kérdés tudom
-
biker
nagyúr
lehet rosszul tudom, de count esetén egy szám csak az eredmény, nincs más
csinálj normál selectet, és számold az eredményt
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
Jim-Y
veterán
Végül nagyjából így csináltam meg
SELECT
date,
COUNT(*) as Osszes,
COUNT(IF(valami < 72,valami,null)) as below72hours,
COUNT(IF(valami > 72,valami,null)) as above72hours
FROM TABLE
GROUP BY date;biztos nem a legszebb, de működik. Az eredeti kérdés arra irányult volna, hogy ha az above72hours-ot csak az Osszes és below72hours alapján akartam volna számolni ebben az egy queryben, akkor azt hogy kellett volna.
-
Jim-Y
veterán
válasz fordfairlane #1332 üzenetére
Igazából csak érdekelt, hogy meg lehet-e oldani egy queryben
-
xeqe
csendes tag
Amennyire én tudom, csak így lehet megoldani:
SELECT
date,
Osszes,
below72hours,
Osszes - below72hours
FROM (
SELECT
date,
COUNT(*) as Osszes,
COUNT(IF(valami < 72,valami,null)) as below72hours
FROM TABLE
GROUP BY date) as temp;És ez így még ocsmányabb, mint a te megoldásod. Amúgy a teljesítmény miatt nem kell aggódnod - ebben az esetben legalábbis. Az adatbázismotor erősen optimalizálja a lekérdezést, szóval valószínűleg az általad összehozott lekérdezés is úgy fog lefutni, hogy amint megvan az Osszes és a below72hours, egy kivonással kiszámolja a hiányzó értéket.
[ Szerkesztve ]
-
xeqe
csendes tag
Vagy várj, valamit elnéztem. Igazából az Osszes és a below72hours alapján nem lehet kiszámolni az above72hours értékét, hiszen utóbbi két érték esetében azok a sorok számítanak ahol valami szigorúan kisebb, illetve nagyobb, mint 72. Emiatt (below72hours + above72hours) nem feltétlen egyenlő az Osszes értékével.
Tehát egyik helyen meg kellene engedni az egyenlőséget ahhoz, hogy igaz legyen:
below72hours + above72hours = Osszes. -
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 ]
-
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.
TV: JZ1000
-
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á.
-
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.
TV: JZ1000
-
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].
-
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.
[ Szerkesztve ]
TV: JZ1000
-
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.
-
bbTamas77
aktív tag
Üdv éppen mysql tanulgatom és máris gondom akadt.
php myadmint használok, Verziószám: 3.5.2.2, utolsó stabil verzió: 4.0.4.1
Szerintem hibátlanul írtam mindent de mégis hibát ír ki.
Amikor az első táblát létre akarom hozni akkor még nem írt ki semmit, sikeresen létrehozta:
Első tábla.
Create Table nev (
nev_id SMALLINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
new_addatum DATETIME DEFAULT '0000-00-00 00:00:00',
new_moddatum DATETIME DEFAULT '0000-00-00 00:00:00',
vezeteknev VARCHAR (75),
keresztnev VARCHAR (75),
INDEX idx_vn (vezeteknev),
INDEX idx_kn (keresztnev)
);De amikor a második táblát hoznám létre sql parancs segítségével, akkor php myadmin az alábbi hibát írja ki.
Második tábla és a hiba:Create Table munkahelyi_beosztas (
beosztas_id SMALLINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
new_id SMALLINT UNSIGNED NOT NULL DEFAULT '0'
beosztas_addatum DATETIME DEFAULT '0000-00-00 00:00:00', beosztas_moddatum DATETIME DEFAULT '0000-00-00 00:00:00',
beosztas_nev VARCHAR (100),
INDEX idx_beoszt (beosztas_nev)
);Hibaüzenet.
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'beosztas_addatum DATETIME DEFAULT '0000-00-00 00:00:00', beosztas_moddatum DAT' at line 4Értem én, hogy azt írja hogy verzióhiba, de mégis hogyan lehetne másképpen megadni, hogy elfogadja az alapértelmezett értéket?
-
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.
TV: JZ1000
-
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).
-
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?[ Szerkesztve ]
TV: JZ1000
Új hozzászólás Aktív témák
- OLED TV topic
- Renault, Dacia topik
- Telekom mobilszolgáltatások
- Luck Dragon: Asszociációs játék. :)
- Kormányok / autós szimulátorok topicja
- iOS alkalmazások
- PlayStation 5
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- ThinkPad (NEM IdeaPad)
- Robot fűnyírók
- További aktív témák...