- ベストアンサー
MySQLのテーブル設計について
- MySQLのテーブル設計について効率と使いやすさを考える
- バイナリデータの管理や負荷分散、バックアップの勉強も必要
- 詳しい本や参考資料を教えてほしい
- みんなの回答 (1)
- 専門家の回答
質問者が選んだベストアンサー
効率のよい:「正規化されてる」でしょうか 「正規化」のおおまかな意味は、「一意の情報は一箇所に」です。 >id(連番)、日付、ユーザーID、ユーザーパス、お店の名前、お店の住所、電話番号、HPアドレス、お店の写真 例えば、この中で、同一の店情報を、複数のユーザーが2重3重に登録することになります。つまり、その分だけ、ファイルサイズが肥大化します。 よって、店情報は店tableとして分けて、お気に入りtableでは、店IDだけ持つのが効率よいと考えます。 また、ユーザーごとの個別情報(ユーザーパスなど)も、お気に入りの登録個数ぶん多重登録されたり、登録のたびにパス変更したりされると過去のデータはパスが違うので変更できないなど困ったことになります。 ので、ユーザー別情報tableを別に持って、ユーザーパスはこのtableで一意に管理する。 といったことが必要になるでしょう。 画像データの扱いは、保存スペースとの関係や利用方法によるでしょう。 1.画像ファイル名のみ保持して、実データは別領域に置く 利点:データベースのサイズは小さく押さえられる。php出力では、他のテキスト情報とともに、img src=""にファイル名を記述するだけで済む。初心者向けの管理方法である。 不利点:画像の場所やファイル名がデータベースと連動せずに変更される可能性がある。 自サイト内の画像用スペースにアップロードする形式なら行方不明にはならないと思うけど、一般公開サイトなら画像の著作権とか肖像権とか商標とかの方が問題かも。 2.データベース内に画像データを取り込み、blob型で保持:sql文はテキストなので、base64encodeして入れ込むことになる。 利点:行方不明にならない。 不利点:データベースのサイズは大きくなる。php出力時は画像のみ個別に取得して画像のみ出力するスクリプトが別に必要になる。よってかなり知識が必要になる。 著作権とか肖像権とか商標とかの問題は上記と同じ。 別tableにするかは、レコードごとの画像枚数との関係もあるでしょう。 また、正規化の観点で、画像1枚ごとに、店IDの他に、誰が撮ったか、どっちからみた写真なのかなどの画像別情報を保持するなら別table管理がよいでしょう。
お礼
詳細にありがとうございます! よく分かりました。 正規化というのですね。疑問が解消されてすっきりです。 また、blobで保存とbase64encodeはデータベースへの格納方法が別だと思っていました。。 blob形に指定したmysqlテーブルにbase64encodeでテキスト化して入れるということですね。 とにかく色々といじってみます。 親切にありがとうございました。