構造を教えてください。

質問

php5mysql5にてホテルの予約システムのようなものを作りたく思っております。

予定の仕様としては2月分の(今月が9月だった場合は翌月の10月分)のカレンダーを表示させます。
2月分を一気に表示させるのではなく1月分づつ表示させる感じです。

管理側はいつの日に何人空いてるかを管理ページから変更できるようにしユーザーは空いてる日に
予約を入れるというよくありそうなものです。

一番悩んでいる箇所はmysqlのテーブル構造です。
基本的にはカレンダー表示なので単純ですが全ての月日をdbに登録する事になるのでしょうか？

その場合例えば以下のようなテーブルになると思うのですが1年だけでも365日あるので厳しすぎるような・・・
id,data,base,num
1(ホテルid),2009-09-25(日付),5(全部屋数),3(空いている部屋数)

としてbase-numで空いてる部屋数を割り出しユーザーが見るページに表示させるよう感じなのでしょうか？

そして上記で割り出した数字が0でなければyoyaku.php?id=1&data2009-09-25とリンクにパラメータをつけ
予約ページへと移動する？
と思っているのですがどのような方法で作るのが一般的なのでしょうか？

構造が明確になればイメージがわくのですが基本がわからずあやふやな状態です。

方法についてのアドバイスや参考になるようなurlの情報でも構いませんのでご存知の方が
いらっしゃいましたら宜しくお願い致します。

回答No.3

mdp36 · ベストアンサー

時間単位の予約システムでよく見かける構成なら、
・カレンダーテーブル・・・日別の営業時間や備考を保持する。
・予約枠テーブル・・・特定の部屋、時間帯に予約できる上限を保持。定期的に予約枠マスタから作成する。
・予約枠マスタ・・・曜日ごとの営業パターンを設定する。
・予約テーブル
・顧客マスタ
・部屋マスタ
・予約‐予約枠関係テーブル・・・予約と予約枠を対応させる。非正規化で予約テーブルにマージされることも。
という感じですね。ホテルではないですが。

＞1年だけでも365日あるので厳しすぎるような・・・
これは逆です。
1年で365件しか無いということは、100店舗で30年使っても1万件です。
この程度の量は全く問題ありません。

イメージがわかないとのことですが、プロトタイプを作りながら検討されるのはいかがでしょうか？

お礼

お返事ありがとうございます。
テーブル設計は是非参考にさせて頂きます。
>1年だけでも365日あるので厳しすぎるような・・・
これは1つづつデータを作る事を想定していたのでDBのサイズではなく手間の問題でした^^;

>イメージがわかないとのことですが、プロトタイプを作りながら検討されるのはいかがでしょうか？
お恥ずかしながらプロトタイプというものを初めて知ったのですがどのような意味でしょうか？

参考までに教えて頂けますと幸いです。

回答No.4

mdp36

＞プロトタイプ
日本語で言えば「試作品」ですね。
全体像がイメージできないなら、まず技術的に簡単だったり、データ構造が決まっている部分を作ってみて、その経験を踏まえて残りの部分の設計をしたほうが良い、という意味です。

http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%83%88%E3%82%BF%E3%82%A4%E3%83%97
http://ja.wikipedia.org/wiki/%E5%8F%8D%E5%BE%A9%E5%9E%8B%E9%96%8B%E7%99%BA

お礼

なるほど。phpプロトタイプで検索したのですがクラスの記述がヒットし？でしたが解決です。
皆様より頂いたアドバイスを基に作り始めてみたい思います。
ご丁寧に教えてた頂きましてありがとうございました！

回答No.2

seimurakam

> せめて1年分の日付だけでもcsvで自動出力してくれるようなものがあれば

とのことなのですが、自分も種々のシステムで構築案件で
#1さんと同じようにカレンダーテーブルを作成することがよくあります。
Excelのオートフィル機能を使うと、目的の形のCSVが1年分だろうと10年分だろうと
同じ操作であっという間にできるので楽ですよ。
あとはおっしゃるとおり、インポートすればOKです。

本質とは外れますが、ご参考までに。
がんばってくださいね！

お礼

なるほど！エクセルの手がありましたね！だいぶ作業が軽減できそうでうです。貴重なご意見ありがとうございます。

回答No.1

noname#94983

だいぶ昔になるが、旅館の予約システムの案件を請けたことがある。このときは、もっとも頻繁に参照されるのが「指定した日の空き室状況」になる、ということだったので、以下のような形でテーブルを用意した。

・空き室状況テーブル
プライマリキーに年月日を示す値（20090925とか、それぞれの使いやすい形式のユニークな値）を用意し、全室の部屋番号のフィールドを用意した。

・顧客テーブル
通し番号のプライマリキー（顧客ID）に、顧客の名前や住所などの個人情報を一通り用意した。

指定した月の予約状況を見る際には、その月の１日から末日までの範囲で検索をし、取得したレコードの各部屋の値をチェックして空き室状況を表示していく。

部屋の予約は、登録された顧客のIDでログインし、予約をすると、空き室状況テーブルの指定の年月日レコードの指定の部屋番号のフィールドに顧客のID番号を登録する。

顧客が予約の状況を確認したいときは、空き室状況テーブルで、各部屋のフィールドに顧客のIDがあるものを検索し一覧表示する。

まぁ、ざっとこういう感じだった。ただ、これがいいわけではまったくなくて、当時、既にある程度できてたシステムを踏襲して作らないといけなかったため、こういうシステムになった。正直、ネットの予約システムが珍しい頃だったので、この程度でもOKだったんだと思う。

今作り直すなら、「客室テーブル」「日付テーブル」「顧客テーブル」「予約テーブル」という具合に細分化し、わかりやすくするだろう。予約が入ったら、ユニークな予約番号を発行し、客室テーブル、日付テーブル、顧客テーブルにそれぞれ新しいレコードを登録する。そして、それらのレコードのID番号と予約番号を、予約テーブルに保管する。これで、客室・日付・顧客・予約番号のいずれからでも、調べたいところに保管されているID番号を取得し、それを使って他のテーブルを検索して必要な情報を取り出すことができる。またそれぞれを切り分けることで、例えば補足情報などのフィールドを追加し、テキストで必要な情報を追記できたりして便利だろう。

＞yoyaku.php?id=1&data2009-09-25とリンクにパラメータをつけ
＞予約ページへと移動する？

まあ、これはいろいろ考え方があると思う。セッションで保管する場合もあるだろう。これはシステムの設計によるだろうから一概にどれが一番とはいえない部分がある。それこそシステムを詰めてからでないとわからないんじゃないだろうか。

予約システムっていうのは、意外と機能がたくさんある。例えば表示も、カレンダーによる秋質状況の表示、特定の日付を指定すると各部屋の空き室状態が表示されるようなページ、顧客の個人情報ページ（予約状況とか）などが必要だろうし、それぞれのところで予約やキャンセルができないといけない。また最近はホテルでさまざまなプランを用意するのが一般的だから、「どのプランで予約するか」というようなことも必要だし、予約の内容（宿泊客数、食事の有無、ベッドや幼児用ベッドや毛布の有無など）も細かになってきている。そうしたことを考えると、なるべくテーブルを細分化し、修正が入っても一部のテーブルだけ修正するだけですぐに対応できるような形が望ましいと思う。

例えば、上記の４テーブルに、更に「プランテーブル」「詳細情報テーブル」とかを用意し、それぞれに予約番号を保管して整理するようにするとか。詳細情報テーブルには、プランの番号、宿泊客数、食事など細かな項目を用意しておく。プランが追加されればプランテーブルに新たにレコードを登録して対応できるし、必要な情報が追加になれば、詳細情報テーブルだけを修正して対応できるだろうし。（まあ、今、思いつきで書いてるからそこまで分けたほうがいいか、もう少しテーブルを統合したほうがいいかかは詰めて考えないとなんともいえないが）

まずは、必要な情報をすべて洗い出し、それらを整理して、なるべく細かなグループわけをしてまとめる。それで、必要なテーブルの構成が見えてくると思う。ま、参考程度に。

お礼

お返事ありがとうございます。
このように実例を基に詳しくご説明頂けますと非常に参考になります。
やはり日付を格納するテーブルは必要ですか・・・
となると曜日のフィールドもセットで組んだ方がいいですね。せめて1年分の日付だけでもcsvで
自動出力してくれるようなものがあればインポートするだけなので作業もだいぶ軽減できるのですが
地味な作業が続きそうですね^^;

言われてみて気づきましたがプラン等機能に応じてテーブルまたはフィールが増えるのは必然ですね。

基本的にはテーブルを分散化して紐づくidを参照しデータの取得を想定していますが確かに正確な機能リストを
練るべきですね。

おかげ様でだいぶイメージがつかめました。ありがとうございます。