データベースの設計について

質問

現在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の対応が確実に取れるかなど不安な点がありますので、アドバイスいただけたらと思います。
もちろんこの方法に固執する必要はなく、結果的に同じようなテーブルが得られれば問題ないです。
長々と失礼致しました。

回答No.1

ToOrisugaru · ベストアンサー

はじめまして、通るすがるともうします。
ご質問の内容なのですが、設計手法についてのご質問かと判断してお答えします。
ＤＢ（ＲＤＢリレーショナルデータベース）の設計について、以下の要領でテーブルを
決定します。（概要ですが）
１．ＤＢに持たせる必要な項目の洗い出しから始めます。
２．次にそれらをあるカテゴリ別に分類していきます。
３．各々のカテゴリについて関係を分析する。
４．カテゴリ毎の項目属性について検討する。
５．テーブル名、項目名の付け方のルールを検討し、項目名を付与する。
という具合に設計を進めていきます。
カテゴリとは（エンティティ）、その業務の内容を熟知していなければできません。
いきなり、入力イメージが出てきて、それにシーク番号がついたイメージを記述
されても、他の人はその業務について無知な訳ですからアドバイスのしようが
ないことになります。
データベース設計は、ＤＢ構築、テーブル定義などの知識とは別に設計手法なる
知識および経験が必要となります。
まず、「データベース設計」というキーワードで検索してみてください。
また、それらについて専門書がありますので、何冊かそれらの書物を読み
試行錯誤し研究することが必要と思います。

これらを誤って、設計し入力イメージ、項目追加により作成したテーブルが大幅に
変更となり大変なことになったシステムを私は多く見てきました。

これとは、別に性能についても検討をしていきます。
たとえば、一つのテーブルに数千万件、数億件のレコードが入るとします。
これらを一つのテーブルスペースに配置した場合、検索に時間がかかりレスポンス
が低下するのであれば、使い勝手が非常に悪くクレームが上がるかもしれません。
レスポンス低下の原因として、これだけでもなくｐｏｓｔｇｒｅｓのメモリ割り当て、１テ
ーブル当たりの項目数、項目属性、テーブルレコード長などの原因により低下する
こともあるかと思います。またインデックス等の検討も必要となります。

さらに、サービス運用時のインデックス分割監視によるレスポンス低下による
作業方式、ハード障害時の対応方法等も検討しなければなりません。

なにぶん回答文字制限により説明不足かもしれませんが、効率的な設計ができるこ
と、ご検討を祈ります。

お礼

お礼が遅れまして申し訳ありません。

まだまだ試行錯誤が必要なようですね。ありがとうございました。