DB struktura-rezervace

[Honza Pazdziora]

On Sun, Aug 10, 2003 at 05:00:36PM +0200, Pavel Kysilka wrote:
> 
>   tabulka relace hotel-pocet_volnych_mist-casovy_interval-cena-stav
> 		-id_hotelu
> 		-id_typ_pokoje
> 		-pocet_volnych_mist
> 		-volne_od
> 		-volne_do (pripadne jak dlouho volne)

Prijde mi to zbytecne komplikovane a nevidim, jakou vyhodu reseni pres
intervaly v tomto pripade misto jednotlivych dnu prinasi, s vyjimkou
uspory mista.

> 		-cena

Nemuze se stat, ze je cena funkci typu pokoje a data?

> 		-stav (obsazeno, rezervovano,volne)

Tady ale asi stejne budete potrebovat i informace o tom, kdo
rezervoval, co, na jak dlouho. Pokud ne dnes, tak za chvili urcite.

>  doslova je potreba zajistit, aby pro kazdy hotel bylo znamo kolik ma v
>  danem case volnych pokoju, za kolik a jaky typ pokoje.
>  zaroven se dane pokoje v hotelu mohou objednavat.

A ta objednava ma byt zadana jak? Jenom ano/ne?

>  konkretni udaje o kazdem pokoji z hotelu v databasi nejsou.
> 
>  doplnujici podminky:  vyhoda reseni pres intervaly se muze vyuzit, ale
>  i nemusi. nekdy se zadava rozdilna cena pro dany pokoj na kazdy den.
>  nekdy muze byt cena stejna po dobu par mesicu.
> 
>  soucasny stav database:
>  pominu, ze puvodni autor a jim napsana aplikace vytvorili 
>  uz asi 250 tabulek.....

To je povzdech nebo indikace kvality toho autora?

>  co se tyce obejdnavani pokoju, je to reseno tabulkou s touto strukturou
>  
>  - konkretni_den ( co den, to cislo.......)
>  -id_hotelu
>  -typ_pokoje_1
>  -pocet_volnych_pokoju_typ_1
>  -typ_pokoje_2
>  -pocet_volnych_pokoju_typ_2
>  .........
>  -typ_pokoje_n
>  -pocet_volnych_pokoju_typ_n

Tady je samozrejme problem s tim, ze tady neni videt cena. Nebo cena
vyplyva z nejakeho registru

	den_od
	den_do
	typ_pokoje
	cena

? Kazdopadne jakmile bude potreba mit n+1 typu pokoje, tak nastane
problem.

>  mnou navrhovane reseni:
>  napadlo me udelat reseni s relacemi pres intervaly.
>  relaci je mineno:    hotel-pocet_volnych_mist-casovy_interval-cena-stav
>   ^^_ uvedeno na zacatku mailu
>  
>  ale toto reseni je narocnejsi na spravu. ale to by se dalo resit pres
>  procedury v PgSQL ( database, na ktere to pobezi ).
> 
>   nastava, zde ale jeden problem. a to je fragmentace intervalu ( neznam
>   lepsi termin). jak se postupne pokoje objednavaji, vznika cim dal tim
>   vice intervalu (relaci). cilize by se to muselo (mohlo ), nejak vzdy v
>   noci prepocitat, aby se sloucily do jednoho intervalu relace se
>   stejnymi vlastnostmi. ale i toto je resitelne.
> 
>   kazdopadne se mi jevi mnou navrhovane reseni, jako nejlepsi a 
>   nejvice systemove.
>   je to lepsi, nez mit pro kazdy den jeden zaznam.

Mistem v databazi ano, jinak si nejsem jisty. Predpokladejte, ze
potrebujete zjistit, zda od 4.9.2003 do 11.9.2003 jste schopen udelat
rezervaci dvou dvouluzkovych pokoju typu Q za cenu P a tri
jednoluzkovych typu R za cenu S. Pokud to budete mit v databazi
po dnech, tak to udelate jednim vnorenym dotazem s par agregovanymi
funkcemi. Pokud to budete mit v databazi modelovane jako
intervaly, ktere se muzou nejruznejsim zpusobem prekryvat a tak.

>   dotaz:
>   
>    pokud ma nekdo lepsi reseni, dejte vedet v konferenci. urcite bych
>    rad videl i jina a predevsim lepsi reseni.
>    
>    mozna je mnou navrhovane reseni prilis narocne na vypocty (zejmena
>    selecty). zde by mne zajimalo, zda ano ci ne.

Navrhuji zvazit, kolik budete mit hotelu a kolik pokoju (typu) a na
jak dlouho dopredu beudete rezervovat. Protoze pokud byste mel mit
misto 365 zaznamu pro jeden typ pokoje 30 intervalu, tak se uz takova
uspora mista ani nevyplati, mely by-li byt tan tim operace nejake
komplikovane.

Kazdopadne ale do celkoveho obrazku chybi nekolik informaci:

- kdo a jak tam bude informace vkladat?
- je to primarni system, nebo jenom frontend pro spousty jinych
  systemu?
- jak je to s temi cenami, k cemu se tam ty ceny vkladaji, jak se
  muzou menit?
- pokud je to sekundarni system, znamena to, ze jednou denne do neho
  nekdo posle informace typu "a od pokoje Q mame v hotelu H45 na
  5.9.2003 jeste 4 za 700", nebo budou chodit zmeny typu "prodali jsme
  dva pokoje typu Q na 5.9.2003 a u zbyvajicich zvedli cenu ze 650 na
  700"?

Teprve na zaklade znalosti toho, jak ma cela ta vec komunikovat
s okolim, kde se tam berou data, odkud jdou a kam, bych se odvazil
delat nejakou datovou analyzu. Ono z toho totiz vyplyne, co budete
potrebovat o tech pokojich drzet.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, auth. WWW servers, XML/XSL, ...
		Only self-confident people can be simple.