1

だから私はアルバムで整理された画像ギャラリーのウェブサイトを持っているので、アルバムの画像を保存するdbテーブルは基本的にこのスキームを持っています:

album_id | images_link
112      | 1.jpg
112      | 2.jpg
112      | 3.jpg
112      | 4.jpg
112      | 5.jpg
112      | 6.jpg
112      | 7.jpg
112      | 8.jpg
112      | 9.jpg

したがって、非常に長いデータベーステーブルを避けるために、アルバムのすべての画像を次のように単一のセルに保存することを考えています:

album_id | images_link
112      | 1.jpg, 2.jpg, 3.jpg, 4.jpg, 5.jpg, 6.jpg, 7.jpg, 8.jpg, 9.jpg

もちろん、データベースのサイズは同じままですが、読み取る行が大幅に少なくなります。分解機能を使用して、各画像ファイル リンクを分割して提供します。これは賢い選択ですか？爆発関数が大規模なデータベースを取得するのと同じくらいメモリを消費するかどうかはわかりません。ご意見をお聞かせください。

問題は、画像名がそれほど短くないことです。images_link行は27文字に設定されているため、設定したアルバムごとに30枚の写真に制限されているため、1つのセルは後で810文字に達すると予想されます。そのバイト数を格納するために varchar を使用したことはありません。この場合は VARCHAR を使用するか、 TEXT を使用する方がよいでしょうか? VARCHAR の方が速いことはわかっています。

前もって感謝します。

4

3 に答える 3

3

最初のスキームは 2 番目のスキームより優れています。

メンテナンスに適しています：

  • 新しい画像を配置するための行の追加のみ
  • 行のみを削除してイメージを終了する
  • 画像のパスを編集したい場合は、その行を更新するだけです...

後で、最初の画像でギャラリーを一覧表示する場合は、JOIN を実行するだけで済みます...

2 番目のスキーマでは、"list_of_images" という名前のカテゴリ テーブルにフィールドがあることに違いはありません...

于 2012-12-07T22:20:07.237 に答える
2

いいえ、それをしないでください。「超長いデータベーステーブル」があっても問題ありません。サブアイテムを 1 つの列に集約することには、多くの潜在的な問題があります。

「読み取る行が大幅に少なくなる」とあなたは言います。詳細テーブルを使用せず、すべてをヘッダー テーブルに詰め込むと、ある種の速度が向上することを想像していますか? ありません。

あなたが今持っている方法は、それが行われるべき方法です。そのままにして、学び続けてください。

于 2012-12-07T22:19:53.853 に答える
0

images_link 列を維持するのは悪夢になるため、元のテーブル構造を維持する必要があります。album_id=112 および images_link=3.jpg の行を削除するとどうなりますか?

単一行への読み取りを簡素化する場合は、group_concat を使用してクエリを試してください。

SELECT GROUP_CONCAT(images_link) FROM tbl_album_images WHERE album_id='112'

返すべきもの

1.jpg,2.jpg,3.jpg,4.jpg,5.jpg,6.jpg,7.jpg,8.jpg,9.jpg

編集：明らかだと思いますが、album_idにインデックスがあることも確認してください

于 2012-12-07T22:20:44.337 に答える