pozdrav svima.
Zanima me optimalno rijesenje.
naime, radim jednu skriptu za godisnje bookiranje apartmana. za svaki apartman bi trebao imati 3 moguca stanja za svaki dan u godini. zauzeto/slobodno/cekanje.
kako da konfiguriram bazu?
stavim u tablicu 365 polja ili ima nesto normalnije.
Takodjer mi je bitno da se iz moguceg ponudjenog rjesenja mogu pretrazivati apartmani po slobodnim danima.
puno pozdravaljam i zahvaljujem na odgovorima
Tango
Pretpostavimo da nemaš puno apartmana (mali iznajmljivač, zar ne?) - tada bi se dizajn baze mogao napraviti ovako:
CREATE TABLE apartmani (
apartmanID TINYINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
datumStart DATETIME NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
datumStop DATETIME NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
status ENUM( ‘0’, ‘1’, ‘2’ ) NOT NULL DEFAULT ‘1’,
) ENGINE = MYISAM ;
gdje su stupci apartmanID i status reference nekakvom popisu koji se može harkodirati u aplikaciju[php]<?php
$apartman = array(1 => ‘tamaris’, ‘agava’, ‘lavanda’, ‘[nastavi niz]’); // dummy nazivi apartmana
$status = array(‘zauzeto’, ‘slobodno’, ‘čekanje’);
?>[/php][quote=""]Takodjer mi je bitno da se iz moguceg ponudjenog rjesenja mogu pretrazivati apartmani po slobodnim danima.[/quote]Baza se pretražuje tako da se usporedi traženi datum s datumima kad je apartman slobodan odnosno zauzet (pogledaj poglavlje MySQL uputa o datumima).
MAMICE, HVALA na odgovoru…
hm. imam jako veliki broj apartmana za kontrolu zauzetosti. trenutno oko 1500 komada.
i jos bih zelio to sve prikazat graficki, u obliku 12 mjesecnog kalendara gdje ce datumi biti razlicito obojani zavisno od ona 3 statusa apartmana.
znam da nece bitl lako to napravit, ali moram se uhvatit u kostac sa tim, pa mi je svaka dobra informacija od itekkakve koristi.
pozdrav svima
Dakle:
Prvo odrediš nulti datum (npr. 01.01.2007.).
Zatim u tablicu apartmana dodaš 1 polje po godini u koje ćeš postaviti običan string dugačak onoliko koliko godina ima dana (365 ili 366) tako da svako mjesto u strnigu određuje točno određeni dan. Taj string se sastoji od nula, jedinica ili dvojki, a svako od tih stanja određuje status zauzetosti (slobodno, zauzeto ili na čekanju).
Kad se stanje promijeni, tada mijenjaš samo brojku na tom mjestu u stringu.
Na ovaj način ne opterećuješ bazu previše, a cijenu je moguće odrediti za svaki dan posebno. Naravno, tablica cijena će referencirati na mjesto u stringu.
Ovo je osnovna ideja. Osim toga, moraš uzeti u obzir duplanje datuma, tj. situaciju da će u određenim situacijama na jedan dan jedan gost odlaziti, a drugi dolaziti. Takav primjer možeš riješiti sa dodavanjem još jednog identičnog polja po godini, pa će ti prvo takvo polje označavati dolaske, a drugo odlaske. Algoritam za ispravno računanje dana rezervacije i kalkulaciju je na taj način prilično jednostavan.
Dakle, za 5 godina, 10 polja.
Duboko preporučan da radiš sa integer brojevima, dakle da ne koristiš date tip podatka… U prijevodu, budi nježan prema serveru i bazi. 
[quote=""]hm. imam jako veliki broj apartmana za kontrolu zauzetosti. trenutno oko 1500 komada.[/quote]Ne može jednostavno, zar ne? 
Onda hardkodirane apartmane prebaci u vlastitu tablicu i samo se putem apartmanID ključa referenciraj na tablicu iz mog prvog prijedloga (u nju naravno dodaj novi ID primarni ključ jer postojeći apartmanID ne može imati tu funkciju).
Ponavljam, najveća greška je koristiti datetime tip podataka. Kod većeg broja requesta, datetime tip podatka je najčešće usko grlo.
Sve što možeš spremaj kao obični broj.
Također, izaberi bazu u kojoj možeš raditi kvalitetno storice, a transaction mehanizam je skoro pa nephodan.
Također, uzmi u obzir da sezone (vremenska razdoblja sa istom cijenom smještaja, popustima i cijenom boravišne pristojbe) ne počinju svake godine na isti datum. Isto tako, ako pravilno dizajniraš bazu, kopiranje sezona u slijedeću godinu je jednostavno, a inače može biti noćna mora.
[quote=“Šljaker”]Duboko preporučan da radiš sa integer brojevima, dakle da ne koristiš date tip podatka… U prijevodu, budi nježan prema serveru i bazi.[/quote]Eh, sad si i meni dao misliti… imaš li kakvu literaturu (ili barem link) o ovome?
MySQL upute govore o veličini podatka date i datetime, ali nigdje ne vidim ništa o drugim opterećenjima.
sljakeru, dankešn.
znaci, prakticki bi moga imat tablicu sa dva stupca(ako cijene vodim odvojeno). jednu za apartmanID a drugu za string statusa apartmana. taj string moram uzeti kao tinyint, i u akcijama cu taj string tretirat kao array i baratat kljucevima zavisno o kojem se danu u godini radi.
i mislio sam da je to najbolje rijesenje…
jos samo trebamo odrediti kako izdvojiti apartmane koji imaju npr 232 dan status “slobodno”. jer krajnji mi je cilj izbacivati(izlistati) samo one apartmane koji su slobodni u navedenom terminu, ili barem da su slobodni za datum pocetka trazenog termina.
hoce li mi puno ta akcija cešljanja svakog stringa od 365 znakovaX2 pri pretrazi uzeti resursa?
imam ja jedan sustav koji je napravljen za 3 mjeseca. radio sam 90 polja u bazi. svako polje za svoj dan.
ali sada mi je cilj obuhvatiti cilu godinu pa bih voli krenuti sto tocnije u taj projekt. jer ako krenem krivo naj… sam.
Datetime tip podatka se tipično prikazuje kao cijeli broj - primjerice, broj sekundi od nekog prešutnog datuma.
[quote=“tango”]jos samo trebamo odrediti kako izdvojiti apartmane koji imaju npr 232 dan status “slobodno”. jer krajnji mi je cilj izbacivati(izlistati) samo one apartmane koji su slobodni u navedenom terminu, ili barem da su slobodni za datum pocetka trazenog termina.
hoce li mi puno ta akcija cešljanja svakog stringa od 365 znakovaX2 pri pretrazi uzeti resursa?[/quote]
Upravo si se dotaknuo pravog problema - pretrage.
Naime, kako ćeš organizirati tablice s podacima i koji ćeš tip podatka koristiti je ustvari sekundarni problem…
Kod pretrage ćeš imati 2 slučaja:
Ovo što si naveo
To je relativno lako riješiti jer se da izvesti na taj način da filtriranje danas (+ 7 dana) slobodnih termina izvedeš samo jednom dnevno pa rezultate spremiš u privremenu tablicu. Npr. kod prikaza naslovnice da se provjeri da li za taj dan postoji svježa privremena tablica te da se prikažu već filtrirani rezultati. Ako pak privremena tablica nije svježa (jučerašnja) da je prvo kreira.
Na taj način opterećenje dobijaš samo kod PRVOG dnevnog učitavanja.
Što se tiče tehnologije, preporučam storicu jer je najbrža i najsigurnija…
Posjetitelji pretražuju za neko vrijeme unaprijed (uobičajena akcija)
Opet je puno lakše i brže pretragu napraviti po stringu.
Naime, obzirom da se pretraga temelji na nekom datumu, prvo izračunaš njegovo mjesto u stringu. Zatim već u samom requestu (WHERE) odrediš izvlačenje samo onih stringova koji na tom mjestu nemaju status “zauzeto”.
Još je elegantnije ako cijeli kod staviš u storicu…
Ustvari, problemi pretrage u turizmu, kao i kalkulacije obzirom na sve silne popuste, dodatke i promjenjivost cijena - to su najveći problemi takvih aplikacija.
Dane i dane sam potrošio na osmišljavanje najbržih sustava koji će najmanje opterećivati bazu. U tome su mi pomagale doista velike agencije, pa smo jednom imali bazu veličine 17 GB sa preko 20.000 smještajnih jedinica i svim financijskim podacima unazad par godina. Ovakav se pristup pokazao optimalan, ali i dovoljno fleksibilan za sva moguća proširenja i nadogradnje.
Ponavljam, nemoj smetnuti s uma da na isti datum jedan gost odlazi, a drugi dolazi. Taj problem trebaš riješiti u fazi dizajna baze!
Upravo u tome i jest štos.
Naime, za turizam je osnovna obračunska jedinica dan, dok sati eventualno igraju ulogu kod odlaska i dolaska, te kod eventualnih dnevnih boravaka (hotelski smještaj). Ustvari, idealna interna obračunska jedinica je pola dana, dok sati i sekunde ne igraju niti kakvu ulogu.
Dakle, ako opseg brojeva za računanje smanjiš za par redova veličine, skoro za toliko ubrzavaš sve operacije s tim brojevima. Kod većeg broja requesta (kako je navedenu u primjeru - 1500 apartmana), ušteda vremena se multiplicira, a samim tim i opterećenost sustava.
P.S. Ovo je odgovor i za Mamicu.
kako nasi poljoprivrednici i voćari kažu:
ako voćku krivo navrneš ni sam bog je neće posli ispravit.
zato bas i ja mozgam o svim mogućim kombinacijama za pocetak. ovaj posa mi visi nad glavom pa ga se moram uvatit kad tad.
a kao sto si sam reka, u turizmu svaki apartman svoju politiku vodi, od termina cijena, popusta za dane borava, popusti za mladje teenagere, popusti za starije teenagere, boze ih sacuvaj. onda ti moras napravit sustav koji ce uzeti u obzir sve moguće filmove hotelskih sales managera. … i na kraju krajeva uvik nesto izostavis.
vidim da si radio pa ti je problematika veoma jasna.
molim te reci mi na koji pojam mislis kad kazes “storica”?
I, da: zašto sam predložio string?
Pa zato jer stringove možeš spremiti u full text catalog, čime neusporedivo ubrzavaš sve pretrage. Tek nakon filtriranja full text search funkcijama filtrirane rezultate dalje obrađuješ i eventualno transformiraš u neki drugi tip podatka.
Naime, full text search je definitivno najbrži način pristupa podacima, a najmanje opterećuje bazu jer koristi gotovi catalog.
“Storica” je stored procedure, regularni objekt u bazi podataka.
Dakle, ta tehnika ti omogućava da napišeš proceduru kakvu god želiš pa je sačuvaš “unutar” baze za stalno.
Osnovna prednost je brzina jer se na taj način najbrže rade operacije na bazi.
Druga je prednost maksimalna nadogradivost. Treća je prednost najbolja preglednost koda jer je dobra praksa da kroz storice radiš zahvate na bazi, a kroz kod aplikacije samo šalješ ulazne parametre za proceduru. Itd.
Storica se piše u čistom SQL-u, a svaki proizvođač baza ga proširuje vlastitim ekstenzijama. Npr. takav prošireni SQL se u slučaju MS SQL Servera zove T-SQL.
sljakeru, svaka ti dala…
znaci definitivno cu ici stringom kao patternom za status pojedinog dana u godini. uz to cu i ogranicit pretragu samo na godinu unaprijed (kroz php), te cu dobiti nekakvu strukturu od 720 znakova u kolumni.
1,1,1,2,2,2,0,0,0,0,1,1,1,1,2,1,1,1,1,2…
a moga bi probat i bez ovih zareza, sta mislis. samo da stavimn spejs.
1= zauzeto
0 = slobodno
2= izmjena gostiju.
3= na cekanju…ovo isto triba uzet u obzir (sad mi je palo na pamet…)
mislim da 720 znakova nije puno za pretragu.
a cak za pocetak mislim koristiti i
SELECT SUBSTRING (‘string_iz_kolumne’, ‘dan_u_godini’, 1)
ovo je sigurno sporije, ali cu krenut za pocetak sa tim, pa kasnije kad uvidim jos neki problem (a sigurno ce ih bit) , da imam manje stvari za minjat.
a kad se stvarno napuni podataka onda cu indexirat tablicu.
svako koliko bi tribalo indexirat tablicu i kolika je po tvom iskustvu treba biti tezina tablice da ides sa full text searchom?
Kao prvo, zarez ti ne treba, a ni razmak. Obzirom da se niti jedno stanje ne sastoji od 2 znamenke, svaka znamenka = točno određeni dan u godini.
Zatim, ne treba ti ni fiksni broj znakova u stringu. Naime, sami string će ustvari povećavati aplikacija kada se budu upisivali termini različiti od nule. To znači da ne moraš unijeti u startu string od 365 nula, nego će se kreirati onda kad se bude zauzimalo.
Npr. na početku nema stringa, što znači da je slobodan u svako vrijeme.
Ako gost rezervira od 03.01. do 09.01., onda će aplikacija promijeniti string u nešto tipa “001111111”, a to će značiti da su svi drugi dani slobodni. Na taj način se dodatno ubrzava i optimizira pretraga…
Broj dana koje ćeš unaprijed omogućiti u pretrazi nije fiksni broj (ti si naveo 720). Ustvari, aplikaciju trebaš napraviti da pretražuje samo one termine za koje postoji cijena.
Što se tiče full text searcha te indexa, najbolje je raditi rebuild svaku noć. Tada trebaš raditi i sve druge radnje za higijenu baze (backup, shrink, error checking…). Ako izabereš transakcijski database sustav, na taj način jako teško možeš izgubiti podatke.
Ja se isto baš sad zezam s tim booking kalendarom, samo ja bi to napravio nešto slično ovom.
I da, mislio sam raditi s datumima oblika dd/mm/yyyy, jer ne mislim da će stranica bit nešto posjećena. Ako bude, rado ću im napraviti novu.
Mene zanima kako unutra cijele godine odrediti koji dani su vikendi, mislim znam to napraviti, ali me zanima jel ima neko jednostavno rješenje/f-ja?
Ne shvaćam pitanje…
Što misliš pod određivanjem vikenda?
Ako koristiš datetime podatak, onda ga možeš interno prikazivati kao dugi oblik pa se web server brine o tome koji je dan u tjednu.
Ja kako postavim pitanje, uvijek sebe samog zbunim 
Htjeo bi isto onako ispisati cijelu godinu po datumima, ali ne znam kako bi to najjednostavnije napravio. Ne koristim datum oblika datetime, već u bazu spremam dd/mm/yyyy.
Sljakeru…
napomenuo si se string povecava zavisno o upitu. Tj. najudaljenijem datumu u buducnosti za koji je trazen upit.
to je super
ali da bi se izbjeglo svakodnevno updateiranje servera radi pocetnog datuma, mogu se zadrzavati i neke akcije iz proslosti. Ali kad se napravi recover baze, onda ce se svakom stringu odrezati onoliko pocetnih znakova koliko je dana proslo od posljednjeg recovera. (substr)
tako da ce nakon recovera prvi znak u stringu odnosit na danasnji datum (datum recovera).
mislim da bi to bilo cak i mudrije a izbjeglo bi se svakodnevni recover i nocne cron akcije
ali u tom slucaju bi se uvela jos jedna informacija za evidenciju zadnjeg datuma recovera.
kad se postavi pravilno tabica sa podacima output je stvar kozmetike.