テーブル設計について
- ウェブアプリケーションのテーブル設計についてアドバイスを求めます。
- スタッフテーブルにシフトスケジュールを盛り込むための新しいテーブルの作成方法を教えてください。
- 業務用ではなく自己学習用のシステムを作成するため、簡素なテーブル設計を希望しています。
- ベストアンサー
テーブル設計について
先日明解なアドバイスを頂いたばかりなのですが、もう一つだけ別件で疑問点が出たので質問致します。 簡素なウェブアプリケーションを作成しようとしています。テーブルの設計をしているところなのですが、どのようなテーブル設計にすればよいのか見当がつかないのでアドバイスを頂きたいです。 仮にスタッフというテーブルがあるとします。今のところスタッフテーブルには名前、性別、生年月日というカラムしかありません。このシステム、「シフトスケジュール」という考え方を盛り込みたいです。例えば、２００９年６月１日はAさん、Bさんがスタッフとして勤務し、２日はBさんとCさんが勤務する。。といったようなアルバイトのイメージです。 この場合、「シフト」といった新しいテーブルを作った方がいいような気がするのですが、一体どのようなカラムをどのような型で用意すればいいのかわかりません。どんなシステムにしたいかに依存するとは思いますが、これから作ろうとしているシステムは業務用でなく自己学習用なので最低限必要な簡素なレベルにしたいのです。ざっくりな感じで構わないのでカラム、テーブルのアドバイスを頂けると助かります。ちなみにMySQLを使用する予定です。
- rio_grande
- お礼率77% (349/452)
- その他(データベース)
- 回答数1
- ありがとう数1
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
根本的なところですが、基本的にテーブルには「キー」というものがあるとよいです。 たとえば、スタッフテーブルには、「スタッフNO」というカラムというのがあるとよいです。 シフトスケジュールについては、テーブルを、 スケジュール シフト と2つ作ります。 スケジュールテーブルは、 スケジュールNO 年月日 シフトテーブルは、 スケジュールNO スタッフNO となります。
関連するQ&A
- テーブル設計について
簡素なウェブアプリケーションを作成しようとしています。テーブルの設計をしているところなのですが、あまりしっくり来ないのでアドバイスを頂きたいです。 仮にスタッフというテーブルがあるとします。スタッフテーブルには名前、性別、生年月日というカラムがあります。これに階級を付け、その履歴を追えるように変更したいです。つまり、スタッフAさんは1998年にアシスタント、2000年にチームサブリーダー、2005年から現在に至ってチームリーダー。。といったような情報を（必要があれば）クエリで取得できるようにテーブルに変更を加えたいです。 まずは階級名自身が変更、追加になることを考えてランクというテーブルを作成しました。属性は、プライマリキーとランク名です。 イメージ 1 | アシスタント 2 | チームサブリーダー 3 | チームリーダー 4 | ディレクター ... 次に、スタッフテーブルにYEAR1、ランク１、YEAR2、ランク２、YEAR3、ランク３という属性を持たせスタッフテーブルからランクテーブルに参照させようかと考えたのですがこれだと数に限りがあるしなんだかあまり柔軟性がないような気がします。このような場合、階級の変更の回数を気にしなくていいような何らかの新しい別のテーブルを作る方法などありますでしょうか？もしそうだとするとどのような属性を持ったテーブルをつくればよいでしょうか？テーブル設計には色々な方法があるのは承知していますが、もしお薦め出来る（出来れば一般的な）いい方法があればアドバイスお願いします。
- ベストアンサー
- その他(データベース)
- テーブル設計について
会員制の小さなサイトを運営しています。 会員は会員IDで管理しているのですが、テーブル設計が適切であるか判断できず、助言を頂きたく書き込みさせて頂きました。 現在、会員情報テーブル(info)というテーブルが全ての基本となっています。 このテーブルには、会員IDの他、名前や性別、住所、自己紹介文などほとんど全ての会員情報が含まれています。 このほかに会員同士の交流用のテーブル(koryu)がいくつかあり、 そこには、会員IDとその会員が行った内容が記録されています。 で、現状、交流用テーブルを使用する場合、常に会員の名前を会員情報テーブルから引っ張ってきており、これが、処理的に重いのでは無いか、と思っています。 以下はたとえばの例ですが、 select koryu.id, info.name, koryu.contents from info,koryu where koryu.id=info.id のように、毎回、（ほぼ）名前だけを引っ張ってきています。 引っかかっているのは、この「名前だけ」というところで、例えば、会員IDと名前しかないテーブルを作成すれば、もしかしたら、処理が軽くなるのでは・・と思っているのです。 ２０カラムあるテーブルと関連付けを行う場合と、２カラムのテーブルと関連付けを行う場合、 ２カラムのテーブルのほうが、処理は軽くなるのでしょうか？また、軽くなる場合、そうしたほうが良いのでしょうか？ （現在、１０００名くらいしか会員がいないため、処理が重いということは無いのですが、 安いサーバを使用しているため、処理はなるべく軽くしておきたいと思っています。） よろしくお願いします。
- ベストアンサー
- MySQL
- テーブル設計に関して
よろしくお願い致します。 テーブルをはじめて設計することになりましてどのように設計すればいいのかわからず困っております。相談できる人が近くには全くいない状況で、皆様のアドバイスを頂きたいと思い質問させて頂きました。 本題ですが、企画の種類がいくつかあったとします。 まず大きくA企画とB企画があります。 A企画の中でも甲企画と乙企画にわかれます。 B企画はまずイ企画とロ企画にわかれます。そしてイ企画、ロ企画それぞれの中で甲企画と乙企画にわかれます。 このときどのような企画種類を表すテーブルを作るのが一番汎用性があるものとなるのでしょうか？ 自分なりに考えたのは提案の階層ごとに【大分類テーブル】【中分類テーブル】【小分類テーブル】【実際のテーブル種類をもつテーブル】の4つを作るというものですが、これだと3階層で固定になってしまいますのでこれではよくないと思うのですが代わりの案が思いつきません。 アドバイスよろしくお願い致します。
- ベストアンサー
- Oracle
- データベーステーブル設計
簡単なアプリケーションを作ろうとしています。内容は、レストランのデータベースです。画面には、単純にレストラン名、住所、電話番号、営業時間、評価を表示させたいです。この「評価」は、このアプリケーションを使用する３人のユーザが入力する１～５の値の平均値としたいです（ユーザはメンテナンス画面から１レストランにつき１回まで評価値入力可能）。つまりユーザAが４、ユーザBが５、ユーザCが１を入力した場合、4+5+1/3=3.3を表示します。テーブルを設計した経験がないので教えてほしいのですが、この場合、どのようなテーブルを作れば最もシンプルできれいに出来るのでしょうか。まずレストランテーブルを作成する必要があると思いますが、「評価」があるために１テーブルでは不足だと思います。評価カラムの値はユーザが値を入力すれば変動することになるので、別テーブルを参照させるようにすべきなのでしょうか？評価テーブルというものを考えてみましたが、ユーザ名とレストランIDの複合をプライマリキーとし、評価値カラムをもたせるとしても、どこに平均値を持たせればいいのかわかりません。テーブル設計の模範例を教えて頂けると助かります。宜しくお願いします。
- ベストアンサー
- Oracle
- フレンドリストのようなものを作る場合の設計
かなり初心者です。もしかしたら妙な事を訊いているのかもしれません。 php5.4.16とmysql5.5.32でSNSのフレンドリストのような機能を作ろうと思います。 フレンド最大数は1000とします。この場合、1000個もカラムを作るのでしょうか？ それとも、会員個別にテーブルを作ってそこで管理するのでしょうか。 もしくは、テーブルは一つとし、会員番号のカラムを二つ用意、関係性を示したテーブルを作るのでしょうか？ もしくは、カラムは一個で文字列で操作したりするのでしょうか？（カンマで区切る等） パフォーマンス的にどの設計が正しくて、どの設計が間違いなのでしょうか… 回答よろしくお願いします。
- ベストアンサー
- MySQL
- テーブル設計について。
テーブル設計について。 DBから集計して、このような表を出しているのですが、 現在、レコードが10万件ほどあり、集計のクエリが終わるまで7秒近くかかっています。 ※以下、タブ区切りにしてありますので、エディタなどに貼り付けて頂くと見やすいと思います。 【表】 質問グループ 質問タグ 答えOK数 答えNG数 A a 2 1 A b 2 0 B a 1 2 【DB】 テーブル：test id answer group tag 1 OK A a 2 NG A a 3 OK A a 4 OK A b 5 OK A b 6 OK B a 7 NG B a 8 NG B a 【クエリ】 SELECT group, tag, SUM(CASE WHEN answer='ok' THEN 1 ELSE 0 END) AS ok, SUM(CASE WHEN answer='ng' THEN 1 ELSE 0 END) AS ng FROM test GROUP BY group, tag; ※「id」をprimaryキー、「group、tag、answer」をまとめてuniqueとしてインデックスを貼ってます ok数とng数の集計に時間がかかってしまっているのですが、 他に良い方法があれば教えて下さい。 また、そもそものテーブル構成を以下のようにすればいいのでは？ とも思ったのですが、どうなんでしょうか？ この形に変えると、集計は一瞬で終わるはずなのですが、 ok と ngを別カラムにするという考え方がしっくりきません。 テーブル構成の考え方としてどうなのか知りたいです。 下のようにすると、okカラムとngカラムの片方にしか値は入らなくなってしまうので、 それだったら最初の構成のように、answerカラムにokかngのどちらかが入るといった方が好ましいのかなとも思い・・ それと今回はたまたまok と ngの固定２つですが、複数になるような場合もあると思うのです。 テーブル：test id group tag ok ng 1 A a 1 NULL 2 A a NULL 1 3 A a 1 NULL 4 A b 1 NULL 5 A b 1 NULL 6 B a 1 NULL 7 B a NULL 1 8 B a NULL 1 SELECT group, tag, sum(ok), sum(ng) FROM test GROUP BY group, tag; ご教示下さい。
- ベストアンサー
- MySQL
- MySQLでのテーブル設計(SET型)の使用有無について
MySQLのSET関数を使う場合、汎用性はなくなりますが、それ以外の メリット、デメリットが知りたいです。 http://www.itmedia.co.jp/enterprise/0308/24/epn01.html を見たのですが、使用すべきかの判断がつきません（><） 以下のようなシステムを考えています。 ■メールマガジン配信 以下、ユーザーがチェックした材料が含まれる料理が投稿されると 1日1回メール配信されます。 このような場合、テーブルに、SETを持つべきか 項目毎にカラムを持つべきか迷っています。 好きなフルーツ（項目はこちらで指定し５～７種類） ・りんご ・ぶどう ・いちご ・バナナ ・キウイ 好きな食べ物の色（項目はこちらで指定で５色） ・赤 ・黄色 ・緑 ・しろ ・茶色 ■現時点でのテーブル設計 ★ユーザーマスタテーブル PK user_id - その他15ぐらいのカラム ★メール配信テーブル PK user_id - f1 - f2 - f3 - f4 - f5 - c1 - c2 - c3 - c4 - c5 このテーブル設計は正しいでしょうか？
- ベストアンサー
- MySQL
- SELECT／別テーブルのレコード数も取得したい
■環境 ・MySQL ■前提 ・テーブルA … idカラム ・テーブルB … A_idカラム ■やりたいこと ・テーブルAデータを取得する際、テーブルAレコードに応じて、テーブルB「A_idカラム」の数(レコード数)も取得したい ■取得イメージ例 ・テーブルA「全カラム」、「count」カラム ※「count」カラム … テーブルBにある「A_idカラム」の数 ■知りたいこと ・どこにも存在しないこの「count」カラムはどうやって作成したら良いでしょうか？ ・全体のSQL文
- ベストアンサー
- MySQL
- 2パターンのデータベース設計で最適なほうはどちら？
こんにちは。 データベース設計をするにあたり、迷っています。 言語はRuby on rails、DBはMysqlです。 たとえば日記サイトを作るとして (1)テーブル : users , diariesがあって、それぞれのidはuser_diaries というリレーション用のテーブルを作って持たせる (2)テーブル : users , diariesがあって、diaries にuser_id というカラムを持たせる というような作り方ができると思うのですが、どちらが優れていると言えるでしょうか？ 決めの問題でしょうか？ 将来的に大きなサイトになっても大丈夫なようにしておきたいです
- 締切済み
- MySQL
- 複数のテーブルをまとめる方法
宜しくお願い致します。 2種のテーブルをくっつけて検索結果に反映させたいと思っております。しかし、双方でリレーションしているカラムが無いのですが、やはり結合する事は無理でしょうか？ 具体的には・・・ Aテーブル：カラム内容 Aid,title,subtitle,text Bテーブル：カラム内容 Bid,title,subtitle,text ※それぞれのカラム名は同じですが、使用目的が本来全く違う為、どのカラムもリレーションしてません。 このA,Bのテーブルで、本来Aだけを抽出するページがあり、その中に、Bのテーブルからも一部反映させたいのです。Bテーブルに書き込むフォーム上で、例えば『Aテーブルに反映』という様な項目を付けて、そこをチェックしたレコードは、A,B両方のページで同じ内容が見れるといったシステムを作りたいのです。やっぱり無理でしょうか？？
- ベストアンサー
- MySQL
お礼
パターンが分かって来ました。中間的なトランザクションテーブルを作り、マスタテーブルに対してm:1の関係で参照する、といった感じですね。これから作ってみます。有り難うございました。