WEBシステムのDB設計について

前へ 次へ
このQ&Aのポイント
  • WEBシステムのDB設計について質問です。プロの方が作るシステムでは通常、ユーザーを識別する主キーは「ログインID」でしょうか？「ログインID」は認証用のみ使用して、識別キーは別に作ったほうが良いのでしょうか？
  • プロの方が作るWEBシステムの、認証・ユーザーマスター部分のDB設計の定石などありましたら教えてください。
  • ２パターン考えました。パターン１では認証テーブルとユーザーマスター、グループマスターの３つのテーブルを使用します。パターン２では認証テーブルなしでユーザーマスターとグループマスターの２つのテーブルを使用します。ご指導いただけたら嬉しいです。
回答を見る
  • ベストアンサー

WEBシステムのDB設計について

趣味でWEBによるグループウェアを作ろうと思ってます。 DB設計について質問です。 プロの方が作るシステムでは 通常、ユーザーを識別する主キーは「ログインID」でしょうか？ 「ログインID」は認証用のみ使用して、識別キーは別に作ったほうが良いのでしょうか？ ※ログインIDは1度設定したら変更不可にしようと思ってます。 プロの方が作るWEBシステムの、認証・ユーザーマスター部分の DB設計の定石などありましたら教えてください。 ２パターン考えました。 ＜パターン１＞ ■認証テーブル １．ログインID（主キー）※認証のみ使用 ２．ログインパスワード ３．ユーザーID（外部キー）※ユーザー情報、その他の識別主キー　システム自動で設定 ■ユーザーマスター １．ユーザーID（主キー） ２．名前 ３．メールアドレス ４．グループID ５．その他情報 　　　： ６．更新日時 ７．更新者 ■グループマスター １．グループID（主キー） ２．グループ名 ３．ユーザーID（外部キー） 　　　： ＜パターン２＞ ■認証テーブルなし ■ユーザーマスター １．ログインID（主キー）※ユーザー識別キー ２．ログインパスワード ３．名前 ４．メールアドレス 　　　： ７．更新者 ■グループマスター １．グループID（主キー） ２．グループ名 ３．ログインID（外部キー） 　　　： ご指導いただけたら嬉しいです。

質問者が選んだベストアンサー

  • ベストアンサー
回答No.1

ユーザーの要望にも寄りますが、＜パターン２＞がユーザー用件的にもシステム的にもわかりやすくなるのではないでしょうか。 ＜パターン１＞は二つのＩＤを意識しなくてはならないため、ややこしくなりがちです。 ちなみに自分が携わってきたシステムは、 ■ユーザーマスター １．ログインID（主キー）※ユーザー識別キー ２．ログインパスワード ３．名前 ４．グループID（外部キー） ■グループマスター １．グループID（主キー） ２．グループ名 のような感じが大半です。

  1. カテゴリ
  2. [技術者向] コンピューター
  3. データベース
  4. その他(データベース)

関連するQ&A

  • DB設計が分かる基礎書籍

    ＤＢ設計をマスターすべく基礎となる書籍を探しています。ユーザから見た動き、基本設計が理解できる、定評の書籍をご紹介頂ければと思います。

  • データベースの設計について教えてください。

    データベースの設計について教えてください。 基本的な質問ですみません。宜しくお願いいたします。 単純なテーブルで表現しますが、 パターンA、Bのどちらのテーブルで設計するのが良いのでしょうか。 DBはmysqlで5000万件のデータで検索のみのデータベースです。 【前提】 ユーザは複数のメールアドレスを持ちます。 画面から、このユーザのもつメールアドレスを表示させる仕様だとします。 【userマスタ】 (PK)ユーザID 　　ユーザ名 　　会社名 ＜パターンA＞ 【mailテーブル】 (PK)ユーザID (PK)ユーザメールアドレス 　　モバイル用アドレス ＜パターンB＞ 　【mailテーブル】 (PK)ユーザメールアドレス 　　モバイル用アドレス 　　ユーザID　←インデックスをはります。

    • ベストアンサー
    • MySQL
  • ［DB設計］多対多の問題点とは

    現在あるシステムを作成する上で、DB設計をしています。 このDB設計をする上で、多対多の状態だと良くない（できない？）とよく聞きます。 例）一人の学生は複数の講義を受講し、一つの講義には複数の学生が受講する。 この時に、学生の情報を格納する「学生DB（主キー：学生番号）」と、講義の情報を格納する「講義DB（主キー：講義番号）」を作成します。そうするとこの二つのDBの関係って、多対多になってしまうと思うのですが、この場合どのような問題が起きますか？ 例がちょっとわかりにくいかもしれませが、要は 「DBを多対多の状態で設計した場合の問題点は何か？」 ということをお聞きしたいです。 よろしくお願いします。

  • 現在php(php5)とDB(MySQL)の勉強として情報管理システム

    現在php(php5)とDB(MySQL)の勉強として情報管理システムを作成しているのですが， 認証機能でつまづいています. 私が認証機能を使いたいのは以下の場面です. ? 利用者がログインする場合 　ただし，利用者側と管理者側を区別できるようにする ? パスワードを変更したい時，パスワード変更画面へログインする場合 ?は，PearのAuth_HTTPモジュールを利用して，DBに登録してあるidとパスワードを組み合わせてBasic認証をするところまでできました.(管理者側のみ) これで出来たと思ったのですが・・・ Basic認証はwebブラウザを閉じるまでログイン状態が続いてしまうので，他に認証を使いたい場面で認証の意味がなくなってしまいました； (すでにログイン状態なので簡単に入れてしまうんです；) 1度ログインした状態で，さらに認証機能をつけるにはどうすればよいでしょうか？ 現状をうまく説明できていなかったらすいません. php,DBともに初心者なので単純な質問かもしれません； よろしくお願いします.

    • ベストアンサー
    • PHP
  • ActiveDirectoryでシステム毎の管理

    ActiveDirectoryでシステムごとの利用可否の管理は可能でしょうか？ うちの会社ではPCのログインにはActiveDirectoryのドメインによる認証を行っていますが、 業務システムのID/パスワードはシステム毎に異なり、それぞれユーザが覚える必要があります。 ActiveDirecoryで、PCのログインIDだけでシステム毎の利用可否を判定する認証機能を提供することは可能でしょうか？ あるいは、それを実現するにはID管理用の認証基盤システムを別途構築する必要がありますか？ 基本的な質問で恐縮ですが、よろしくお願いします。

  • 異なるサーバのDBデータ同士を結合するには？

    全く違うサーバに載っているDBのデータ同士を結合するいい手段はないでしょうか？ DBは両者ともOracleですが9と10という違いがあります。 SERVER１に載っているDBは商品管理のためのものです。主キーは「品ID」です。 SVR２に載っているDBは、保証期間の管理をするためのものです。主キーは「品ID＆メーカーID」です。 唯一データのつながりを作れそうなのは両者の主キーのみです。 あとのデータには何にもつながりはありません。 どちらかのサーバに片方のDBのテーブルを作るとかビューを作ればいいかと思いましたが、その方法についてはNGとされています。 （とりあえずその方法でやる場合できますでしょうか？？？） DBに何かを作ることなくデータの結合をさせれないでしょうか？ SQLplusなりSQLクリエイトツールなりどんな方法でもDB自体汚さない限り問題はありません。

  • DB設計についてアドバイスお願いします。

    作成するアプリケーションは簡単なスケジュール管理のできるWEBアプリケーションです。 以下、作成予定のテーブルです。 ＜tbl_date＞ id VARCHAR(50) ・・・PRIMARYKEY / not null / AUTO INCREMENT date VARCHAR(8) ・・・not null ＜tbl_schedule＞ id VARCHAR(50) ・・・PRIMARYKEY 、not null 、AUTO INCREMENT morning VARCHAR(50) afternoon VARCHAR(50) evening VARCHAR(50) 以下、ページ詳細です。ユーザー側と管理側に分けています。 ＜ユーザー側＞ １ページ目 ⇒はじめのページで日付を選択する。プルダウンメニューで日付を選択してsubmitボタンを押すと選択された日付がDBに登録され、次の画面に遷移する。 ２ページ目 ⇒登録されているスケジュールをDBから呼び出して表示する。 ＜管理側＞ １ページ目 ⇒はじめのページで日付を選択する ※ユーザー側とは別のページ ２ページ目 ⇒スケジュールの編集画面。テキストフォームと登録されているスケジュールをDBから呼び出して表示する。 DB設計は初挑戦なので見当違いなところ多くあると思います... ご指摘、アドバイス等いただけたらと思います。よろしくお願いいたします。

  • テーブル設計の主キーについて質問があります。

    テーブル設計の主キーについて質問があります。 マスタを物理削除せず、論理削除するデータベースを考える時、 削除日時を主キーに持ってきたりするレイアウトはよくありますでしょうか。 DBはmysqlです。 例） ＜会社マスタ＞ （PK)会社コード （PK)会社支店コード （PK)削除日時 　　　会社名 　　　住所 主キーにNULL値は入れられないと思うのですが（←あっていますでしょうか）、 削除日時を無理やりNULL以外のものを入れたとします。 そしてアプリケーションで検索を考えた時に、”削除になっていないもの” を対象にレコードを探します。 インデックス（この場合は主キーですが）が検索高速化に有効に使われるのは、 なるべく対象が少なくなるものと思います。 以上を考えれば、 割合が多い削除日時を主キーにもってくるのはいかがなものかと思うのですが、 どうなのでしょうか。 宜しくアドバイスお願いいたします。

    • ベストアンサー
    • MySQL
  • ポイントシステムのDB設計

    こんにちは！みなさんのお知恵をお借りしたいと思っています。 下記の要件を満たすDB設計をしたいです。 MySQL5.5 + Java 5で実装予定です。 システム概要 (1)ユーザはWebサイトにて、ポイントを購入し、ポイントを使用することでアイテムが購入できる。 (2)ポイントは常時、購入することが可能で、アイテムも同様に常時、購入可能である。 (3)ポイントには有効期限があり、購入日から有効期限(1年)が過ぎたポイントは無効となる。 (4)購入するポイント数はユーザが任意の値を入力することができる。 (5)アイテムを購入する際に必要なポイント数は、アイテムによって異なる。 (6)ポイントが消失するのは月末である。 (例.2013年7月に購入したポイントは2014年8月1日になると消失する) (5)ユーザー数は300万程度 満たしたい要件 ・現在のポイント残高はWebサイトにて常時閲覧可能としたい。 ・当月に無効となるポイント数は常時閲覧可能としたい ・Webサイトをメンテナンスにして、バッチを流すなどの処理はなるべく避けたい。 お知恵を貸して頂けると幸いです。よろしくお願いします！

  • 項目があったりなかったりするテーブル設計について。

    伊藤と申します。 postgreSQL7.2.2を使用して、Webアプリケーションを制作しています。 テーブル設計で迷っているところがあります。 HTMLのフォームのデータを取り込み、データベースに格納する、 と言う事をしたいのですが、クライアントが自由に フォームの内容を変えることができるようになっています。 そこで、変わったパターンが出てきてテーブル設計に困っています。 Radioボタンが3つあるとします。 1番目と2番目がチェックされるときは問題ないのですが、 3番目をチェックしたときにはさらに、 テキストボックスに入力を求められる事があるのです。 　下記のような場合が問題になります。 ==================================== Q2　あなたのすきな食べ物は？ ○りんご ○みかん ○その他　↓下のボックスに入力してください 　＿＿＿＿＿＿＿＿＿＿＿＿＿＿ |＿＿＿＿＿＿＿＿＿＿＿＿＿＿| ==================================== 以下が現状です。 ■環境 OS：Turbolinux 7 Server DBサーバ：postgreSQL ■テーブル ・質問テーブル ・質問選択肢テーブル ・回答テーブル ■キー 質問テーブルの主キー(質問ID)に対して、 質問選択肢テーブルにある外部キーがリレーションします。 質問選択肢テーブルにはシーケンスもあり(選択肢No)、 質問IDと選択肢Noで主キーとしています。 ■問題 ・例外的な選択肢追加を（ある選択肢に対して並行に） 　可能にするには質問選択肢テーブルをどう設計すればいいのか。 ・回答テーブルに通常なら選択された値をレコードに 　格納するだけだが、 　ひとつ項目が増える事もイレギュラー的に発生するので、 　回答テーブルどう設計するか。 以上2点です。 長くなって申し訳ありません。 ご教授よろしくお願い申し上げます。

注目のQ&A

カテゴリ

専門家に質問してみよう

職業から探して質問する

あなたにピッタリな商品が見つかる！ OKWAVEセレクト

質問する