- 締切済み
［DB設計］多対多の問題点とは
okg00の回答
- okg00
- ベストアンサー率39% (1322/3338)
http://gihyo.jp/dev/feature/01/database/0003 リレーショナルモデルにおいては実装がややこしくなるから。
関連するQ&A
- 1対多の場合のデータベース設計
データベースの設計段階で、１対多となる場合、どういうデータベース設計をすれば良いのか分かりません。 具体的に例として挙げれば、ショッピングサイトがあるとします。 その中で、１つの商品があります。 １つの商品には１つの名前、１つの価格など、１対１のものがありますが、中には購入履歴など、１対１ではなく、１対多のものがあります。 この場合、その気になれば１００でも１０００でも増えていきます。こういった、項目の数が具体的に決まっていない場合、どういうデータベースの列を作成すれば良いのでしょうか？ 多くても大丈夫なように、購入履歴１という列から購入履歴１０００という列まで１０００列用意するしかないのでしょうか？
- 締切済み
- MySQL
- アクセスでリレーションシップの一対多で参照整合性で
アクセスでリレーションシップの一対多で参照整合性で組める条件を教えてください。 例えば、 ・数値型とテキスト型のフィールドでは繋げられない。とか ・主キー同士でないとダメ。とか ・重複するデータが入っているレコードがある場合はダメ とか・・・ どういう条件がOKでどういう条件がダメなのかよくわからなくて混乱しています。 自分で試していますが、うまくいったりできなかったりです。
- ベストアンサー
- オフィス系ソフト
- WEBシステムのDB設計について
趣味でWEBによるグループウェアを作ろうと思ってます。 DB設計について質問です。 プロの方が作るシステムでは 通常、ユーザーを識別する主キーは「ログインID」でしょうか？ 「ログインID」は認証用のみ使用して、識別キーは別に作ったほうが良いのでしょうか？ ※ログインIDは1度設定したら変更不可にしようと思ってます。 プロの方が作るWEBシステムの、認証・ユーザーマスター部分の DB設計の定石などありましたら教えてください。 ２パターン考えました。 ＜パターン１＞ ■認証テーブル １．ログインID（主キー）※認証のみ使用 ２．ログインパスワード ３．ユーザーID（外部キー）※ユーザー情報、その他の識別主キー システム自動で設定 ■ユーザーマスター １．ユーザーID（主キー） ２．名前 ３．メールアドレス ４．グループID ５．その他情報 ： ６．更新日時 ７．更新者 ■グループマスター １．グループID（主キー） ２．グループ名 ３．ユーザーID（外部キー） ： ＜パターン２＞ ■認証テーブルなし ■ユーザーマスター １．ログインID（主キー）※ユーザー識別キー ２．ログインパスワード ３．名前 ４．メールアドレス ： ７．更新者 ■グループマスター １．グループID（主キー） ２．グループ名 ３．ログインID（外部キー） ： ご指導いただけたら嬉しいです。
- ベストアンサー
- その他(データベース)
- DBにの主キーで空いている番号を見つける方法
こんにちわ。 DBに、顧客コードというユニークな番号が設定されています。ここでもし、新規作成をする場合、Insert文を発行するのですが、主キーとしてInsertする番号を知ることができません。 DBからどうやってこの情報を得ればよいのでしょうか？自動付番してくれるものなのでしょうか？
- ベストアンサー
- Visual Basic
- 【MySQL】１対１でテーブルをあえて分ける
mysqlを使用してデータベースを作成しているのですが データベースでテーブルを分けるときって 【アカウントテーブル】 ID アカウント 名 アカウント パスワード 名前 住所 電話番号 職業 【職業テーブル】 職業ID 職業名 というような１対多というのはよく組むとおもうんですが 下記のような 【アカウント情報テーブル（アカウント情報）】 アカウントID アカウント 名 アカウント パスワード 【アカウント情報テーブル（プロフィール情報）】 アカウントID 名前 住所 電話番号 職業 １対１の関係でテーブルをジャンル（エンティティ）ごとに複数にわけて あとでリレーションして一個にまとめるというのはデータベース的にあまりよろしくないのでしょうか？ 何故、こんなことしたいかというと、１テーブルあたりのカラム数がかなり多くなってくると PHPでデータベースを書き込んだり呼び出したりする時に毎度多くのカラムを取り扱わなければならず SELECTで、カラムを一個一個選んで行かないといけません。 しかし、取り扱いたいカラムは大抵の場合あるジャンルだけなので リレーションするかしないかで、あるジャンルのデータだけを取り扱えれば 効率がよくなるのでは？ というのがあります。 また、視覚的にカラムの把握もしやすくなります。 この１対１テーブルは、DB設計的にどうなでしょうか？
- ベストアンサー
- MySQL
- DB設計に要する見積もりについて
新規のシステムで、全体の見積もりを行う中で、DBだけに注目して容量の算出、テーブル作成、正規化等プログラミングする前にいろいろやる事があると思いますが、その部分だけの作成にはどのような情報があれば、工数を算出できるのでしょうか？ 勿論、テーブルの数や名前、その中の項目数や項目名、収まるデータ量なんか はDB作成以前の設計段階での工数見積もりに入ってくると思うので、ここでは DB見積もりから除外して考えております。 宜しくお願い致します。
- ベストアンサー
- その他(データベース)
- カンマ区切りで格納するカラムって設計上ありでしょうか？
例えば、1,2,5,8,9,10 というような形でデータを格納するカラムをテーブルに作ろうと思っているのですが設計上ありでしょうか？ 格納したあとは、それSELECTのIN(1,2,5,8,9,10)で 使用するのが主で、更新時のキーが別にあればOKという感じでしょうか？ こういう場合に、このような設計をした事があるよ。いった例など教えていただけると幸いです。
- ベストアンサー
- その他(データベース)
- SQL文の結合（一対多）がわからない
色々とネットで調べてみたのですが、ピンとこないので質問させていただいています。 以下のようなテーブルを想定しています。 「テーブルA」 ユニークキー データ１ データ２ ・・・ 0001 ... 0002 ... 0003 ... 「テーブルB」 キー データA データB ・・・ 0001 ... 0001 ... 0002 ... テーブルAではユニークキーは重複していないのですが、テーブルBのキーは重複しています。 このような状況で、テーブルBの”キー”とテーブルAの”ユニークキー”を照合させて、テーブルBに”データ１ データ２ ・・・”を流し込みたいと思っています。 現状では、複数の検索結果が出るためにエラーとなっています。「一対多」結合を利用するというところまではわかったのですが、そこから先がよくわかりません。 どなたか解説していただけないでしょうか。 初心者の質問で恐縮ですが、お教え頂ければ嬉しいです。
- ベストアンサー
- その他(データベース)
- access １対１と１対多のテーブルをクエリで集計したい…
受注管理のデータベースを作っています。 売り上げを計算するクエリを作ったのですがどうもうまくいかないので質問します。 集計したいテーブルですが 受注マスタテーブル 注文番号（主キー テキスト型） 注文日（日付型） 氏名 ： ： 受注明細マスタテーブル 注文番号 （重複あり）受注マスタの注文番号と１対多のリレーションシップ 商品名 品番 販売単価 購入個数 経費・返品金額テーブル 注文番号（主キー）受注マスタの注文番号と１対１のリレーションシップ 経費 返品金額 これを、販売単価×購入個数-経費＋返品金額というようにして１ヵ月ごとに集計しようとして、下のようなクエリを作ったのですが経費が何回も計算されてうまくいきませんでした… よろしくお願いします。 SELECT Format(注文者マスタ!注文日,"yyyy/mm") AS 月, Sum([受注明細マスタ]![販売単価]*[受注明細マスタ]![購入数量]-[経費・返品金額テーブル]![経費]+[経費・返品金額テーブル]![返品金額]) AS 売上 FROM (注文者マスタ RIGHT JOIN 経費・返品金額テーブル ON 注文者マスタ.注文番号 = 経費・返品金額テーブル.注文番号) LEFT JOIN 受注明細マスタ ON 注文者マスタ.注文番号 = 受注明細マスタ.注文番号 GROUP BY Format(注文者マスタ!注文日,"yyyy/mm");
- ベストアンサー
- オフィス系ソフト
- Accessでの設計
次のようなデータの設計に困っています。 前回他の方に答えていただいたのですが、問題が生じたので再度投稿させていただきます。 例）受験者名簿テーブル 受験者番号 主キー 受験者氏名 受験者かな 郵便番号 住所 電話番号 例）申込者テーブル 申込者番号（主キー） 受験者番号 受験者との続柄 申込者氏名 申込者かな 郵便番号 住所 電話番号 上記のテーブルが２つあります。また、受験者と申込者テーブルの受験者番号はリレーションを設定してます。 まず、受験者との続柄が「本人」の場合、申込者名前や住所、その他の項目は全て、受験者テーブルのデータを元に入力できるようにしたいです。また、受験者との続柄が「本人」ではないときには、氏名などを直接入力できるようにしたいです。 その際、申込者に「主キー」は必要かどうか。 また、他にテーブルを作成する必要があるのか。など初心者にわかりやすいように教えていただきたいです。クエリで、試してみましたが「本人」以外のデータを入力できなくなってしまいました。 どなたか回答願います。
- 締切済み
- その他(ソフトウェア)
お礼
早速の回答ありがとうございます。 実装がややこしくなるというのはよく聞くのですが、 なぜややこしくなるのかが知りたいです。