2

1 つのプロジェクトから、非常に多数のファイルの静的ストレージの編成が困難になるまで。画像の場合、テーブル Image を作成し、ストレージのパスを計算するためのレコードを保持します。このような:

コード:

 $ image_id = 1665765;
 $ paddedId = str_pad ($ image_id, 20, '0 ', STR_PAD_LEFT);
 $ path = '/'. implode (DIRECTORY_SEPARATOR, str_split ($ paddedId, 2));

出力時: ==> webroor.upload/00/00/00/00/00/00/01/66/57/65/1665765.jpg

$ image_id は、画像が必要なエンティティのテーブル内のフィールドです ($ user-> image_id)。このアプローチにより、1 つの $ image_id に基づいて、ベースを呼び出すことなくイメージへのフル パスを指定できます。ファイルの形式が明らかにわかっている場合に機能します (この場合は、常に.jpg)。ただし、ユーザーがさまざまな形式の画像をダウンロードする必要がある場合があります。そして、このアプローチは実用的ではありません。スピリットを作成し、テーブルをファイル (画像) と結合して、ID でファイル化し、その展開パスを計算する必要があるからです。テーブル イメージが巨大になる可能性があるため (または別のデータベースであっても)、システム パフォーマンスが低下します。ストレージにあるレシピを共有してください。たぶん、誰かがより良い方法を考えているでしょう。

私の英語でごめんなさい。

4

1 に答える 1

1

2つの方法があります。

まず、データベース内のすべてのファイルのフル パスを格納するようにアーキテクチャを最適化する必要があります。しかし、既存のプロジェクトに膨大な数のコンテンツがあるため、簡単ではありません。2 つ目 - アップロードされたすべてのファイルを .jpg などの 1 つの特定の拡張子に変換すると、すべての問題が解消されます。多くの負荷の高いソーシャル ネットワークがこのソリューションを使用しています。

于 2012-10-25T10:11:02.267 に答える