- ベストアンサー
ウェブアプリケーションでのテーブルの分け方について
現在、railsを勉強しています。 複数のユーザーが各々のタスクを管理するアプリを作成する初心者用チュートリアルで、すべてのユーザーでひとつのタスクテーブルを用意しユーザーＩＤで各タスクを各ユーザーに紐付けているものがありました。 規模等にもよると思いますが、『すべてのユーザーでひとつのタスクテーブルを用意する方法』と『各ユーザーごとにタスクテーブルを用意する方法』のどちらがより一般的でしょうか？ また、後者の場合、ユーザー登録時に動的にモデルとテーブルを作成することになると思いますがそもそもそのようなことは可能なのでしょうか？ よろしくお願いします。
- spring_man
- お礼率94% (18/19)
- Ruby
- 回答数1
- ありがとう数2
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
規模関係なしにテーブルは１つじゃないかな。 同じ項目のテーブルは複数持たない設計が一般的だと思うよ。 いちいちモデル、エンティティなんかを複数作るなんて非効率だし、データを取得するロジックだって無駄が多くなる。 技術的には自動的に作れるけど
関連するQ&A
- [CakePHP]複数テーブルのアソシエーション
CakePHPについて質問です（Ver.2.2)複数テーブルのアソシエーションについてなのですが、下記のようなアソシエーションは可能でしょうか？ [使用テーブル] Post、Recommend、UserMaster、UserDetail [結合キー] (1)Post.id = Recommend.post_id (2)User.id = Post.user_id (3)User.id = UserDetail.user_id つまり、Post.php内にてPost以外で紐づいているテーブル同士を結合が可能かどうかを知りたいです。（(1)(2)はPostテーブルと紐づいているが、(3)はPostテーブル以外同士で紐づいている） 下記方法にて(1)(2)は実現できたのですが、(3)の方法が見つかりませんでした。 -- class Post extends AppModel { $belongsTo = array('User'); $hasOne = array('Recommend'); （略） -- 不明点あればご説明します。どうぞよろしくお願いします。
- ベストアンサー
- PHP
- デーブルのリンクについて
select文で２つのテーブルをリンクし表示したいのですが，うまくできません． 具体的には， 「ユーザテーブル」 ・ＩＤ ・名前 「タスクテーブル」 ・タスクＩＤ ・タスク名 ・ユーザＩＤ１ ・ユーザＩＤ２ ・ユーザＩＤ３ という二つのテーブル構成になっています． タスクテーブルのユーザＩＤ１～３は，ユーザテーブル のＩＤとリンクしています． この状況で，タスクテーブルのユーザＩＤ１～３を ユーザテーブルのＩＤとリンクさせ，名前を表示する クエリを作成したいのです． 「タスクテーブルクエリ」 ・タスクＩＤ ・タスク名 ・ユーザ名前１（ユーザテーブルのＩＤとリンク） ・ユーザ名前２（ユーザテーブルのＩＤとリンク） ・ユーザ名前３（ユーザテーブルのＩＤとリンク） このようにするにはどうすればよいでしょうか？ すみませんが，教えて下さい．
- ベストアンサー
- MySQL
- 二つのテーブルの結合
はじめまして。 複数のテーブルの扱いでいきずまっております。 taskには案件のデータが入ってます。 task_userにはそれに携わるユーザー名(一人でない)が入っています。 titleでソートして出力したい場合、どうしたらいいのでしょうか？ 現状のままでは、task_userのnumでソートしています。 $sql = "select * from task_user where user_id ='3' order by num desc; $result = mysql_query($sql); while ($row = mysql_fetch_object($result)) { $task_id = $row->task_id; $sql_task = "select * from task where num ='" . $task_id . "'"; $result_task = mysql_query($sql_task); $row_task = mysql_fetch_object($result_task); $title = $row_task->title; } mySQL4.0を使っています。 できればバージョンをあげずに解決したいと思っています。 ご教授いただければ幸いです。
- 締切済み
- MySQL
- 2テーブルが同じユーザテーブル参照するときの結合
2つのテーブルで、同じユーザテーブルを参照してデータ取得したいのですが、 どうやって結合すれば良いのでしょうか？ ■概要 ・ユーザがアクションに挑戦すると、結果を表示 ・その際、「アクション作成者」と「アクション挑戦者(ユーザ)」を表示したい ※「作成者」「挑戦者」は、同じ「user」テーブルで管理したい ■3テーブル ・「result」「action」「user」 ・「result」「action」テーブルには、それぞれ「user_id」カラムがある ・「result」テーブルには、「action_id」カラムがある。1対多？ ■知りたいこと ・一気にまとめて一覧として取得する方法 ・最終的に「結果」と、「result」「action」それぞれに対応した「user」テーブルの「name」カラムを取得したい ■試してみたこと ・これだと「挑戦者名」が取得できない SELECT * FROM result r LEFT JOIN `action` a ON r.`action_id` = a.`id` LEFT JOIN `user` u ON r.`user_id` = u.`id` ・これだと「挑戦者」のユーザIDしか取得できない SELECT *,a.user_id AS actionuser_id FROM result r LEFT JOIN `action` a ON r.`action_id` = a.`id` LEFT JOIN `user` u ON a.`user_id` = u.`id`
- ベストアンサー
- MySQL
- こちらのテーブルにあってこちらのテーブルにないIDを抽出するSQL
お世話になってます MySQLでデータを格納しております。 以下のようにUserTable,Userinfoという2つのテーブルがあったとします。 ■UserTable -ID(key) -username ■Userinfo -ID(key) -user_info1 -user_info2 UserTableはユーザID作成時に自動でレコードが生成されます。 登録されたユーザは自分の情報を自分自身で登録することにより Userinfoテーブルにレコードが生成されます。 ここで、ユーザIDを作成したユーザのうち、自分の情報を登録していない ユーザIDを抽出したいのですが、この場合、どのようなSQLを書けばよいのでしょうか・・・？ ユーザIDが、UserTableにあって、UserInfoにない、というものを作ればよいのですが・・・ SQLだけじゃ無理でしょうか・・・？
- ベストアンサー
- MySQL
- 会員が作成したデータを格納するテーブルのプライマリキーについて
例えば、写真サイトで各ユーザーが任意に アルバムを複数作成できるようにする場合、 アルバムテーブルのプライマリキーは、 以下３つのどれが好ましいでしょうか？ （案１） PK アルバムID（DBの自動採番） Key ユーザーID （案２） PK ユーザーID PK アルバムID（同じユーザーIDの最大アルバムID+1で採番する） （案３） PK アルバムID（同じユーザーIDの最大アルバムID+1で採番する） PK ユーザーID 以下がわからず判断できません（; ;） ・アルバムに限らず会員が作成したデータを格納するテーブル全てにユーザIDが必要になると思いますが、 テーブル固有のキーとユーザIDを複合プライマリーキー（PK）とするのと、 テーブル固有のキーを単一プライマリーキーとするのでは どちらが良いのでしょうか？ ・案２，３で複合キーとした場合、 ユーザーIDをテーブルの一番上の項目にするのと、 テーブル固有のキー項目となりえた項目のどちらを テーブルの一番上にするのが良いのでしょうか？
- ベストアンサー
- MySQL
- mysqlのデータベース設計(1テーブルで管理)
お世話になります。 現在、会員がログインしてブログ管理できる(記事を作成・編集できるシステム)を考えています。 そこでデータベース設計について質問があります。 一般的には、 ・ユーザー情報に関するテーブル ・ブログ記事に関するテーブル この２つを以下のような感じで設計すると思うのですが↓ ■usersテーブル ・id ・ユーザー名 ・パスワード ■articleテーブル ・id ・user_id(記事投稿者のid) ・contents(ブログタイトル、ブログ本文) ・created ・modified 私は、この２つを１つのテーブルですべてまとめて管理することを考えているのですが、 何かデメリットはあるのでしょうか？↓ ■usersテーブル(このテーブル１つですべてまとめて管理) ・id ・ユーザー名 ・パスワード ・contents(ブログタイトル|ブログ本文|記事投稿日|記事編集日) ・created ・modified ちなみにブログ記事は、区切り文字で分けながらcontentsにどんどん詰め込んでいき(updateする)、 取り出すときは区切り文字をexplodeしていく形を考えています。 実際にはもっと項目が多くなるのですが、１ユーザーの情報をすべて１つのテーブルで管理することで個人的に非常にわかりやすい、さらに単純なのでこちらのほうが速度も速いのではないかと思っているのですが、良くないのでしょうか？（あまり見かけないので） どなたか教えていただけると幸いです。 よろしくお願い致します。
- ベストアンサー
- PHP
- テーブルの設計についてアドバイスください
MySQL5を使用しています。 あるプレゼントコンテンツを作ろうとしているのですが、1箇所、懸念点がありなにかいい方法がないかアドバイス頂ければと思います。 presets（プレゼントテーブル） ------------- id users（会員テーブル） ------------- id tickets（応募可能テーブル） ------------- id present_id user_id left_ticket（応募可能数） logs（応募履歴テーブル） ------------- id present_id user_id is_prize（当選したかどうか） 仕様 ・各プレゼントへの応募可能数は、ユーザ／プレゼントによって違う（=left_ticket） プレゼントを新規登録する際に、ticketsテーブルに全ユーザ分のレコードを登録しなくてはならず、数十人程度なら良いんですが、数百人～数千人となると非現実的かなと思っています。 なにか良い方法はありますでしょうか？
- ベストアンサー
- MySQL
- Mysql（5.1）を利用してWebアプリケーションを作成しているので
Mysql（5.1）を利用してWebアプリケーションを作成しているのですが、ユーザマスタのテーブルを作成する時に、カラム ユーザIDにAUTO_INCREMENTにした場合、他のカラム 登録者ユーザID ENTRY_USER_ID、更新ユーザID UPDATE_USER_IDにもAUTO_INCREMENTを指定したいのですがエラーになってCREATEできません。 エラーが表示されます。 ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key ぐぐって見たのですが、プライマリーキーなどといっしょに指定するみたいなのですが、SQL文は、create table USER_MST ( USER_ID INTEGER(10) AUTO_INCREMENT, NICKNAME VARCHAR(12) NOT NULL, ENTRY_USER_ID INTEGER(10) AUTO_INCREMENT, UPDATE_USER_ID INTEGER(10) AUTO_INCREMENT, ENTRY_YMD TIMESTAMP NOT NULL, UPDATE_YMD TIMESTAMP NOT NULL, DELETE_YMD TIMESTAMP NULL, PRIMARY KEY ( USER_ID ,ENTRY_USER_ID,UPDATE_USER_ID) )ENGINE=InnoDB CHARACTER SET UTF8; を実行しているのですが、うまくいきません。 ご教授お願いします
- 締切済み
- MySQL
- MYSQL テーブル作成
はじめまして。 MYSQLのテーブル作成について質問があります。 今WEBサイトからユーザにレシピを入力してもらうシステムを作っているのですが、『必要な材料』のような数がユーザの入力に依存するような場合どのようにしてテーブルを作成するべきなのでしょうか？ 考えたのは １）そのrecipeというテーブルを作って一つのcolomnに『ingredient』をつくってその中にすべてまとめて入力 ２）recipeの他にingredientsというテーブルを作りその中でrecipe_idなどでレシピを表示するときに一緒に引き出せるようにする。 レシピの数が増えたり、材料の数が増えた場合、どちらのほうが結果的によいのでしょうか？ よろしくお願いします。
- 締切済み
- MySQL
お礼
御礼が遅くなり申し訳ありません。 なるほどそういうものなのですね。 初心者用チュートリアルだったので、わかりやすく簡略化しているのかと思いました。 ありがとうございました。