データベーステーブル設計
- レストランデータベースのシンプルなアプリケーションを作成する際に、どのようなテーブル設計が最適かについて教えてください。
- レストランの情報を表示するアプリを作りたいですが、レストラン名、住所、電話番号、営業時間、評価をどのように設計するのがベストでしょうか。
- レストランのデータベースを作成する際に、評価をどのように扱えば良いかについて教えてください。
- ベストアンサー
データベーステーブル設計
簡単なアプリケーションを作ろうとしています。内容は、レストランのデータベースです。画面には、単純にレストラン名、住所、電話番号、営業時間、評価を表示させたいです。この「評価」は、このアプリケーションを使用する３人のユーザが入力する１～５の値の平均値としたいです（ユーザはメンテナンス画面から１レストランにつき１回まで評価値入力可能）。つまりユーザAが４、ユーザBが５、ユーザCが１を入力した場合、4+5+1/3=3.3を表示します。テーブルを設計した経験がないので教えてほしいのですが、この場合、どのようなテーブルを作れば最もシンプルできれいに出来るのでしょうか。まずレストランテーブルを作成する必要があると思いますが、「評価」があるために１テーブルでは不足だと思います。評価カラムの値はユーザが値を入力すれば変動することになるので、別テーブルを参照させるようにすべきなのでしょうか？評価テーブルというものを考えてみましたが、ユーザ名とレストランIDの複合をプライマリキーとし、評価値カラムをもたせるとしても、どこに平均値を持たせればいいのかわかりません。テーブル設計の模範例を教えて頂けると助かります。宜しくお願いします。
- rio_grande
- お礼率77% (349/452)
- Oracle
- 回答数2
- ありがとう数2
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
基本は次のとおりです。 レストランテーブル （レストランID，レストラン名，住所，電話番号，営業時間） ユーザテーブル （ユーザID，ユーザ名） 評価テーブル （レストランID，ユーザID，評価） 平均値はDBに格納せず，SELECT検索のたびに AVG(評価) 集約関数で計算させて出力します。ユーザは特定の３人に限定せず，多数のユーザが投票してもその評価の平均を出力することができます。 この設計で運用を進めてみて，「使用しているサーバの性能があまり高くなく，テーブルを結合したり AVG(評価) 計算していると時間がかかることが分かった」ということが判明したのであれば，この基本の正規形をあえて崩すことは検討するかもしれません。
その他の回答 (1)
- jjon-com
- ベストアンサー率61% (1599/2592)
> レストランID、ユーザIDの複合を > プライマリキーにすればよいですよね？ はい，そのとおりです。
お礼
有難うございました！
関連するQ&A
- データベースの設計について教えてください。
データベースの設計について教えてください。 基本的な質問ですみません。宜しくお願いいたします。 単純なテーブルで表現しますが、 パターンA、Bのどちらのテーブルで設計するのが良いのでしょうか。 DBはmysqlで5000万件のデータで検索のみのデータベースです。 【前提】 ユーザは複数のメールアドレスを持ちます。 画面から、このユーザのもつメールアドレスを表示させる仕様だとします。 【userマスタ】 (PK)ユーザID ユーザ名 会社名 ＜パターンA＞ 【mailテーブル】 (PK)ユーザID (PK)ユーザメールアドレス モバイル用アドレス ＜パターンB＞ 【mailテーブル】 (PK)ユーザメールアドレス モバイル用アドレス ユーザID ←インデックスをはります。
- ベストアンサー
- MySQL
- テーブル設計について
簡素なウェブアプリケーションを作成しようとしています。テーブルの設計をしているところなのですが、あまりしっくり来ないのでアドバイスを頂きたいです。 仮にスタッフというテーブルがあるとします。スタッフテーブルには名前、性別、生年月日というカラムがあります。これに階級を付け、その履歴を追えるように変更したいです。つまり、スタッフAさんは1998年にアシスタント、2000年にチームサブリーダー、2005年から現在に至ってチームリーダー。。といったような情報を（必要があれば）クエリで取得できるようにテーブルに変更を加えたいです。 まずは階級名自身が変更、追加になることを考えてランクというテーブルを作成しました。属性は、プライマリキーとランク名です。 イメージ 1 | アシスタント 2 | チームサブリーダー 3 | チームリーダー 4 | ディレクター ... 次に、スタッフテーブルにYEAR1、ランク１、YEAR2、ランク２、YEAR3、ランク３という属性を持たせスタッフテーブルからランクテーブルに参照させようかと考えたのですがこれだと数に限りがあるしなんだかあまり柔軟性がないような気がします。このような場合、階級の変更の回数を気にしなくていいような何らかの新しい別のテーブルを作る方法などありますでしょうか？もしそうだとするとどのような属性を持ったテーブルをつくればよいでしょうか？テーブル設計には色々な方法があるのは承知していますが、もしお薦め出来る（出来れば一般的な）いい方法があればアドバイスお願いします。
- ベストアンサー
- その他(データベース)
- データベースの設計をしています。
データベースの設計をしています。 ユーザマスタというテーブルがあり、 その中には、個人または企業のデータが入ります。 マスタ登録時に個人と企業は微妙に必須項目が違います。 (例えば、企業の場合は代表者名が入る、など) 要件としては、「企業だけを検索したい」というものもあります。 ここで質問なのですが、 (1)ユーザマスタに「企業フラグ」をつけて、それが「1」のものと検索する (2)代表者名に値が入っているものを検索する この場合、(1)と(2)ではどちらが検索が速いのでしょうか。 (1)の方が、気分的に(なんとなく、です)速い気がするのですが、 (1)だと、余分にカラムを持つことになり、もし(1)も(2)も同じ速さOR(2)の方が速い場合には 無駄だなあ、と思って困っております。 どなたかお詳しい方がいらっしゃいましたら、 どうぞよろしくお願い致します。
- ベストアンサー
- MySQL
- コラムの値からコラム・テーブルを検索
プライマリキーが様々なテーブルで別の名前で利用されていると、テーブル同士の関連の全てが把握できずに困っています。以前にコラム名からテーブルを検索する方法を質問したのですが、私が扱っているデータベースでは、プライマリキーがシステムの別の場所で少しだけ異なる名前で利用されていることが多いので、その方法では把握できない関連が出てきます。 具体的には、EMPLOYEES__KEYというEMPLOYEESテーブルのプライマリキーがPERSONALIZE_EMPOYEESというテーブルでPSNLZ_EMP__KEYという名前で使われている状況を考えていただきたいと思います。PSNLZ_EMP__KEYのコラムのレコードは全てEMPLOYEES__KEY内のデータからとられているとします。 以前にselect TABLE_NAME from USER_TAB_COLUMNS where COLUMN_NAME = 'EMPLOYEES__KEY' というSQLで特定のコラムを使っているテーブルを全てリストアップできると教えていただいたのですが、今回のケースでは、同じような内容のコラムなのですが名前が異なるため上記のSQLでは検索できないテーブルがある場合、それをどうやってとってきたらよいのかということです。 コラムの値にtaro, jiro, hanakoなどのようにテーブルまたはシステム内でユニークな値が指定されている場合、コラムの値を指定し、「その値が使われているコラム・テーブルを列挙せよ」というような命令を与えればよいのだということまでは分かりますが、どのようにSQLを書けば良いか教えてください。
- ベストアンサー
- Oracle
- データベースのマスタ設計についての質問
現在データベースの設計を勉強しています。 マスタの設計について疑問があって質問しました。 【1】すべてのマスタデータを統合したテーブルを作成 カラム１：カテゴリID(PK) カラム2：カテゴリCD(PK) カラム3：値 【2】それぞれのカテゴリに応じたテーブルを作成 カラム1：カテゴリCD(PK) カラム2：値 ※私はパターン１の方が、カテゴリの追加等柔軟かなと考えています。 それぞれのパターンの長所・短所を教えてください。
- ベストアンサー
- その他(データベース)
- テーブル設計について
先日明解なアドバイスを頂いたばかりなのですが、もう一つだけ別件で疑問点が出たので質問致します。 簡素なウェブアプリケーションを作成しようとしています。テーブルの設計をしているところなのですが、どのようなテーブル設計にすればよいのか見当がつかないのでアドバイスを頂きたいです。 仮にスタッフというテーブルがあるとします。今のところスタッフテーブルには名前、性別、生年月日というカラムしかありません。このシステム、「シフトスケジュール」という考え方を盛り込みたいです。例えば、２００９年６月１日はAさん、Bさんがスタッフとして勤務し、２日はBさんとCさんが勤務する。。といったようなアルバイトのイメージです。 この場合、「シフト」といった新しいテーブルを作った方がいいような気がするのですが、一体どのようなカラムをどのような型で用意すればいいのかわかりません。どんなシステムにしたいかに依存するとは思いますが、これから作ろうとしているシステムは業務用でなく自己学習用なので最低限必要な簡素なレベルにしたいのです。ざっくりな感じで構わないのでカラム、テーブルのアドバイスを頂けると助かります。ちなみにMySQLを使用する予定です。
- ベストアンサー
- その他(データベース)
- mysqlのデータベース設計(1テーブルで管理)
お世話になります。 現在、会員がログインしてブログ管理できる(記事を作成・編集できるシステム)を考えています。 そこでデータベース設計について質問があります。 一般的には、 ・ユーザー情報に関するテーブル ・ブログ記事に関するテーブル この２つを以下のような感じで設計すると思うのですが↓ ■usersテーブル ・id ・ユーザー名 ・パスワード ■articleテーブル ・id ・user_id(記事投稿者のid) ・contents(ブログタイトル、ブログ本文) ・created ・modified 私は、この２つを１つのテーブルですべてまとめて管理することを考えているのですが、 何かデメリットはあるのでしょうか？↓ ■usersテーブル(このテーブル１つですべてまとめて管理) ・id ・ユーザー名 ・パスワード ・contents(ブログタイトル|ブログ本文|記事投稿日|記事編集日) ・created ・modified ちなみにブログ記事は、区切り文字で分けながらcontentsにどんどん詰め込んでいき(updateする)、 取り出すときは区切り文字をexplodeしていく形を考えています。 実際にはもっと項目が多くなるのですが、１ユーザーの情報をすべて１つのテーブルで管理することで個人的に非常にわかりやすい、さらに単純なのでこちらのほうが速度も速いのではないかと思っているのですが、良くないのでしょうか？（あまり見かけないので） どなたか教えていただけると幸いです。 よろしくお願い致します。
- ベストアンサー
- PHP
- 2パターンのデータベース設計で最適なほうはどちら？
こんにちは。 データベース設計をするにあたり、迷っています。 言語はRuby on rails、DBはMysqlです。 たとえば日記サイトを作るとして (1)テーブル : users , diariesがあって、それぞれのidはuser_diaries というリレーション用のテーブルを作って持たせる (2)テーブル : users , diariesがあって、diaries にuser_id というカラムを持たせる というような作り方ができると思うのですが、どちらが優れていると言えるでしょうか？ 決めの問題でしょうか？ 将来的に大きなサイトになっても大丈夫なようにしておきたいです
- 締切済み
- MySQL
- データベース設計支援ツール
いろんなプロジェクトでデータベースの設計を何度かやっていると、似たようなテーブル名やカラム名。 また、似たような定義になってきます。 テーブル定義書などは、Excelなどで管理しているのですが、ツールか何かで管理したいと思っています。 そうすれば、異なるプロジェクトでも共有できますし、生産性の向上に繋がると思っています。 できれば、似たようなテーブル（部門マスタテーブルなど）は自動で作ってくれるくらいが理想ですが・・・。 そのようなツールってありますでしょうか？
- ベストアンサー
- その他(データベース)
- データベースの設計について
現在PostgreSQL(ver 8.4)を使ってちょっとしたシステムの構築を計画していますが、データベースの設計に関して広くアドバイスを頂きたいです。 ユーザーの入力データをDBで効率よく管理したいと考えています。 例えば、次のようなテーブルを作るとします。 userテーブル id | name ---+------------- 1 | 山田太郎 2 | 高橋次郎 .. | ............. .. | ............. emailテーブル id | address ---+------------------------------ 1 | yamada@mail.com 2 | takahashi@mail.com .. | ................................. .. | ................................. この様な複数のテーブルにユーザーの入力を受け、1対1に対応するIDを振って名前やアドレスなどのデータをリアルタイムで挿入していく場合、どのようなテーブルを用意し、プログラムを組むのが適切なのでしょうか？ 具体的には、PerlでCGIをつくり、ブラウザ上などからユーザーの入力したデータを取得してPostgreSQLに次々挿入していく形にしようとしています。 具体的なPerlのコードを書いていただけると助かるのですが、他の言語のコードでも一向に構いません。 今のところ、自分で考えたものとしては、 create table user( id serial, name text); create table email( id serial, address text); とテーブルを用意し、 Perlコードの概要は use DBI; # *実際にはユーザーの入力値から値を得る $input_user = 'name_hogehoge'; $input_email = 'address_hogehoge@mail.com'; # DBとの接続 $dbh = DBI->connect("dbi:Pg:dbname=hogehoge", ......); # プレースホルダの準備 $sth_user = $dbh->prepare("INSERT INTO user (name) VALUES(?)"); $sth_email = $dbh->prepare("INSERT INTO email (address) VALUES(?)"); # SQLの実行 $sth_user->execute("$input_user"); $sth_email->execute("$input_email"); # コミット $dbh->commit; といった感じで考えていました。しかしidの対応が確実に取れるかなど不安な点がありますので、アドバイスいただけたらと思います。 もちろんこの方法に固執する必要はなく、結果的に同じようなテーブルが得られれば問題ないです。 長々と失礼致しました。
- ベストアンサー
- PostgreSQL
お礼
jjon-com様、とてもクリアなご回答大変有難うございました。よくわかりました。念のため一点だけ確認ですが、ユーザはメンテナンス画面からデータベースに存在するレストラン１つあたり１回まで（０回 or １回）評価出来るようにしたいのですが、この場合、評価テーブルのレストランID、ユーザIDの複合をプライマリキーにすればよいですよね？