テーブルを別ける判断要素をお聞かせ下さい

お世話になっております。データベースのテーブルの別け方について質問させて下さい。

例えば、会員制のブログサービスを公開するとして、各会員の個人情報を収めるmemberというテーブルを以下のような構成で用意したとします。
（idはURLの一部となるもの）

no　　id　　　mail　　　pass　　name　　blog_title
1　　lala　***@***.com　1234　　佐藤　　私の日記帳
2　　tecno　**@***.com　5432　　石田　　明日は何処へ
3　　nonno　**@***.com　9812　　毛利　　音楽大好き


上記は、会員の個人情報と併せ、ブログのタイトルなども1レコードで済むことが出来るので、会員情報とブログの情報も登録したケースです。



対して、以下は会員情報とブログ情報を別けた場合です。

memberテーブル
no　　mail　　　pass　　name
1　***@***.com　1234　　佐藤
2　**@***.com　 5432　　石田
3　**@***.com 　9812　　毛利


blog詳細テーブル(member_noとnoで紐付けている）
no　member_no　id　　　blog_title
1　　1　　　　lala　　私の日記帳
2　　3　　　　nonno　音楽大好き
3　　2　　　　tecno　明日は何処へ


例えばhttp://blog.sample.com/lala/
というURLにアクセスされた場合、１つのテーブルに情報が収められている場合、個人情報が登録されたテーブルに接続しなければなりませんが、ブログ情報だけを別にしたテーブルを設けていると、個人情報が登録されたテーブルには接続しなくても済むかと思います。

ここで質問させて下さい。
以前、1つのレコードで収まるなら、複数のテーブルを用意する必要はないといった意見を聞いたことがあるのですが、上記のような2つのケースの場合、やはり貴重な情報を含まれたテーブルは、極力、接続機会を減らす方が良いのでしょうか？

今日まで、1つのレコードで収まるなら複数のテーブルは用意することなく来ましたが、もしかして、

・2つのテーブルに別けようが、１つが漏洩したら全て漏洩したと同じだ。だから1つにまとめて問題ない。

・貴重なテーブルは接続機会を減らすべきだ。

というような意見があるのでは？と、意見を伺えればと思い、質問させて頂きました。

お忙しいとは思いますが、ご意見のほど宜しくお願い致します。

No.1 ベストアンサー 回答者： mitoneko 回答日時： 2014/02/19 21:03

　一つだけ、絶対にテーブルを分けておかなければいけないパターンがあります。

　一人の会員が、二つ以上のブログを持てる場合です。
　この場合、memberテーブルと、blog詳細テーブルが一対多の関係となるため、二つのテーブルが必要です。

　ブログは、金輪際、一人につき一つだと主張するのであれば、blog詳細テーブルのnoフィールドは不用です。
　memberテーブル　blog詳細テーブル共に、同じnoを使用することとして、主キーはどちらのテーブルでもnoとなり、結合するフィールドも当然noとなります。

　後者の場合において、テーブルを一つにするか二つにするかですが、・・・
　もし、セキュリティーを考えてというのが動機であれば、テーブルは一つで良いです。
　その代わり、テーブルに対してでは無く、フィールドに対してアクセス権限を設定します。
　当然、このようにセキュリティーを強化する場合、ブログを表示するためのプログラムと、会員情報をも扱うプログラムは、別々のＩＤでデータベースにアクセスすることになります。会員情報を扱うＩＤにはテーブル全体に対する権限を許可して、ブログを表示するＩＤには、ブログ情報のフィールドのみにアクセス許可を与えておくわけです。
　ブログを扱うプログラムは、どうあがいても、会員情報にアクセスすることは出来ません。

　同じＩＤでデータベースにアクセスするのであれば、テーブルをいくつに分けようが、セキュリティーは強化されません。

　さて、不正侵入を考えます。ルートが破られれば、何をどうやっても漏洩の阻止は不可能です。
　アクセスするためのＩＤを分けてあれば、最悪、ブログ情報用のＩＤに関しては破られても、会員情報へのアクセスは出来ません。漏洩するのは、ブログ情報だけです。会員情報が破られたら、テーブルを分けていようが同じテーブルだろうが一緒のことで、全データが漏洩します。

　また、データの保全という意味では、どうせ、データベースが壊れたら、テーブルをいくつに分けていようがデータベース丸ごと壊れますから、一緒のこと。　

　となると、検討するのは、どちらの方が保守管理が楽になるかです。
　もう一つの検討課題は、テーブルを分けると、会員情報全体を集約する時に、テーブルの結合が余計に発生します。
　また、テーブルを分けた時には、memberテーブルにある会員にのみ、blog詳細テーブルの情報を作るように、整合性を保証する必要があります。普通は、テーブル定義の時に、参照性制約を定義して保証するのですが、ＭｙＳＱＬでは、ファイル形式の選択によって、之が出来るかどうかが変わるところには注意が必要です。

　後は、動機と環境によりますね。
　シンプルさを考えるなら（当然、保守性はシンプルなのが一番です。）、わたしなら、１テーブルにします。

この回答へのお礼

mitonekoさん

はじめまして。貴重なご意見をありがとうございます。

考えるべきポイント等、とても勉強になりました。

お恥ずかしいことかもしれませんが、これまでアクセス権限など出来ることすら知りませんでした。
今回を機に、色々と調べてみたいと思います。

長文に渡り、詳しい内容の書き込みをありがとうございました。感謝しています。

お礼日時：2014/02/20 20:14