Új hozzászólás Aktív témák

• #1377 bpx őstag szmegma #1360

  Új Válasz 2013-08-01 13:47:51 #1377

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz szmegma #1360 üzenetére

  az a baj a mysqllel, hogy nincs benne egyszeru "generator" funkcio, mert egyebkent ez a feladat pl. arra is lefordithato, hogy generaljunk szamokat 1-31-ig es adjunk hozza ennyi napot a mostani datumhoz, ami tisztan SQL lenne

  de rekurziv lekerdezessel megoldhato, csak kell egy olyan forras, amelynek legalabb 31 sora van
  peldaul select SQL megoldas:

  select date_add(CURDATE(), interval o.num day) from
  (select @n := @n + 1 as num
  from information_schema.columns, (select @n := 0) n
  limit 31) o;

  ezzel persze az a baj, hogy mindig az information_schema.columns-hoz (vagy amire epp meg van irva) kell nyulni + akar el is lehetne tarolni a szamokat 1-31-ig egy kulon tablaban (es nem kell feltalalni ujra a kereket naptar tablaval):

  create table numbers (n int);

  insert into numbers
  select @n := @n + 1 as num
  from information_schema.columns, (select @n := 0) n
  limit 31;
  
  select date_add(CURDATE(), interval n.n day) from numbers n;

  csak hat ez meg megint ronda (szerintem)

  szemlelteteskeppen, Oracle-ben ez ennyi:

  select sysdate + level from dual connect by level <= 31;

  a dual tabla sajatossagai miatt ez raadasul sem diszkrol, sem a cache-bol nem olvas, nem kell PL/SQL-ezni meg context switch sincs

• #1366 fordfairlane veterán szmegma #1365

  Új Válasz 2013-07-31 20:47:03 #1366

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz szmegma #1365 üzenetére

  Nem nagy dolog, én sem használtam még soha.

• #1364 martonx veterán szmegma #1362

  Új Válasz 2013-07-31 10:36:04 #1364

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz szmegma #1362 üzenetére

  aha, bár maga a kérdés megdöbbentett, hogy eddig nem használtál tárolt eljárást.

• #1361 martonx veterán szmegma #1360

  Új Válasz 2013-07-31 07:10:23 #1361

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz szmegma #1360 üzenetére

  Hirtelenjében két módszer jutott az eszembe.

  1. While ciklussal - SQL-ben ez nem túl szép, de ez pont az az eset, amikor érdemes használni.
  2. Csinálsz magadnak egy naptár táblát, amibe pár évre előre eltárolod a napokat, hétvégéket, munkaszüneti napokat.

  Ismerve, hogy ez mihez kell neked, én a második megoldást javaslom, noha nem kis munka egy tisztességes naptár táblát összerakni pár évre előre magadnak.

• #1351 Apollo17hu őstag szmegma #1350

  Új Válasz 2013-07-28 14:40:17 #1351

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz szmegma #1350 üzenetére

  Igazad van. Az a probléma, hogy én csak arra gondoltam, hogy a vizsgálandó intervallum beleesik-e a már foglalt időintervallumba. Lehet viszont olyan eset is, amikor csak átfedés van.

  Módosítsd úgy a feltételt, hogy a foglalt jelzést a következő jelentse:

  (workers_start_timestamp > desired_start_time AND workers_start_timestamp < estimated_completion_time)
  OR
  (workers_finish_timestamp > desired_start_time AND workers_finish_timestamp < estimated_completion_time)

  Ennek már jónak kell lennie.

• #1349 Apollo17hu őstag szmegma #1347

  Új Válasz 2013-07-28 02:59:43 #1349

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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_end

  Ez 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_end

  Ez 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 NULL

  A JOIN-okban nem vagyok biztos, én más szintaktikát szoktam használni, de a lényeg sztem látszik.

  Ha ez kész, akkor írom, hogyan csapd a workers_id mellé a szükséges infót (de erre már te is rá tudsz jönni).

• #1348 Apollo17hu őstag szmegma #1347

  Új Válasz 2013-07-28 02:36:54 #1348

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz szmegma #1347 üzenetére

  Ha jol ertem, akkor ez mar CSAK ["oszlop"]=>"true" erteku munkast dob vissza? Magyarul aki biztos nem er ra.

  Nem, ["oszlop"] értéke lehet "false" is, ami azt jelenti, hogy a munkásnak ez a munkája nem ütközne abba a munkába, amit rá akarunk sózni. Viszont a munkásnak több munkája is van, és ha csak egynél is "true" értéket kapsz, az fogja azt jelenteni, hogy a munkásnak van olyan munkája, ami üti a rásózandó melót. De át is írhatod a "true" és a "false" értékeket pl. "not feasible" és NULL -ra vagy bármire, hogy hangsúlyosabban látszódjon.

  Idokozben kiderult itt egy ujabb dolog. Megpedig, hogy nem csak egyetlen idopontot kell vizsgalnia a keresnek, hanem ido intervallumot.

  Ezt úgy kellene megoldani, hogy az intervallum kezdetét és végét tárolod. Tehát mondjuk checking_start és checking_end meződ van. Az ["oszlop"] meződet kell csak módosítanod (ennek is adhatnál mondjuk egy ["check_worker_time"] vagy bármilyen, beszédes nevet) úgy, hogy a checking_start -ot a workers_start_hour -hoz, a checking_end -et pedig a workers_end_hour -hoz viszonyítod.

• #1343 Apollo17hu őstag szmegma #1342

  Új Válasz 2013-07-27 12:28:09 #1343

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz szmegma #1342 üzenetére

  Várjál, ez így még nem biztos, hogy jó. Nézem az új kódod: abban a workers_starting és workers_finishing mit jelent? A teljes vagy csak a foglalt munkaidő kezdetét és végét? Ha utóbbit, akkor jó, ha előbbit, akkor ki kell cserélni, mert a foglalt munkaidőt kell összevetni a checking_time -mal.

  Ezután a lekérdezésed végére még szükség van WHERE-re, hogy csak azok a rekordok maradjanak a listádban, ahol a munkás teljes munkaidejébe beleesik-e a checking_time.

  Vmi ilyesmi kell tehát a lekérdezésed végére:

  WHERE teljes_munkaido_start < checking_time AND teljes_munkaido_end > checking_time

  Ha pedig ezzel is kész vagy, egy olyan listát kapsz, amiben csak azok a munkások jelennek meg, akiknek a munkaidejére esik a checking_time. A munkásokhoz annyi rekord fog tartozni, ahány munkájuk van. Ha ezekből a munkákból akár csak egynél is 'x' szerepel a segédoszlopban, akkor a munkás foglalt.

• #1341 Apollo17hu őstag szmegma #1340

  Új Válasz 2013-07-26 17:42:18 #1341

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz szmegma #1340 üzenetére

  A MySQL szintaxist nem ismerem, meg kéne próbálni, hogy a CASE WHEN-be először csak az egyik feltételt adod meg, és megnézni, hogy úgy kapsz-e TRUE értékeket. Ha nem, akkor valószínűleg nem tudja összehasonlítani a két időértéket, tehát az egyik valószínűleg nem time típusú változó.

  Nekem az a furcsa, hogy a workers_start_hour -t és a workers_start_end -et ugyanebben a lekérdezésben generálod. Lehet, hogy ezek a CASE WHEN -ben még nem léteznek, ezért nem is tud velük mit kezdeni. Esetleg e kettő helyett beírhatnád a fölöttük lévő képleteket [FROM_UNIXTIME(workers_starting,'%H%i')*1 és FROM_UNIXTIME(workers_finishing,'%H%i')*1].

• #1339 Apollo17hu őstag szmegma #1338

  Új Válasz 2013-07-25 17:06:34 #1339

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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őpont

  Segédoszlop -ban 'x'-szel jelölöd, ha a munkás a vizsgált_időpont -ban foglalt.
  A kód végén lévő két feltétel pedig csak azokat a munkásokat szűri, akiknek a munkaidejére esik a vizsgált_időpont.

  Az így kapott listában meg kell nézned, hogy van-e olyan munkás, akinél a segédoszlop értéke minden esetben NULL (vagyis egyik meglévő melója sem akadna a vizsgált_időpont -tal). Ehhez a fenti kódot allekérdezésbe kell majd rakni, és analitikus függvényt kell használni rá.

• #1337 Apollo17hu őstag szmegma #1327

  Új Válasz 2013-07-24 18:32:50 #1337

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz szmegma #1327 üzenetére

  Hát, ez sokkal bonyolultabb (legalábbis azon az úton, ahogy elindultunk), mint gondoltam.

  A "munkás, munkaidő_start, munkaidő_end, foglalt_start, foglalt_end" listában minden sorra meghatároznám (segédoszloppal), hogy az adott sorban lehetséges-e a kívánt munkát (időpont alapján) végezni (IF, AND és OR megfelelő kombinációjával). Ezután munkások munkanapjaiként csoportokat készítenék analitikus függvénnyel, ami megmutatná, hogy adott munkás adott munkanapján van-e ütközés (az előbb létrehozott segédoszlop). Ahol nincs ütközés, azt a munkást, és azt a napot adná vissza az eredmény...

  De néztem, hogy natural join-t használtál. (Eddig nem is hallottam róla.) Ha tényleg ennyire 0-ról indulsz, akkor ez nagyon necces. Ha valahogy össze is tudnánk rakni a modellt, lehet, hogy baromi lassan futna a lekérdezés, optimalizálásban pedig nem vagyok jártas...

• #1326 Apollo17hu őstag szmegma #1321

  Új Válasz 2013-07-23 18:34:34 #1326

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Apollo17hu

  őstag

  válasz szmegma #1321 üzenetére

  tisztább valamivel...

  Én talán úgy csinálnám, hogy minden munkáshoz meghatároznám a szabad idő-intervallumokat (a +/-1 óra korrekcióval). Ez start_date és end_date párokat jelentene. Ezeket összesíteném (UNION?), majd erre az összesített halmazra futtatnám le a keresést, ami abból állna, hogy a kiválasztott időpont beleesik-e valamelyik intervallumba vagy sem. Ha igen, akkor nincs szabad időpont, ha nem (NULL), akkor van.

  Az ismétlődéssel gondban vagyok. Azt valahogy úgy lehetne beépíteni, hogy az előre vizsgált pl. 1 hónapot le kell osztani azoknak a napoknak a számával, ami két ismétlés között eltelik, majd a hányadost kell felhasználni, de nem látom, hogy lehetne beépíteni a modellbe.

• #1320 Apollo17hu őstag szmegma #1317

  Új Válasz 2013-07-22 22:50:03 #1320

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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...

• #1318 martonx veterán szmegma #1317

  Új Válasz 2013-07-22 08:51:25 #1318

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

Új hozzászólás Aktív témák