- ベストアンサー
テーブルを別ける判断要素とは？
- データベースのテーブルを別ける判断要素とは何でしょうか？会員情報とブログ情報を別々のテーブルに分けるかどうかは、情報の安全性やデータの関連性などを考慮して判断する必要があります。
- 1つのレコードで収まる場合でも、貴重な情報を含むテーブルは接続機会を減らす方が良いとされています。しかし、複数のテーブルに分けた場合、1つのテーブルが漏洩した場合は他のテーブルも漏洩する可能性があるため、適切なセキュリティ対策が必要です。
- また、会員情報とブログ情報を分けることで、データの冗長性を減らし、データの一貫性を保つことができます。さらに、データの運用や管理を効率化することもできます。
- みんなの回答 （1）
- 専門家の回答
質問者が選んだベストアンサー
一つだけ、絶対にテーブルを分けておかなければいけないパターンがあります。 一人の会員が、二つ以上のブログを持てる場合です。 この場合、memberテーブルと、blog詳細テーブルが一対多の関係となるため、二つのテーブルが必要です。 ブログは、金輪際、一人につき一つだと主張するのであれば、blog詳細テーブルのnoフィールドは不用です。 memberテーブル blog詳細テーブル共に、同じnoを使用することとして、主キーはどちらのテーブルでもnoとなり、結合するフィールドも当然noとなります。 後者の場合において、テーブルを一つにするか二つにするかですが、・・・ もし、セキュリティーを考えてというのが動機であれば、テーブルは一つで良いです。 その代わり、テーブルに対してでは無く、フィールドに対してアクセス権限を設定します。 当然、このようにセキュリティーを強化する場合、ブログを表示するためのプログラムと、会員情報をも扱うプログラムは、別々のＩＤでデータベースにアクセスすることになります。会員情報を扱うＩＤにはテーブル全体に対する権限を許可して、ブログを表示するＩＤには、ブログ情報のフィールドのみにアクセス許可を与えておくわけです。 ブログを扱うプログラムは、どうあがいても、会員情報にアクセスすることは出来ません。 同じＩＤでデータベースにアクセスするのであれば、テーブルをいくつに分けようが、セキュリティーは強化されません。 さて、不正侵入を考えます。ルートが破られれば、何をどうやっても漏洩の阻止は不可能です。 アクセスするためのＩＤを分けてあれば、最悪、ブログ情報用のＩＤに関しては破られても、会員情報へのアクセスは出来ません。漏洩するのは、ブログ情報だけです。会員情報が破られたら、テーブルを分けていようが同じテーブルだろうが一緒のことで、全データが漏洩します。 また、データの保全という意味では、どうせ、データベースが壊れたら、テーブルをいくつに分けていようがデータベース丸ごと壊れますから、一緒のこと。 となると、検討するのは、どちらの方が保守管理が楽になるかです。 もう一つの検討課題は、テーブルを分けると、会員情報全体を集約する時に、テーブルの結合が余計に発生します。 また、テーブルを分けた時には、memberテーブルにある会員にのみ、blog詳細テーブルの情報を作るように、整合性を保証する必要があります。普通は、テーブル定義の時に、参照性制約を定義して保証するのですが、ＭｙＳＱＬでは、ファイル形式の選択によって、之が出来るかどうかが変わるところには注意が必要です。 後は、動機と環境によりますね。 シンプルさを考えるなら（当然、保守性はシンプルなのが一番です。）、わたしなら、１テーブルにします。
お礼
mitonekoさん はじめまして。貴重なご意見をありがとうございます。 考えるべきポイント等、とても勉強になりました。 お恥ずかしいことかもしれませんが、これまでアクセス権限など出来ることすら知りませんでした。 今回を機に、色々と調べてみたいと思います。 長文に渡り、詳しい内容の書き込みをありがとうございました。感謝しています。