Struktura DB, rezervace

13. 6. 2016 15:05:00

Napsal Jan Stejskal;1299124
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:)

13. 6. 2016 15:05:00

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201954

(20 hodnocení)

13. 6. 2016 15:06:18

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

13. 6. 2016 15:06:18

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201953

Luděk Kvapil

13. 6. 2016 15:06:46

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

13. 6. 2016 15:06:46

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201952

Jan Stejskal

(7 hodnocení)

13. 6. 2016 15:11:34

Napsal siva01;1299128
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ý".

13. 6. 2016 15:11:34

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201951

Luděk Kvapil

13. 6. 2016 15:14:50

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

13. 6. 2016 15:14:50

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201950

Steeta

(3 hodnocení)

13. 6. 2016 15:14:56

Jan Stejskal:

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

13. 6. 2016 15:14:56

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201949

(20 hodnocení)

13. 6. 2016 15:17:46

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

13. 6. 2016 15:17:46

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201948

(17 hodnocení)

13. 6. 2016 15:32:32

Napsal Steeta;1299131
Jan Stejskal:
něco takového? Docela se mi to také líbí
ID|ID_ZAMESTNANEC|ID_PROJEKT|DATUM--------------------------------------------1|1|1|2016-05-012|1|2|2016-05-103|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

13. 6. 2016 15:32:32

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201947

Martin

(62 hodnocení)

13. 6. 2016 17:26:27

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

13. 6. 2016 17:26:27

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201946

(20 hodnocení)

13. 6. 2016 17:48:09

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

13. 6. 2016 17:48:09

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201945

Default

(94 hodnocení)

13. 6. 2016 20:27:42

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

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

13. 6. 2016 20:27:42

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201944

Martin

(62 hodnocení)

13. 6. 2016 22:45:21

Napsal kubiro;1299213
Záleží na situaci, nejlepší řešení se zdá ukládat jen změny, jak se psalo už nahoře
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".

13. 6. 2016 22:45:21

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201943

takatom

(2 hodnocení)

13. 6. 2016 23:47:58

Struktura je vhodná pro ORACLE a podobné DB, které umožňují v SQL relace mezi záznamy.

I tak je ale vhodnější 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.)

13. 6. 2016 23:47:58

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201942

(20 hodnocení)

14. 6. 2016 00:00:28

Napsal takatom;1299252
Struktura je vhodná pro ORACLE a podobné DB, které umožňují v SQL relace mezi záznamy.
I tak je ale vhodnější 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.)
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?

14. 6. 2016 00:00:28

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201941

Jan Stejskal

(7 hodnocení)

14. 6. 2016 09:03:58

Napsal takatom;1299252

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

14. 6. 2016 09:03:58

0 0

Líbí se: zatím nikdo

Nelíbí se: zatím nikdo

https://webtrh.cz/diskuse/struktura-db-rezervace/strana/2/#reply1201940