- ベストアンサー
データベースのテーブル設計について
データベースのテーブル設計で、数項目のみのデータをひとつのテーブルにしていますでしょうか？ すべてデータベース内で管理するという一貫性はあると思うのですが、たかだか数項目なのでどうかなとも思ってしまいます。 かといって、数項目のみのデータをプログラム内（たとえば構造体）で管理するというのも、管理が必要な要素が散らばるし、再コンパイルも必要になってきます。 このあたりどのようにすればよいのかなといつも判断に悩んでいます。 みなさんはどのように判断、設計していますでしょうか？ご意見お教えください。
- ii_oniku
- お礼率15% (9/59)
- その他(データベース)
- 回答数4
- ありがとう数0
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
関連するQ&A
- データベースで変更の多いテーブルの設計
データベースを設計しています。 あるテーブルに関して、項目（列）が50個くらいあるのですが、これらのうち20個くらいの列が頻繁に変更があり、データの履歴が必要になるため、テーブルを再設計しようと考えています。 現在は変更があるたびにテーブル全体を別テーブルにコピーして、寄せています。 このような場合、何かよい設計方法はあるでしょうか？
- ベストアンサー
- その他(データベース)
- データベースの設計方法について
全くの初心者で、いろいろな書籍を参考に販売・在庫管理データベースをつくりたいと勉強しています。 環境はMicrosoft SQL Server 2008 R2 EE をサーバーにインストールして、別のクライアントパソコンから SQL Server Management Studio でデータを作成しています。 データベースとは閉じた空間で、１つのデータベース内で必要なテーブルを全て用意するものと思っていました(参考にした書籍もそうなっていました)。 しかし、ネットでいろいろ調べるとインスタンス内に複数のデータベースを作成し、それらデータベース内のテーブルは相互接続可能出来るみたいでした。 となると、データベースを設計する際 ＜販売管理データベース＞ ・顧客情報テーブル ・商品情報テーブル ・在庫テーブル ・単価テーブル ・請求データテーブル ・伝票テーブル ・etc. と１つのデータベースに全てのテーブルを用意する設計では無く ＜販売管理データベース＞ ・伝票テーブル ・請求データ ・etc. ＜顧客情報データベース＞ ・顧客情報テーブル ・単価テーブル ・etc. ＜商品情報データベース＞ ・商品情報テーブル ・在庫テーブル ・etc. みたいに、機能ごとにデータベースを分けて、インスタンス単位で１機能(もしくは複数機能の実装)の設計でも良いのでしょうか？ プログラム言語の、プロジェクト＝インスタンス、クラス＝データベースみたいな考え方が出来ればと思っています。 この方法が正しいのか誤りなのか、そもそも理解に誤りがあるのか全く見当が付きません。 一般的にはどのようにするものなのでしょうか？
- ベストアンサー
- SQL Server
- データベースのフィールドそのものを自由に定義できるテーブル設計とは
はじめまして。 この度、ユーザからの入力をデータベースに保存する複数アンケートフォームを作成しようとしています。 その際、各アンケートフォームごとに入力項目名、入力タイプ好きな数だけ管理側から設定できる仕様です。 このような通常フィールド（列）となる部分の名称やデータタイプを自由に設定できるデータベース設計がうまくいきません。現場ではどのようにしてやられてるのでしょうか？ 私が思いつく限りでは ---------------------- アンケートフォームテーブル ・アンケートフォーム番号（PK） ・アンケート名称 ---------------------- 項目雛型テーブル ・項目番号（PK） ・データタイプ ---------------------- 項目実体 ・アンケートフォーム番号（PK） ・項目番号（PK） ・項目名称 ・表示状態 ---------------------- 上記のような構造にした場合、ユーザ毎のアンケートデータを保存するテーブル構造が思いつきません。 作成できる項目数の限度を３０に決めて、予め３０フィールド、テキスト型のようなものを用意しておくのも狭い利用範囲になる気がしますが・・・ アドバイスをお願いします。
- ベストアンサー
- その他(データベース)
- データベースの設計について
朝からデータベースの設計について悩んでいます。 テーブルにしたいデータがあるのですが、 それぞれカテゴリーが違うデータがあります。 構造的には少ししか違わないのですが、 これらのデータを1つのテーブルとしてまとめるか、 それとも、それぞれ1つずつのテーブルにするか迷っています。 迷っている理由として： ・同時にアクセスがあった場合、全て一つのテーブルにまとめていると、障害がないか？ ・全てを1つのテーブルにすると、多少は構造が違うので、必要のないフィールドが出てしまう。 それぞれを1つのテーブルで分割するということも考えたのですが、 例えば、全てのデータからある特定のデータの検索をかける場合に 不都合なのではないか？と考えてしまいます。 こういう場合には： select * from table_A where field="検索したいデータ"; select * from table_B where field="検索したいデータ"; select * from table_C where field="検索したいデータ"; とテーブルの分だけSQLを実行するしかないのでしょうか？ どちらを選択しても、それぞれ一長一短のようで、混乱しています。 よろしくお願いします。
- ベストアンサー
- MySQL
- データベース、テーブル設計についてです。
現在、ブランドサイズをインターナショナルサイズに変換するデータベース設計をしていて悩んでいることがあります。どうか知恵をお貸しください。 参考にしています書籍は、ミック著「達人に学ぶDB設計徹底指南書」です。 書籍には、正規化の次数が低いほど検索SQLのパフォーマンスは良いですが、データ整合性は低く、正規化していくほどパフォーマンスが低下する代わりにデータ整合性が高くなります。と書いています。 ですので、正規化した結果、５つのテーブルが出来上がりました。 これらを正規化したテーブルを中間テーブルで扱うには、どのように設計すればよろしいでしょうか？ 以上、よろしくお願いします。 下記は、正規化したテーブルです。 テーブル名 ：： ブランド 扱うデータ ：： （仮）A、その他ブランド.... テーブル名 ：： 性別 扱うデータ ：： メンズ、レディース、ユニセックス テーブル名 ：： カテゴリー 扱うデータ ：： ウェアー、ボトム、シューズ、その他カテゴリー.... テーブル名 ：： ブランドサイズ 扱うデータ ：： 1、2、3、その他ブランドサイズ.... テーブル名 ：： インターナショナル・サイズ 扱うデータ ：： S、M、L、その他サイズ....
- ベストアンサー
- MySQL
- 利用者数１０万のデータベース設計について
WEB上で利用者数１０万のマイページ機能をもつようなビジネスサイトを構築しようと考えています。 ユーザーのID,PASS管理と ユーザーごとのマイページの中にスケジュール管理機能、顧客管理機能 を設けます。 このような大規模なデータベースの設計例を教えていただけないでしょうか？ データベースにはMySQLを使用しようと考えています。 ユーザーのID管理は一つのテーブルじゃ無理ですよね？ その場合どのように分ければいいのしょうか？ ユーザーごとのマイページはユーザーごとにスケジュールテーブルなどを 作るべきなのでしょうか？ MySQLの物理的最大DB,テーブル数の制限などあるのでしょうか？ 私自身はデータベースプログラムが出来ないため設計の部分でお教えいただけたらと思います。
- ベストアンサー
- その他(データベース)
- データベーステーブル設計
簡単なアプリケーションを作ろうとしています。内容は、レストランのデータベースです。画面には、単純にレストラン名、住所、電話番号、営業時間、評価を表示させたいです。この「評価」は、このアプリケーションを使用する３人のユーザが入力する１～５の値の平均値としたいです（ユーザはメンテナンス画面から１レストランにつき１回まで評価値入力可能）。つまりユーザAが４、ユーザBが５、ユーザCが１を入力した場合、4+5+1/3=3.3を表示します。テーブルを設計した経験がないので教えてほしいのですが、この場合、どのようなテーブルを作れば最もシンプルできれいに出来るのでしょうか。まずレストランテーブルを作成する必要があると思いますが、「評価」があるために１テーブルでは不足だと思います。評価カラムの値はユーザが値を入力すれば変動することになるので、別テーブルを参照させるようにすべきなのでしょうか？評価テーブルというものを考えてみましたが、ユーザ名とレストランIDの複合をプライマリキーとし、評価値カラムをもたせるとしても、どこに平均値を持たせればいいのかわかりません。テーブル設計の模範例を教えて頂けると助かります。宜しくお願いします。
- ベストアンサー
- Oracle
- mysqlのデータベース設計(1テーブルで管理)
お世話になります。 現在、会員がログインしてブログ管理できる(記事を作成・編集できるシステム)を考えています。 そこでデータベース設計について質問があります。 一般的には、 ・ユーザー情報に関するテーブル ・ブログ記事に関するテーブル この２つを以下のような感じで設計すると思うのですが↓ ■usersテーブル ・id ・ユーザー名 ・パスワード ■articleテーブル ・id ・user_id(記事投稿者のid) ・contents(ブログタイトル、ブログ本文) ・created ・modified 私は、この２つを１つのテーブルですべてまとめて管理することを考えているのですが、 何かデメリットはあるのでしょうか？↓ ■usersテーブル(このテーブル１つですべてまとめて管理) ・id ・ユーザー名 ・パスワード ・contents(ブログタイトル|ブログ本文|記事投稿日|記事編集日) ・created ・modified ちなみにブログ記事は、区切り文字で分けながらcontentsにどんどん詰め込んでいき(updateする)、 取り出すときは区切り文字をexplodeしていく形を考えています。 実際にはもっと項目が多くなるのですが、１ユーザーの情報をすべて１つのテーブルで管理することで個人的に非常にわかりやすい、さらに単純なのでこちらのほうが速度も速いのではないかと思っているのですが、良くないのでしょうか？（あまり見かけないので） どなたか教えていただけると幸いです。 よろしくお願い致します。
- ベストアンサー
- PHP
- MySQLのテーブル設計について
PHPとMySQLを勉強中です。 データベースと連携させた「お気に入りのお店」を登録するような地図サイトを作ろうと思っているのですが、テーブル設計について疑問ですので、よろしければ教えてください。 ちなみにMySQLへ登録する項目は、 id（連番）、日付、ユーザーID、ユーザーパス、お店の名前、お店の住所、電話番号、HPアドレス、お店の写真 などを考えています。 １、効率のいいテーブルの設計とはどのようなものでしょう？ 素人考えでは、一括で管理したほうがよさそうだと思うのです。 ですが、他の方のスクリプトをダウンロードして見てみると、ほとんどテーブルが分割されていることが多いです。 どのような意図なのでしょう？？ ２、バイナリデータはbase64でテキストにしたほうがいいと本に書いてありましたが、テーブルも別にしたほうがいいのでしょうか？ ３、このような内容について、詳しい本などがありましたらぜひ教えてください。負荷分散とかバックアップなどについても勉強しようと思っています。 結局は、どのような使われ方をするかで設計が変わってくるような気がしますが、何分、勉強し始めたばかりでよく分かっていません。。 お手すきのときに教えてください。 よろしくお願いいたします。
- ベストアンサー
- MySQL
- 映画のデータベースの設計について・・・
データベースの設計について質問です。 現在、映画のデータベースのようなものを作成しようとしているのですが、そこで、出演者のデータをどのようにしようか悩んでおります。 タイトルごとにユニークなIDをふって、 出演者用のテーブルを作り、タイトルIDと出演者名を結びつけるという方法でいいのでしょうか？ この場合・・・ ・タイトルのIDを覚えておく ・出演者用のテーブルに移動し、IDと出演者名を入力する という作業が、出演者の人数分必要になりかなり大変そうなのですが、このような作業を簡略化する方法はあるのでしょうか？ わかりにくい文章でもうしわけありません。 どうかよろしくお願いします。
- ベストアンサー
- その他(データベース)
