- ベストアンサー
データベースの設計で質問です。
会社テーブルがあり、会社がサービス可能な都道府県情報を保存したい場合には、 どのように作るのがいいのでしょうか？ 会社テーブルに都道府県別に47個のカラムを追加する 会社テーブル id | name | pref_1 | pref_2 | pref_3 | .... | pref_47 --------------------------------------- 1 | 会社A | 1 | 0 | 1 | .... | 0 2 | 会社B | 0 | 0 | 1 | .... | 1 という感じかなと思ったのですが、カラム数が多くなってしまい、なんとなく冗長な感じがしてしまいます。
- overdist
- お礼率40% (4/10)
- その他(データベース)
- 回答数4
- ありがとう数3
- みんなの回答 （4）
- 専門家の回答
関連するQ&A
- データーベース設計段階での質問です。
データーベース設計段階での質問です。 管理しなければならないフラグ項目が100近くあり、そのフラグがよく検索対象になります。ただし、1レコードにつけられるフラグは10個までと決まっています。現在使用中のデータベースでは10個のカラムをつくっていて、そこに対象フラグのIDを列挙しています。 例えば A項目に対して1,20,34,56,78 B項目に対して3,6,11,15,42,78,89 のフラグがたっている場合、 name f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 ------------------------------------------------------ A 1 20 34 56 78 null null null null null B 3 6 11 15 42 78 89 null null null となっています。他に日付などのカラムが5項目ほどあります。 このままだと検索等でややこしいことになるため テーブルを整理したいと思っています。 1.100個のboolean型のカラムを作る 2.ビットフラグ（ビットフィールド）のカラムを４つほど作って、検索時ビット演算する 3.項目名(ID)とフラグNo、だけの2カラムで構成した別テーブルを作ってjoinする 4.文字列としてIDを格納し、フルテキストインデックスをはる などがあると思うのですが、効率のいい設計がいまいちよくわかっていません。 上記の方法以外にも何かいい方法があると思います。 このような場合の、テーブル設計の方法を教えて下さい。
- ベストアンサー
- その他(データベース)
- データベースのマスタ設計についての質問
現在データベースの設計を勉強しています。 マスタの設計について疑問があって質問しました。 【1】すべてのマスタデータを統合したテーブルを作成 カラム１：カテゴリID(PK) カラム2：カテゴリCD(PK) カラム3：値 【2】それぞれのカテゴリに応じたテーブルを作成 カラム1：カテゴリCD(PK) カラム2：値 ※私はパターン１の方が、カテゴリの追加等柔軟かなと考えています。 それぞれのパターンの長所・短所を教えてください。
- ベストアンサー
- その他(データベース)
- Index の使い方、where a.カラム1 LIKE CONCAT
Index の使い方、where a.カラム1 LIKE CONCAT(b.カラム2,'%') お世話になります。 テーブルA： id phone ----------------------------------- 1 819011112222 2 819022223333 3 81312345678 4 651112222 5 8699998888 6 819011112222 テーブルB： id Name Pref --------------------------------------------------- 1 Japan-1 8131234 2 JP-Mobile 8190 3 China-1 869 4 China-2 868 5 Japan-2 813 6 Japan 81 7 Singapore 65 このようなテーブルで、テーブルBはレコード数が数千件あります。 数千件でしたし、データを取るのに遅いとは思いますが、 なんとか耐えらえた範囲なので下記のように実行しておりました。 select a.*,b.Name,b.Pref FROM テーブルA a, テーブルB b where a.phone LIKE CONCAT(Pref,'%') group by a.id; 結果 id phone Name ---------------------------------------------------- 1 819011112222 JP-Mobile 2 819022223333 JP-Mobile 3 81312345678 Japan-2 4 651112222 Singapore 5 8699998888 China-1 5 862223333 China-2 6 819011112222 JP-Mobile テーブルB Prefに対してIndexを作成していますが、どうも作動していないようです。 Indexに関してよく理解できていなかったので、気にしていなかったのですが、今回早さを比べる為に Indexあり、なしで試しみても大して変っていませんでした。 今のところ、Indexを使えていなくても問題ないのですが、今後テーブルBのデータが数万件に増えてしまい、今までのやり方が通用しません。 効果的に使用する方法をアドバイス頂けませんでしょうか。 よろしくお願いします。
- 締切済み
- MySQL
- SQL ServerのINNER JOINについて
SQL Server 2008 R2のINNER JOINについて質問させて下さい。 ------------------------------ SELECT * FROM [Customer] INNER JOIN Pref ON Customer.CustomerPref1 = Pref.PrefId ON Customer.CustomerPref2 = Pref.PrefId ON Customer.CustomerPref3 = Pref.PrefId WHERE ([CustomerId] = 123) ------------------------------ 3つもONがあって変なSQL文となっております。 (当然SQLエラーとなります。) やりたい事は、 顧客フォーム[Customer]の中に、都道府県をプルダウン選択する項目が3つあります。 3つとも都道府県マスタテーブルをリレーション(FK)しております。 3つの都道府県項目で「都道府県名」をそれぞれSELECTするには、 どうしたらよいでしょうか? ご教授頂けますようお願い申し上げます。 ------------------ ▼DB情報 顧客情報テーブル：Customer 顧客ID：CustomerId 都道府県カラム1：CustomerPref1(1,2,3,～などの値が格納) 都道府県カラム2：CustomerPref2(1,2,3,～などの値が格納) 都道府県カラム3：CustomerPref3(1,2,3,～などの値が格納) 都道府県マスタテーブル：Pref 都道府県ID：PrefId(1, 2, 3,～などの値が格納) 都道府県名：PrefName(1:北海道, 2:青森県, 3:岩手県～などの値が格納)
- ベストアンサー
- SQL Server
- データベーステーブル設計
簡単なアプリケーションを作ろうとしています。内容は、レストランのデータベースです。画面には、単純にレストラン名、住所、電話番号、営業時間、評価を表示させたいです。この「評価」は、このアプリケーションを使用する３人のユーザが入力する１～５の値の平均値としたいです（ユーザはメンテナンス画面から１レストランにつき１回まで評価値入力可能）。つまりユーザAが４、ユーザBが５、ユーザCが１を入力した場合、4+5+1/3=3.3を表示します。テーブルを設計した経験がないので教えてほしいのですが、この場合、どのようなテーブルを作れば最もシンプルできれいに出来るのでしょうか。まずレストランテーブルを作成する必要があると思いますが、「評価」があるために１テーブルでは不足だと思います。評価カラムの値はユーザが値を入力すれば変動することになるので、別テーブルを参照させるようにすべきなのでしょうか？評価テーブルというものを考えてみましたが、ユーザ名とレストランIDの複合をプライマリキーとし、評価値カラムをもたせるとしても、どこに平均値を持たせればいいのかわかりません。テーブル設計の模範例を教えて頂けると助かります。宜しくお願いします。
- ベストアンサー
- Oracle
- テーブル設計について
二つのテーブルの行数は同じとします 1行に10カラム以上あるテーブルから1カラムだけ取得するのと idとvoteだけの2カラムで作ったテーブルから1カラムだけ取得する場合の処理スピードは速くなりますか? updateで更新する時のスピードもカラム数が多いと違いが出ますか？ よろしくお願いします sprintf("SELECT vote FROM hoge WHERE id=%d", $id );
- ベストアンサー
- MySQL
- データベースの設計について
現在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
- データベースの設計について教えてください。
データベースの設計について教えてください。 基本的な質問ですみません。宜しくお願いいたします。 単純なテーブルで表現しますが、 パターンA、Bのどちらのテーブルで設計するのが良いのでしょうか。 DBはmysqlで5000万件のデータで検索のみのデータベースです。 【前提】 ユーザは複数のメールアドレスを持ちます。 画面から、このユーザのもつメールアドレスを表示させる仕様だとします。 【userマスタ】 (PK)ユーザID ユーザ名 会社名 ＜パターンA＞ 【mailテーブル】 (PK)ユーザID (PK)ユーザメールアドレス モバイル用アドレス ＜パターンB＞ 【mailテーブル】 (PK)ユーザメールアドレス モバイル用アドレス ユーザID ←インデックスをはります。
- ベストアンサー
- MySQL
- テーブル設計について
会員制の小さなサイトを運営しています。 会員は会員IDで管理しているのですが、テーブル設計が適切であるか判断できず、助言を頂きたく書き込みさせて頂きました。 現在、会員情報テーブル(info)というテーブルが全ての基本となっています。 このテーブルには、会員IDの他、名前や性別、住所、自己紹介文などほとんど全ての会員情報が含まれています。 このほかに会員同士の交流用のテーブル(koryu)がいくつかあり、 そこには、会員IDとその会員が行った内容が記録されています。 で、現状、交流用テーブルを使用する場合、常に会員の名前を会員情報テーブルから引っ張ってきており、これが、処理的に重いのでは無いか、と思っています。 以下はたとえばの例ですが、 select koryu.id, info.name, koryu.contents from info,koryu where koryu.id=info.id のように、毎回、（ほぼ）名前だけを引っ張ってきています。 引っかかっているのは、この「名前だけ」というところで、例えば、会員IDと名前しかないテーブルを作成すれば、もしかしたら、処理が軽くなるのでは・・と思っているのです。 ２０カラムあるテーブルと関連付けを行う場合と、２カラムのテーブルと関連付けを行う場合、 ２カラムのテーブルのほうが、処理は軽くなるのでしょうか？また、軽くなる場合、そうしたほうが良いのでしょうか？ （現在、１０００名くらいしか会員がいないため、処理が重いということは無いのですが、 安いサーバを使用しているため、処理はなるべく軽くしておきたいと思っています。） よろしくお願いします。
- ベストアンサー
- MySQL
- データベース ー どういうテーブル構造にしますか？
管理者テーブル table admin admin int, adm_name text 商品テーブル table items item_id int, item_name text, item_price int と２つのデータテーブルがあった場合に 、誰がいつどんな変更をしたかを記録を取りたい場合、あなたならどういうふうに作りますか？ itemsテーブルにカラムを増やしますか？ 別テーブルでログ用のテーブルを増やしますか？
- 締切済み
- その他(データベース)
お礼
みなさま、回答ありがとうございました。 大変参考になりました。 今回の場合は、分けたほうが汎用性がありそうです。