DB struktura-rezervace

Honza Pazdziora adelton na informatics.muni.cz
Úterý Srpen 12 12:47:40 CEST 2003


On Tue, Aug 12, 2003 at 09:20:13AM +0200, Karel Zak wrote:
> 
> > 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".
> 
>  On ten interval neni zase tak moc nelogicky. Proste nekdo, neco, na
>  nejakou dobu rezervoval. Problem je udrzovani takove tabulky (viz.

To puvodni zadani ale rezervace opomijelo, bylo to jenom o tom, ze je
potreba vedet, kolik je kdy jakych pokoju. Na to mi prijde jednodussi
to mit po dnech. Rezervace pak samozrejme nejakym intervalem, ty
rezervace je ale stejne nutne modelovat jinde, protoze muzu chtit mit
jednu rezervaci (a jednu transakci) na ruzne dny a ruzne typy a pocty
pokoju.

> > > >  relaci je mineno:    hotel-pocet_volnych_mist-casovy_interval-cena-stav
> > > >   ^^_ uvedeno na zacatku mailu
> 
>  Proc to uz na urovni modelu DB tak silene agregujete? Proc proste
>  nebudete jen udrzovat informace o obsazeni jednotlivych pokoju a
>  pokud budete potrebovat sumu o stavu volnych mist tak na zaklade
>  stavovenych podminek (hotel, cena, typ pokoje ...) si tuto vec za
>  chodu jednim selectem nespocitate?

No, pokud ma hotel 24 dvouluzkovych pokoju, cisla pokoju 101 -- 112,
202 -- 212, a v systemu by se rezervovaly primo konkretni pokoje, tak
by asi melo cenu delat to po pokojich. OP ale psal, ze tuhle informaci
(o konkretnim pokoji) v systemu nema. Cili ma dany den k dispozici 24
dvouluzkovych pokoju, z toho 13 za nejakou cenu a 11 za jinou, treba.
Prijde mi nejjednodussi tu informaci uchovat proste takhle.

Jakmile se provede vlastni rezervace, pravdepodobne se zaalokuje
konkretni pokoj, ale i tahle alokace se muze menit, a kazdopadne se
pak konkretni rezervace budou delat jinde.

>  Nezapomente, ze ve vice uzivatelskem prostredi vam nastane celkem
>  nepekny problem, ktery uz zde nekdo popisoval u skladu se zbozim. Lze
>  to popsat jako "vice obchodniku nabizi stejne zbozi ze stejneho
>  skladu a nevedi o tom, ze tak cini jeste jiny obchodnik - ke svemu
>  zdeseni to zjisti az ve chvili, kdy dojde k opravdovemu pokusu o
>  reservaci/prodani toho zbozi, ktere uz mezi tim prodal jiny obchodnik".
>  Z pohledu integrity DB to problem neni, ale z uzivatelskeho to muze
>  byt pekna neprijemnost, (IMHO) bez sance na nejake elegantni reseni.

Co jsem videl, tak rezervacni systemy, kam maji on-line pristup
zakaznici, to vetsinou resi tak, ze v okamziku pocatku prace
s konkretnim objektem (pokoj, luzko, letenka) tento zamknou pro jeho
session a po tuto dobu je tedy ten pocet dostupnych objektu zmenseny.
Systemy, se kterymi pracuji specializovani uzivatele, casto resi az
tu konecnou kolizi, tedy nechaji vyplnit objednavku a az pri pokusu
o transakcni vlozeni to kdyztak spadne.

U hotelu a agentur, ktere jim prodavaji pokoje, se to pak vcelku
snadno resi tak, ze dostanou z te hromady 500 pokoju k dispozici 20,
ty si pak prodavaji a v podstate off-line reportuji zpatky, a hotel
jim postupne muze davat dalsi pokoje k prodeji, zvysit tak jejich
hromadku. Pokud se tady jedna o primarni system pro stovky hotelu, tak
predpokladam, ze to bude nejaka podobna vec (protoze na vlastni
konkretni rezervace a evidenci pobytu kazdy ten hotel uz neco sveho
ma).

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


Další informace o konferenci Databases