- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Aliexpress tapasztalatok
- Windows 10
- Xiaomi AX3600 WiFi 6 AIoT Router
- Facebook és Messenger
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Adobe Lightroom topic
- Adobe Illustrator kérdések
- Vírusirtó topic
- Mesterséges intelligencia topik
Új hozzászólás Aktív témák
-
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.Én kérek elnézést!
-
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? -
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.
Én kérek elnézést!
-
sonar
addikt
válasz Apollo17hu #838 üzenetére
Zsiir! A group by nem jutott eszembe.
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
Speeedfire
nagyúr
válasz Apollo17hu #865 üzenetére
2 tábla mindenféleképp kellene, 1 tábla kevés az adatok miatt.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
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.[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
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.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
válasz Apollo17hu #876 üzenetére
Hát, én ezt mindig nem értem, hogy ez az egyetlen_tabla honnan származtatik.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
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.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
nagyúr
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[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
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"Sk8erPeter
-
laracroft
aktív tag
válasz Apollo17hu #995 üzenetére
Köszi a válaszokat és a helyesírási tanácsot is
-
laracroft
aktív 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? -
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
Én kérek elnézést!
-
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.[ Szerkesztve ]
-
#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.
-
Jinxb1rd
addikt
válasz Apollo17hu #1191 üzenetére
Hm, nem is tudtam, hogy ilyenek is vannak. Megnézem majd. Köszi!
We are only Stardust...
-
laracroft
aktív tag
-
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á.
"hacsak nem jön a jó tündér break utasítás képében..."
-
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?
[ Szerkesztve ]
"hacsak nem jön a jó tündér break utasítás képében..."
-
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.
"hacsak nem jön a jó tündér break utasítás képében..."
-
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[ Szerkesztve ]
"hacsak nem jön a jó tündér break utasítás képében..."
-
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"hacsak nem jön a jó tündér break utasítás képében..."
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
szmegma
aktív tag
-
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
-
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 procedureSELECT
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;[ Szerkesztve ]
-
cidalain
veterán
válasz Apollo17hu #1493 üzenetére
igen
[ Szerkesztve ]
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
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!
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
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- http://pazsitz.hu -
-
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.
>> GearBest Club Veszprém << >> https://www.facebook.com/gbc.veszprem <<
-
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'[ Szerkesztve ]
A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
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?----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
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.
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
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----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
fordfairlane
veterán
válasz Apollo17hu #1707 üzenetére
MySQL tud analitikus függvényeket?
Tudomásom szerint egyiket sem ismeri.
x gon' give it to ya
-
don_peter
senior tag
válasz Apollo17hu #1712 üzenetére
Makszimum 8 topik jelenik meg az utolsó bejegyzések alapján csökkenő sorban.
----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
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.----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
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----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
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..----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
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.----== Neo Geo és Arcade Fórum : www.neo-geo.hu ==----
-
laracroft
aktív tag
válasz Apollo17hu #1777 üzenetére
Köszi kipróbálom
-
laracroft
aktív 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 -
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.
Én kérek elnézést!
Új hozzászólás Aktív témák
- Konzolokról KULTURÁLT módon
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Megérkezett a Google Pixel 7 és 7 Pro
- Politika
- Eredeti játékok OFF topik
- Honor Magic6 Pro - kör közepén számok
- Futás, futópályák
- Vodafone mobilszolgáltatások
- Építő/felújító topik
- CURVE - "All your cards in one." Minden bankkártyád egyben.
- További aktív témák...
- Lenovo Legion 7, 16,0"WQXGA, Ryzen 9 6900HX, 32 GB DDR5, RX6850M XT 12 GB, 1TB SSD, 1,5+ év garancia
- Corsair RM850e 850W Gold Moduláris Tápegység
- Samsung Odyssey Neo G9 Super Ultrawide Gamer Monitor!49"/Mini LED/5120x1440/240hz/1ms/+Ajándék
- Apple Macbook Pro 16" 2019 i7-9th 6Magos 32/512 -75% Touch Bar HUN Radeon Pro 5300M 4GB 3K Retina
- Apple Mac mini M2 2023 8GB 256GB + Xiaomi Mi Desktop 27"-os FullHD monitor egyben
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen