0

たとえば、ブログに記事のリストがあるとします。各記事には 1 つの画像があり、各画像には 1 つのサムネイルがあります。

記事のリストを表示すると、それぞれがサムネイルで表示されます。単一の記事を表示するときは、フルサイズの画像で表示されます。

これは、記事ごとに 3 つの大きな (サイズ不明の) データ項目 (画像、サムネイル、テキスト) があることを意味します。

これらの設計の長所と短所は何ですか:

  1. 記事テーブルにはサムネイル列と画像列が含まれます
  2. 記事テーブルには、サムネイル列、別のテーブルに保存された画像が含まれます
  3. サムネイルと画像を 1 つの個別のテーブルに保存
  4. 独自の個別のテーブルに保存されたサムネイルと画像
  5. サイトには、画像とサムネイルが保存されているフォルダーへの書き込みアクセス権があり、データベースには URL/ファイル名が含まれています

（私が考慮していないものはありますか？）

それが違いを生むのであれば、私はそうすべきではないと思いますが、サイトは Postgres または MySql を使用して Ruby/Rails で作成されます。

4

2 に答える 2

1

IMO、オプション5が最適です。データベースに画像を保存できるからといって、そうする必要があるわけではありません。ファイルの場所と画像に関するメタデータをDBに保存します。画像をファイルシステムに保存します。

DBに画像を保存することの「短所」は、アプリで実際に画像を使用するためにフープを飛び越えてしまうことです。ほとんどすべてのライブラリ、スクリプト、アドオンなどは、特別なコーディングなしでディレクトリにある場合、画像を使用できます。それらをDBに入れて、それらを使用するためのアクセスを提供するためにコードを書く必要があります。

私が見ることができる唯一の利点は、複数のWebサーバーが単一の（または複製されたデータベース）を使用し、写真がすべてのWebサーバーで自動的に利用可能になり、データと画像を一度にバックアップできるWebファーム環境にあることです。

IMO、短所は、画像を保存するためにDBを使用する長所をはるかに上回ります。

于 2011-07-31T12:37:06.250 に答える
0

私が正しく理解していれば、データベースは、フィールドのデータ型とサイズに応じて、大きなフィールドを個別の「テーブル」に自動的に分離します。「列外ストレージ」などのGoogle 。これにも設定があるかもしれません。

つまり、大きなフィールド用に別のテーブルを自分で作成する必要はありません。

dbの代わりにディスクに保存することについては、わかりません。その質問はこれまで何度もされてきたと思います。

于 2011-07-31T12:25:50.390 に答える