0

ユーザーが送信するファイルをホスティングします。ファイルからデータを取得し、それをディレクトリに移動する必要があります。

このファイルの存続期間には、2 つの興味深い点があります。1 つ目はデータが抽象化されているときで、2 つ目は共有できるようにファイルがアーカイブされているときです。

データが抽象化されている場合、ファイルの名前を一意のものに変更するか、一意の文字列をファイル名に追加して、他の既存のファイルを上書きしないようにすることを考えました。

ファイルをアーカイブするとき、私は 3 つの方法を考えました。1 つは、特定のデータからアップロードされたすべてのファイルを 1 つのフォルダーに保持することです。(2006/sept/04, 2008/jan/05) もう 1 つは、フォルダーを保持し、フォルダーに保持したいファイルの最大数までそれをいっぱいにしてから、別のフォルダーを作成することです (/folder001/、/folder002/、 /folder003/ など)。もう 1 つは、あるしきい値に達したらサブフォルダーを作成することです。(/j/jd/jde/jdelator) のように、これを unix で見たことがありますが、これを説明する方法がわかりません。

私が持っている質問は、皆さんが有用だと思った、または使用した戦略の種類は何ですか?

4

4 に答える 4

3

データが抽象化されている場合は、次のようなものを選択します。filename + millisec(); ミリ秒への2つの呼び出しが同じになることはほとんどなく、アクセスするときはファイル名の方が使いやすいです。

古い未使用のファイルを削除する場合は、日付戦略が便利です。ログによると、2006 フォルダーを取得し、昨年アクセスされていないファイルをすべて削除するだけで済みます。これは、新しいファイルかどうかをユーザーが判断できるため、ユーザーにとっても良い指標となります。folderXYZ は、N 個のファイルごとに日付をタグに置き換えた、これの変形にすぎません。

しきい値のサブフォルダーを使用すると、ディレクトリのエントリ数を低く抑えることができるため、アクセスが高速になります。このソリューションでは、特定のディレクトリが大きくなると、ファイルを移動する必要があることに注意してください (マップされていない場合は、一部の URL を壊す必要があります)。

もう 1 つの可能性は、ファイル名の場所に対応する UID を持つ DB を使用し、 http://server.com/UID/filename.txtを介してファイルにアクセスすることです。このようにして、ユーザーはファイルを便利な「filename.txt」として保存し、ファイルを見つける場所の URL を知ることができます (DB を使用して UID を場所に変換します)。同じファイルの重複を処理するために、UID をチェックサム (MD5、SHA-1) にすることができることに注意してください。

于 2008-09-17T09:17:17.147 に答える
2

データベースでguidを使用して投票し、必要に応じてContent-Dispositionヘッダーを使用して元のファイル名に名前を付け直します。私が提唱することの1つは、使用するフォルダーがWebルートの外部に保存されていることです。ユーザーがアプリケーションフォルダにファイルをアップロードしないようにする必要があります。

于 2008-09-17T07:01:50.263 に答える
1

ID（int）をファイルの名前であるuuidにタグ付けするリレーショナルデータベースを使用しました。このように、それらがディスク上にどのようにあるかは問題ではありません。ファイルを難読化するのに役立ちます。また、JOIN を使用してファイルを任意に「名前変更」することもできます。また、別のファイル「名」を使用することもできます。それはすべて、アプリとそれが実行されている場所によって異なります。

于 2008-09-17T06:38:37.403 に答える
1

アプリケーションなどにもよりますが、今のところファイル リポジトリ スキームを非常にシンプルに保ち、後でより複雑な戦略を決定することをお勧めします。言い換えれば、しばらくの間、一種の「管理された混乱」を引き起こします。構造と戦略は、すべての要件とドメインの詳細を見つけるときに後で出てきます。シンプルに保つことで、すべてを簡単に変更できます。

とにかく、変更は避けられません。今できる最善のことは、何らかの戦略を選択し、すべてを文書化することです。

于 2008-09-17T06:52:35.717 に答える