Prodej eshopu E-Samolepka™ + kompletní výroba • Možnost okamžitě začít s podnikáním
Zobrazují se odpovědi 1 až 30 z 30

Struktura DB, rezervace

  1. Ahoj, mám takový dotaz.

    Řekněme, že mám pro danou zakázku zabraný datum 1.5. - 30.5., k tomu potřebuji přidělit dělníka od 1.5. - 30.5.

    dále je možnost, že v průběhu zakázky budu dělníka potřebovat jinde a tudíž ho na zakázce budu mít pouze v rozmezí 1.5. - 10.5. a pak zpět bude od 15.5. - 30.5.

    (pracovníků bude přiděleno několik k jedné zakázce)

    Jak nejlépe to hodit do DB? Přemýšlel jsem klasicky dávat datumy ve formátu DATE, ale pak nastává problém jak nějak rozumně řešit kontrolu na DB při zadání datumu zda je již někde vytížen či nikoli. Pak druhá varianta je pro každý den uložit řádek do DB a ty jeden po druhém kontrolovat, což mi ale přijde zas trochu čuňačina.

    K jaké variantě by jste se přikláněli? A pokud k první, nějaký nápad na SQL dotaz pro kontrolu zda je někde již zařazen? Alespoň nakopnutí.

    Pak mě napadla ještě jedna varianta a to uložit si všechny dny po jednom do DB a do dalšího sloupce nějak vkládat ID všech přidělených pracovníků na určitý den. Nicméně předem neznám počet pracovníků a blbě by se mi pak filtrovali a upravovali, nechci mít sloupec ve tvaru 1,5,20,22,23 (IDčka pracovníků nějak oddělená)

    Díky za nakopnutí

  2. Co se právě děje na Webtrhu?
  3. tohle je uplne klasickej obycejnej navrh
    tabulka zakazek
    tabulka pracovniklu
    spojovaci tabulka pracovnici-zakazky (s datumem od kdy do kdy jakej rpacovnik na zakazce je - pokud ma pracovnik pauzu tak bude mit dva zaznamy)

    nedelej proboha zadny silenosti kolem, nech datovou strukturu standardni, vsechno co potrebujes ti vyresi spravne dotazy, nic vic nic min... Upravovat nejak silene strukturu nebo vymejslet kraviny toho typu cos tu vymyslel nema jedinej smysl, tim mozna ulehcis praci sobe, protoze ocividne netusis co delas, ale bohuzel z toho bude pak jen sracka

  4. Já bych asi tu spojovací tabulku pojal jako timesloty - pro každého pracovníka generovat po přiměřených blocích (hodinách, půldnech, ... ), ty přiřazovat na projekt - zakázky, interní činnosti, přesuny, dovolené apod., zbylé bloky nechávat nepřiřazené. Jasné jak facka a odpadnou ti zmatky se zrušením přiřazení, s nestíháním přejezdu mezi zakázkami, ...., které bys tam dřív nebo později mohl chtít zohledňovat.

  5. Já bych to řešil tak, že by byla tabulka, kde by byl project_id, worker_id, workday_id. Jeden řádek, jeden pracovník. Takže když na projektu 1 ve workday 1 bude dělat 5 lidí, tak by tam bylo i 5 řádků...

    Obsazenost pracovníka by šlo řešit přes count(workday_id). Zároveň by se snadno vykazovaly hodiny na projektu...

  6. Aleš Jiříček:
    Však jsem psal, že mi to přijde jako prasečina :D ale chtěl jsem znát názor i někoho dalšího :) a ano z části jsem si to chtěl ulehčit :D

    ndpudo, siva01:

    no to jsou defacto řešení které jsem dával jako ty druhé, nicméně trochu prasácké mít pro každý den jeden řádek :/ ale pro práci pro mě snazší no

  7. Citace Původně odeslal Steeta Zobrazit příspěvek
    ndpudo, siva01:

    no to jsou defacto řešení které jsem dával jako ty druhé, nicméně trochu prasácké mít pro každý den jeden řádek :/ ale pro práci pro mě snazší no
    vůbec to není prasácké... Aspoň co jsem takhle četl v knížkách o SQL, tak všude tam řeší podobné situace právě takhle... Mně spíše připadá prasárna dávat více pracovníků na jeden řádek.. Na správu databáze by to bylo šílené. Nemluvě o těch dotazech o.O

  8. siva01: ano to je vůbec největší prasárna, o tom žádná. No zkusím to cestou dotazů na SQL a kontrolou rozmezí na sloupce DATE

  9. Respektive já mám takový nástroj, kterému říkám PriceMonitor. Sbírá ceny z Heureky. Z počátku jsem také měl tu db nenormalizovanou, ale nakonec jsem zjistil, že normalizace databáze mi ušetří spoustu času při analýzách. Je to možná trochu pomalejší, ale zato je to snažší na správu a práci.

  10. Tohle fakt čuňačina není, lepší mít databázi bombenfest und idiotensicher. Radši víc dat, která spolehlivě nejsou navzájem v konfliktu, jasných a "robustních", než vymýšlet vychytanou logiku, které rozumí sotva její autor a jež vezme zasvé s první změnou. Při zakládání pracovníka spustit vygenerování bloků, klidně 365*24h, a rezervovat a účtovat. Tohle si ošetříš snadno, zatímco překryvy a nepřekryvy a pracovník1 a pracovník2 a kde co nullable na jedné řádce, to je cesta do pekel.

  11. Citace Původně odeslal siva01 Zobrazit příspěvek
    vůbec to není prasácké... Aspoň co jsem takhle četl v knížkách o SQL, tak všude tam řeší podobné situace právě takhle... Mně spíše připadá prasárna dávat více pracovníků na jeden řádek.. Na správu databáze by to bylo šílené. Nemluvě o těch dotazech o.O
    Takový návrh je chybný, protože databáze bude obsahovat více jak 90% dat, která nejsou k ničemu potřeba (pokud jeden zaměstnanec pracuje na jednom projektu měsíc, je v databázi 29 záznamů z 30 k ničemu).

    Jediné, co je třeba znát, jsou změny. Tedy datum, kdy byl zaměstnanec přeřazen na jiný projekt.

  12. hosi... nebudu se s vama hadat, ale neda mi to vam nenapsat, ze vase reseni jsou slozita, generuji tuny zbytecnejch dat a stejne nakonec tu logiku psat musite... navic logika u tohodle bude jendoducha v kazdym pripade... na tomhel neni moc co vymejslet...

  13. Citace Původně odeslal Aleš Jiříček Zobrazit příspěvek
    hosi... nebudu se s vama hadat, ale neda mi to vam nenapsat, ze vase reseni jsou slozita, generuji tuny zbytecnejch dat a stejne nakonec tu logiku psat musite... navic logika u tohodle bude jendoducha v kazdym pripade... na tomhel neni moc co vymejslet...
    Vaše řešení je podobně špatné jako ta ostatní. Ukládat datum od do není potřeba a při dočasném přeřazení na jiný projekt vám bude vznikat více řádků, nehledě na to, že mimo vložení nového záznamu musíte upravit i ten předchozí. To je špatně.

  14. Rad to uznam, ale jen pokud napisete spravne reseni, abych se mohl poucit ;) Uprimne nechapu lidi co reknou - nemas pravdu - ale uz nereknou co je spravne, na takove lidi byvam sprosty

  15. Citace Původně odeslal Jan Stejskal Zobrazit příspěvek
    Takový návrh je chybný, protože databáze bude obsahovat více jak 90% dat, která nejsou k ničemu potřeba (pokud jeden zaměstnanec pracuje na jednom projektu měsíc, je v databázi 29 záznamů z 30 k ničemu).

    Jediné, co je třeba znát, jsou změny. Tedy datum, kdy byl zaměstnanec přeřazen na jiný projekt.
    Ježiš.. Když nepracuje, tak přece není žádný záznam v řádku. To je snad jasný, ne?

    ---------- Příspěvek doplněn 13.06.2016 v 15:00 ----------

    Když na tom v jeden den maká 5 lidí, tak je u projektu 5 řádků na den.. Když 4 lidi, tak jsou u projektu 4 řádky na den.. Nemaká nikdo? žádný řádek..

    Ad časové úseky: tak prostě přiřadím začátek a konec, ale stále je princip stejný. Místo pracovního den by bylo od a další sloupec do..

  16. Citace Původně odeslal Aleš Jiříček Zobrazit příspěvek
    Rad to uznam, ale jen pokud napisete spravne reseni, abych se mohl poucit ;) Uprimne nechapu lidi co reknou - nemas pravdu - ale uz nereknou co je spravne, na takove lidi byvam sprosty
    Ale já už to řešení napsal. Pokud jste to nepochopil, tak tedy polopatě: potřebujete tři tabulky, zaměstnanci, projekty a spojovací, kde je id zaměstnance, id projektu a datum. Datumem se rozumí datum změny, tedy den, kdy je zaměstnanec přeřazen na jiný projekt. Práci lze plánovat, přeřazovat zaměstnance mezi projekty operativně, získat přehledy hodin nad jednotlivými projekty atd. Vše na straně databáze. Nevzniknou žádná zbytečná data.

    ---------- Příspěvek doplněn 13.06.2016 v 15:04 ----------

    Citace Původně odeslal siva01 Zobrazit příspěvek
    Ježiš.. Když nepracuje, tak přece není žádný záznam v řádku. To je snad jasný, ne?

    ---------- Příspěvek doplněn 13.06.2016 v 15:00 ----------

    Když na tom v jeden den maká 5 lidí, tak je u projektu 5 řádků na den.. Když 4 lidi, tak jsou u projektu 4 řádky na den.. Nemaká nikdo? žádný řádek..
    Nepochopil jste. Vy potřebujete záznam v db, když se pracuje. A tento záznam je zbytečný. Není potřeba mít uloženo, že se pracuje. Stačí si uložit, kdy se začalo pracovat.

  17. Citace Původně odeslal Jan Stejskal Zobrazit příspěvek
    AJežiš.. Když nepracuje, tak přece není žádný záznam v řádku. To je snad jasný, ne?

    ---------- Příspěvek doplněn 13.06.2016 v 15:00 ----------

    Když na tom v jeden den maká 5 lidí, tak je u projektu 5 řádků na den.. Když 4 lidi, tak jsou u projektu 4 řádky na den.. Nemaká nikdo? žádný řádek..

    jsem to smazal.. už mi to došlo O:)

  18. Jan Stejskal: Nepochopil, bylo to zmineno bez vysvetleni a nejednoznacne, uz chapu co tim myslite a libi se mi to.

  19. Takže místo pracovní den bude začátek a konec (a v tom data typu date_id)

  20. Citace Původně odeslal siva01 Zobrazit příspěvek
    Takže místo pracovní den bude začátek a konec (a v tom data typu date_id)
    Ne, jen začátek. Konec není potřeba ukládat. Konec vznikne automaticky tím, že začne pracovat na jiném projektu. Pokud nebude pracovat vůbec, přiřadíte mu například projekt "volný".

  21. Jasně... Takže se pak rovnou můžu zeptat, kdo je volný a nemusím dělat žádné složité dotazy. Je to fakt jednoduché, tudíž i nejlepší řešení.

  22. Jan Stejskal:

    něco takového? Docela se mi to také líbí


    Kód:
    ID|ID_ZAMESTNANEC|ID_PROJEKT|DATUM
    --------------------------------------------
    1|1|1|2016-05-01
    2|1|2|2016-05-10
    3|1|1|2016-05-15

  23. Steeta: nepouzivej sloupec ID... proc to sakra furt vsude vsichni delaj :) pouzivej slozenej primarni klic... vyhod tedy ID a primarni klic das na id_zamestannec id_projekt a datum... id se pouziva kdyz nemas podobnou jednoznacnou identifikaci, tak si ji vytvoris, jeste vyjimecne kdyz to nekde hodne usnadnuje praci s tou databazi... ale tady to smysl nema
    Naposledy upravil Aleš Jiříček : 13.06.2016 v 15:35

  24. Citace Původně odeslal Steeta Zobrazit příspěvek
    Jan Stejskal:

    něco takového? Docela se mi to také líbí


    Kód:
    ID|ID_ZAMESTNANEC|ID_PROJEKT|DATUM
    --------------------------------------------
    1|1|1|2016-05-01
    2|1|2|2016-05-10
    3|1|1|2016-05-15
    Když už tak krásně všechno minimalizujete tak vyhoďte zbytečný sloupec ID

    EDIT: tak než jsem to přečetl a napsal tak už to napsal i AJ

  25. Když jsem dělal rezervační systém, tak jako nejlepší řešení mi přišlo, že jsem si určil nějakou jednotku času, ve tvém případě den a k těmto entitám jsem přiřazoval pracovníky. Každý den měl tedy svůj záznam a ten byl svázaný se záznamem pracovníka. Já to tedy dělal pomocí doctine, ale takový návrh mi přišel nejlépe použitelný co se týče rozšiřitelnosti a získávání dat.

    To že by to šlo navrhnout datově úsporněji, aby se sledovaly např. jen změny je jasné, ale nevím proč bych to dělal. Ušetřil bych sice data v DB, ale získávání dat z takové DB by bylo o dost náročnější a jak by se systém rozšiřoval, náročnost by ještě stoupala.

    Když chci např. výpis projektů a přiřazených pracovníků během týdne, vytáhnu 7 entit (dnů) a na ně je všechno navázané. Nepřijde mi normální, abych se při takovém výpisu hrabal někde "v minulosti".

  26. Martine z pohledu programovani s Doctrine te chapu, ale i s Doctrine jde snadno napsat to co navrhuje Jan Stejskal... A databazove to je narozdil od tech entit na kazdy praocvni den spravne... Na male db a malem systemu to nevadi... Ale ja uz casto delam systemy kde kazdy horsi navrh primo na db se strasne projevi na vykonu, takze absolutne uprednostnuju spravne navrhy db pred cimkoliv jinym...

  27. Záleží na situaci, nejlepší řešení se zdá ukládat jen změny, jak se psalo už nahoře

    Kód:
    id_zamestnanec, id_projekt, datum
    Případně id_projekt na 0 že nepracuje od daného data na ničem

    Pro získávání kdo je zrovna volný a kdo ne to je vpohodě, jakmile ale bude potřeba v budoucnu třeba získat kolik dní v měsíci pracoval na kterém projektu, tak bude problém, protože přepočítávat mezi datumy počty dnů a kdoví čeho a ještě kdyby pracoval na jednom projektu tak, že mezitím by měl dvakrát volno a ještě pracoval pár dní na jinačím, to si nedovedu tu šílenost představit, jak by se tohle přepočítávalo zpětně ;) V takovém případě už by se hodilo víc zase ukládat ty jednotlivé dny, protože by stačil jednoduchý nenáročný select dotaz

  28. Citace Původně odeslal kubiro Zobrazit příspěvek
    Záleží na situaci, nejlepší řešení se zdá ukládat jen změny, jak se psalo už nahoře

    Kód:
    id_zamestnanec, id_projekt, datum
    Případně id_projekt na 0 že nepracuje od daného data na ničem

    Pro získávání kdo je zrovna volný a kdo ne to je vpohodě, jakmile ale bude potřeba v budoucnu třeba získat kolik dní v měsíci pracoval na kterém projektu, tak bude problém, protože přepočítávat mezi datumy počty dnů a kdoví čeho a ještě kdyby pracoval na jednom projektu tak, že mezitím by měl dvakrát volno a ještě pracoval pár dní na jinačím, to si nedovedu tu šílenost představit, jak by se tohle přepočítávalo zpětně ;) V takovém případě už by se hodilo víc zase ukládat ty jednotlivé dny, protože by stačil jednoduchý nenáročný select dotaz
    Taky si myslím, že kdyby se systém rozrostl o další vazby a potřeby zjišťovat nějaké statistiky, zálohování a podobně, bylo byla by to docela magie. Sice by měla DB málo dat, ale nejsem si jistý, zda by získávání dat bylo pro DB méně HW náročnější. Určitě bych se neřídil pravidlem "méně dat" = "lepší návrh".

  29. Struktura [zakázka,pracovík,datum] je vhodná pro ORACLE a podobné DB, které umožňují v SQL relace mezi záznamy.
    I tak je ale vhodnější [zakázka,pracovík,datum od, datum do] např. s předpokladem, že zakázka is null znamená volný pracovník.
    To samozřejmě pro případy, kdy napíšeme query vracející žádaný výsledek. Frameworky a podobně podivné přístupy vracející uložená data na server, kde se teprve vše dopočítává, pak jakýkoli návrh DB degradují a ušetření atributu už nic nezachrání.
    SQL se sice může někomu zdát trochu fest, ale stojí to za to. (Doufám, že jsem se trefil do MyšQL.)

    Kód:
    select zakazka,pracovnik,
           sum(datediff(least(:obddo,zv.datumdo),greatest(:obdod,zv.datumod))+1)as doba
     from  zaznamyvytizeni zv
     where (zv.datumdo >= :obdod or zv.datumdo<= :obddo)
           and zakazka is not null
     group by zakazka,pracovnik
    Naposledy upravil takatom : 14.06.2016 v 00:41

  30. Citace Původně odeslal takatom Zobrazit příspěvek
    Struktura [zakázka,pracovík,datum] je vhodná pro ORACLE a podobné DB, které umožňují v SQL relace mezi záznamy.
    I tak je ale vhodnější [zakázka,pracovík,datum od, datum do] např. s předpokladem, že zakázka is null znamená volný pracovník.
    To samozřejmě pro případy, kdy napíšeme query vracející žádaný výsledek. Frameworky a podobně podivné přístupy vracející uložená data na server, kde se teprve vše dopočítává, pak jakýkoli návrh DB degradují a ušetření atributu už nic nezachrání.
    SQL se sice může někomu zdát trochu fest, ale stojí to za to. (Doufám, že jsem se trefil do MyšQL.)

    Kód:
    select zakazka,pracovnik,
           sum(datediff(least(:obddo,zv.datumdo),greatest(:obdod,zv.datumod))+1)as doba
     from  zaznamyvytizeni zv
     where zv.datumdo >= :obdod or zv.datumdo<= :obddo
           and zakazka is not null
     group by zakazka,pracovnik
    uprimne ja byhc to tim datumem od a do resil (takejsem to navrhoval jako prvni)... zkusil jsem vas sql dotaz na testovaci db a spravna data jsou venku ;) chtel sem to prepsat aby to pouzivalo jen datum zmeny a to se mi zatim nepovedlo... i kdyz verim ze to pujde taky... Jan Stejskal urcite uz vi?

  31. Citace Původně odeslal takatom Zobrazit příspěvek
    Kód:
    select zakazka,pracovnik,
           sum(datediff(least(:obddo,zv.datumdo),greatest(:obdod,zv.datumod))+1)as doba
     from  zaznamyvytizeni zv
     where (zv.datumdo >= :obdod or zv.datumdo<= :obddo)
           and zakazka is not null
     group by zakazka,pracovnik
    Aby bylo možné tímto způsobem získat skutečné počty, je třeba vyloučit víkendy, svátky a nějakým propojit s docházkou. V praxi bude důležitější získat počet člověkohodin na projektu než počet hodin jednoho zaměstnance nad všemi projekty.

    U návrhu pouze s datem změny jsou potřeba dva dotazy do db nebo použití procedury, je totiž nutné získat i poslední záznam před zadaným datem od (pokud mě zajímá pondělí až pátek a v pondělí nedošlo ke změně, potřebuji poslední záznam před pondělkem, abych znal id projektu). Protože je nutné vyloučit nepracovní dny, bude nutné mít výpočet na straně aplikace a pak má tento přístup výhodu v tom, že potřebujete pouze dva jednoduché dotazy do databáze (resp. čtyři, aby nebylo potřeba spojování tabulek, tzn. názvy projektů a jména zaměstnanců získáte každé vlastním dotazem).

Hostujeme u Server powered by TELE3