DB struktura-rezervace

Pondělí Srpen 11 21:51:13 CEST 2003

On 11-08-2003 18.37 +0200, Honza Pazdziora wrote:
	zdravim,
  diky za odpoved.
> 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.
ano, je to trosku komplikovanejsi reseni.
> 
> > 		-cena
> 
> Nemuze se stat, ze je cena funkci typu pokoje a data?
ne, nemuze. je to system zavisly znacne na lidskem faktoru.
> 
> > 		-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.
ano, to je dulezity dodatek, ktery jsem opomenul. to by potom znamenalo
prepsani znacne casti database a vyhozeni hodne napsaneho kodu. sice nevim,
zda tento pripad nastane, ale kdyby, tak mam co delat.
z toho duvodu bude patrne lepsi reseni typu "co den, to dany typ
pokoje v danem hotelu".

> > 
> >  soucasny stav database:
> >  pominu, ze puvodni autor a jim napsana aplikace vytvorili 
> >  uz asi 250 tabulek.....
> 
> To je povzdech nebo indikace kvality toho autora?
autora radeji neresim.napsat to budu muset, tak ci tak. jen me udivilo,
ze nekdo byl schopen toto vytvorit. stacilo pridat jeden klic a tabulek
mohlo byt do deseti kusu.
> 
> >  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
ano, toto je chyba v zadani z me strany. cena tam byla take
zaimplementovana do vyse uvedene tabulky.
> 
> 	den_od
> 	den_do
> 	typ_pokoje
> 	cena
> 
> ? Kazdopadne jakmile bude potreba mit n+1 typu pokoje, tak nastane
> problem.
typy pokoju bych resil nejakym ciselnikem.
> 
> >  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. 
ano, v jednoduchosti je sila.
>Pokud to budete mit v databazi modelovane jako
> intervaly, ktere se muzou nejruznejsim zpusobem prekryvat a tak.
> 
zde nastava prave problem. uloha by to byla velice zajimava. ale, aby to
byl potom po me schopen nekdo to dal spravovat a rozsirovat.

> >   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.
nemohu prilis mluvit o detailech.
ale pocty hotelu jsou ve spodnich stovkach. doby a ceny reservaci se
lisi podle obdobi. muze to byt na cely rok, ale muze to byt i jen na
sezonu ci svatek. je to dost zavisle na lidskem faktoru.

zde vidim, ze se tato uspora prilis nevyplati.
> 
> Kazdopadne ale do celkoveho obrazku chybi nekolik informaci:
> 
> - kdo a jak tam bude informace vkladat?
uzivatele z klienstkych aplikaci.
> - je to primarni system, nebo jenom frontend pro spousty jinych
>   systemu?
primarni system
> - jak je to s temi cenami, k cemu se tam ty ceny vkladaji, jak se
>   muzou menit?
ano, mohou. musi to byt celkove realtimovy system. zmena se musi
okamzite projevit.
> - 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.
presne informace o pokojich (cislo pokoje, pocet zidli, ....) drzet nemusim.
staci pouze typ, pocet, cena, stav vzhledem k rezervaci.

dotatecny dotaz:
zde by me zajimalo, jak by bylo reseni pres intervaly odhadem narocnejsi
na vykon pocitace. zde pocitam, ze vcelku dost.

celkove resume:
vidim to na jednodussi reseni, i kdyz rad delam slozitejsi veci.
system ma jeste dost reserv na rozsireni. pokud by to bylo neco
komplexnejsiho ( to jmenovany system neni ), tak bych volil reseni pres
intervaly. ale zde je prusvih, ze za pul roku muzu system rozsirovat a
prepisovat. a toto riziko nechci podstupovat. prislo by potom hodne
prace nazmar.

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

	dik

   a zatim
   	pavel kysilka