データベースのblobフィールドに基づいてファイルシステムを作成する方法。 なぜ便利なのですか。 パフォーマンスの問題

親愛なる読者 これは、データベースシリーズの3番目の記事です。



目次：

1. 同じサーバー上の異なるデータベースに異なるタイムゾーンを作成する方法。
2. ユーザーによるデータ変更のログをデータベースに保存し、別のデータベースに保存する方法（メインデータベースが詰まって成長しないようにするため）
3. データベースのblobフィールドに基づいてファイルシステムを作成する方法。 なぜ便利なのですか。 ファイルストレージ効率の問題（最大のパフォーマンスを得ると同時に必要な最小スペースを取得する方法）

このメソッドは、ユーザーがWebインターフェイスを介してサイトに添付したファイルのストレージを実装するためのメソッドです。 これは、オペレーティングシステムで編成されているという意味で「ファイルシステム」ではありません。



この記事で説明する例は、私がかつて抱えていた問題を解決します。「 ウェブサイトで会社のアカウント内のセクションを選択します。会社の従業員がファイルを保存し、フォルダを作成します（「ディスク」と呼びましょう）。 ディスクは他の会社のアカウントから分離し、アカウントのプロセスに統合する必要があります（タスク、プロジェクト、取引相手のカード、レポートなどに適用されるファイルのストレージを整理する） 。



すぐに、速度の観点から、この方法は単純にファイルをWebサーバーに保存するよりも効果が低いことに注意してください。 しかし、これにはいくつかの利点があり、私の場合はダウンロード速度を落とすという欠点を上回っています。



マイナス：ファイルのアップロード時間の増加



メリット

1. 分散ストレージ構造。 つまり Webサーバー自体にクライアントファイルを保存する必要はありません。 ネットワーク上の任意のサーバーのどこにでも保存できます。 必要に応じて、サーバーからサーバーに簡単に移動します。
   
   
2. バックアップクライアントファイルの容易さ。 標準のバックアップツールを使用してすべてを実行できます。
3. 安全性 この方法には、ファイルをダウンロードする際のWebアプリケーションの主要な脆弱性はありません（たとえば、こちらを参照してください ）。 また、この方法では、各企業が独自のデータベースを持っているため、クライアントデータを他のクライアントのデータから物理的に分離します。

このファイルストレージシステムを実装する主な論点は、分散ストレージの可能性でした。 原則として、cifsやsambaなどのソリューションを使用し、他のマシンからネットワークドライブをマウントし、そこにクライアントファイルを保存できます。 しかし、その時点で私はこのようにここに来ましたが、標準的なソリューションではなく、私は完全に満足しています。



この記事では、実装プロセスを単純なものから複雑なものまで検討します。

1. ストレージ構造の一般的な組織。
2. blobフィールドにファイルを保存します。 直接抽出。
3. blobフィールドに中間アーカイブを使用してファイルを保存します。 中間解凍で抽出します。
4. 遅延選択アーカイブを使用してファイルを保存します（すべてのファイルがアーカイブに意味があるわけではありません。その場合、ゲームはろうそくに値しません。また、すぐにアーカイブすることは必ずしも意味がありません）。
5. 次に、ディレクトリ構造の編成、アクセス権の編成、ファイル操作、いくつかの特殊なケースなどを検討します。
   
   それでは始めましょう。

それでは始めましょう。



データベースとして、firebird 3が使用されます



1.ストレージ構造の一般的な組織。



前の記事（ログストレージ）のように、メインの作業データベースにファイルを保存しないでください。大量のゴミ、バックアップの問題などが発生します。 これを行うには、別のデータベースを選択することをお勧めします。 それを「ファイルDB」と呼びましょう。 ディレクトリ構造とファイルへのリンクはメインデータベースに保存する必要があり、ファイル自体のバイナリデータはファイルデータベースに保存されます。



この場合、バックアップの便利さと迅速なデータベースが得られます。 たとえば、私のシステムでは、ファイルデータベースのバックアップを含むバックアップを個別にスケジュールする機会をユーザーに提供しています。 さらに、ユーザーがFTPでユーザーにバックアップアーカイブを自動的にアップロードする可能性もあります（たとえば、ユーザーが自分の機器にバックアップを保存し、クラウドの場所を借りるのにお金を払わない場合）。 このような実装は、個別のデータベースにファイルを保存することと、分散ストレージシステムの構成のために可能です。



また、このような組織のおかげで、WebサーバーはWebサーバーの機能のみを実行し、ファイルストレージは実行しません。 ネットワーク上のリソースの配分をより適切に編成できます。 膨大な数のクライアント（膨大な数のデータベースとファイル構造）を使用すると、データストレージの割り当てられていない組織は受け入れられません。 構造は、シンプルであるだけでなく、無限にスケーラブルでなければなりません。



スキームは次のように表すことができます。









さらに、各要素は独自の個別のサーバーに配置できます（そうすることをお勧めします）。 データストレージ構造は、次のように編成できます。 添付ファイルに関するデータを含む構造がメインデータベースに作成されます

CREATE TABLE FILES_ ( ID BIGINT, DATA TIMESTAMP, --   DATA_DEL TIMESTAMP, --   USER_ INTEGER, --,   USER_DEL INTEGER, --,   ID_FILE INTEGER, --ID     FILE_NAME VARCHAR(256), --  FILE_NAME_TMP VARCHAR(256), --    CONTENT_TYPE VARCHAR(100), --   STATUS SMALLINT, --  (  ) SIZE BIGINT, --  SIZE_ZIP BIGINT, --   SIZE_ZIP_2 BIGINT, --   ZIP_USE SMALLINT, --    ID_FOLDER INTEGER, -- ,    FLAG_ZIP SMALLINT --   );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルデータベースの構造は次のようになります（blobフィールドのファイルとファイル自体に関する最小データ）。

 CREATE TABLE FILES_ ( ID BIGINT, DATA TIMESTAMP, USER_ INTEGER, --,   FILE_NAME VARCHAR(256), --  CONTENT_TYPE VARCHAR(100), --   FILE_DATA BLOB SUB_TYPE 0 SEGMENT SIZE 80, --   STATUS SMALLINT, -- (  ) SIZE INTEGER, --  SIZE_ZIP INTEGER, --   ZIP_USE SMALLINT --    );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これら2つのテーブルには相互にデータの冗長性がありますが、後で、たとえば、遅延バックアップ操作中、デバッグ中、後続のデータ分析中などに役立ちます。 複数のデータベースで同じクエリをブロックしないでください。



議論は、blobフィールドの単純なファイルエントリから始めます。



2.1。 blobフィールドにファイルを保存します。



WebフォームおよびWebサーバー上のディレクトリにファイルをアップロードするプロセスについては考慮しません。 読者がこれに精通していることを前提としています。



したがって、ユーザーがWebフォームのボタンをクリックすると、ファイルがアップロードされ、Webサーバーディレクトリに保存されます（たとえば、tmpになります）。



現在、グローバルFILES配列にファイルデータがあります。

（PHPで例を挙げます）



PS：プレゼンテーションを簡単にするために、危険な特殊文字のニーモニックへの変換、数値データから数値への強制的な縮小などを意図的に省略しています。 読者はこのための独自の手順を持ち、SQLインジェクションの危険性を認識していると想定されています。 そうでない場合は、このトピックに精通し、適切な変換を行うことを強くお勧めします。

 //    . $dbh_file = ibase_connect(…); //     $fd = fopen($_FILES[…]['tmp_name'], 'r'); //     $blob = ibase_blob_import($dbh_file, $fd); //  fclose($fd); //  ,       . if (!is_string($blob)) { } else { $query = 'INSERT INTO FILES_ ( USER_, NAME_FILE, CONTENT_TYPE, FILE_DATA, SIZE, SIZE_ZIP, ZIP_USE) VALUES ( '.$USER_.', '.$_FILES[...]['name'].', '.$file_type.', ?, '.$_FILES[...]['size'].', '.$_FILES[...]['size'].', 0) RETURNING ID'; $prepared = ibase_prepare($dbh_file, $query); $res_query = ibase_execute($prepared, $blob); $prom_query = ibase_fetch_row($res_query);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

$ prom_query [0]-記録されたファイルのIDの値になります。 ファイルデータベースにファイルデータを正常に書き込んだ後、メインデータベースにファイルデータを書き込む必要があります。

 // ,   , ID   . if (isset($prom_query[0])) //     $dbh_osn = ibase_connect(…); $query2 = ' INSERT INTO FILES ( USER_, ID_FILE, FILE_NAME, SIZE, SIZE_ZIP, CONTENT_TYPE, FILE_ NAME_TMP, ZIP_USE) VALUES ( '.$USER_.', '.$prom_query[0].', '. $_FILES[…]['name']).', '. $_FILES[…]['size'].', '. $_FILES[…]['size'].', '.$_FILES[…]['type'].', '.basename($_FILES[…]['tmp_name']).', 0)'; $res_query2 = ibase_query($dbh_osn, $query2); //       tmp. unlink($_FILES[…]['tmp_name']);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべて、ファイルデータベースに書き込まれたファイルがあります。 Webサーバー上にはありません。 メインデータベースには、このファイル、そのステータス、タイプ、サイズ、およびファイルデータベース内の識別子に関する情報が含まれています。



2.2。 データベースからファイルを読み取ります。



ユーザーがファイル名のリンクをクリックすると、逆のプロセスを実行する必要があります。 データベースからファイルを抽出し、このデータのシーケンスをユーザーのブラウザに提示して、ファイルの種類を伝えます。



リンクでは、ファイル識別子をGETパラメーターとして指定する必要があります（またはソルト付きの識別子ハッシュ-システムのセキュリティ要件に依存します。これまでのところ、単純な状況を検討します）。 たとえば、リンクはこのファイルのようになります。



データベースからの単純な読み取りの段階で（データをアーカイブせずに）、ファイルデータベースにアクセスするだけです。

 //     $dbh_file = ibase_connect(…) $query="select p.file_data, p.CONTENT_TYPE, p.FILE_NAME, p.size from FILES p where p.id=".$_GET['id']; $res = ibase_query($dbh_file, $query); $data = ibase_fetch_row($res);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ヘッダーでデータ型を指定すると、Chromeブラウザーで個々の問題が検出されました。 基本的に、ヘッダー内のファイル名は一重引用符で囲む必要がありますが、他のブラウザでは引用符なしで必要です。 このために、たとえば、次のソリューションを使用できます。

 preg_match("/(MSIE|Opera|Firefox|Chrome|Version)(?:\/| )([0-9.]+)/", $_SERVER['HTTP_USER_AGENT'], $browser_info); list(,$browser,$version) = $browser_info; if ($browser=='Chrome') header("Content-Disposition: attachment; filename='".str_replace(' ','_',$data[2])."'"); else header("Content-Disposition: attachment; filename=".str_replace(' ','_',$data[2]));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ほとんどの場合、スペースによって名前が切り捨てられるため、ダウンロード時にファイル名を正しく反映するためにスペースを「_」に置き換えます。



その後、ファイルのバイナリデータをスクリプトの本文に出力します。

 echo ibase_blob_echo($data[0]);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PS：ここで、典型的なエラーに注意を払いたいと思います。 <？Phpとafter？>の前に文字を入れないでください。そうしないと何も機能しません。



さて、リンクfile_b.php？Id = 123をクリックすると、ユーザーにはファイルをダウンロードするためのウィンドウが（名前とタイプとともに）表示されます。



3.1。 中間アーカイブを含むファイルをダウンロードする



ファイルを保存するかなり単純で基本的な方法を検討しました。 ここで少し改善します。 結局、バイナリシーケンスはデータベースに格納されます。短くしてスペースを節約してください。 これを行うには、ファイルデータをblobに書き込む前に、アーカイブします。

いくつかの統計：

この考えは、約1.5年前に初めて思いつきました。 その瞬間、私はある会社のためにアカウント調整モジュールを開発していましたが、この機能を実験的に統合することにしました。 アカウントと契約、pdf、xls、docなどに関する情報を含むあらゆる種類のファイルがこのモジュールに添付されます。



50〜70人のスタッフを抱える中規模企業で1.5年間、合計ボリュームが1526 mbの4085個のファイルが1つのモジュールに（現在）接続されていましたが、ディスク上ではすべて1240 mbかかります。 つまり zipアーカイブでアーカイブすると、約20％の節約になりました。 これはかなり良いです。

当時、アーカイブはスクリプト内のzip.lib.phpライブラリを通じて直接実装されていました。 後で、この方法は圧縮と速度の両方で最適ではないという結論に達しました。 現在、実際には、7zipアーカイバが使用されています。

アーカイブを使用してファイルをダウンロードしても、特別な問題は発生しません。 ファイルのBLOBシーケンスをデータベースに保存する前に、たとえば次のようにアーカイブする必要があります。

 exec('7z a < > < >);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして最後に、元のファイルに加えて、そのアーカイブをWebサーバーから削除します。



しかし、そのようなファイルをユーザーに抽出するプロセスは、はるかに興味深いものです。



3.2。 アーカイブから抽出してデータベースからファイルを読み取る



直接抽出の場合と同様に、機能しません。 ユーザーがリンクをクリックした後、まずファイルを読み取り、Webサーバーに保存し、解凍してからユーザーに転送する必要があります。



つまり ユーザーがリンクfile_b.php？id = 123をクリックすると、スクリプトは、このファイルをサーバーのディスクに保存した後、blobファイルからデータを考慮する別のスクリプトを（セクション2.2とまったく同じ方法で）ヤンクする必要があります。受信したファイルからそれを自分自身に持ち込み、ウィンドウがポップアップするように目的のヘッダーを置き換えます-彼はファイルをダウンロードしています。



これらの目的のために、CURLを使用します。



ブラウザのタイプを決定し、ヘッダーを置き換えてから、次の手順を実行します。

 //         //  $fp = fopen($path, 'w'); // curl-   ,       blob ,      . $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_USERAGENT, $agent); curl_setopt($ch, CURLOPT_FILE, $fp); curl_exec($ch); curl_close($ch); fclose($fp);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、$ pathというファイルに、アーカイブファイルが表示されます。 解凍します。

 exec('7z e '.$path.' –o < > -y');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、ファイルを読み取り、fpassthruを使用してスクリプト内に既にそのデータを統合します。

 $stream = fopen(< >,'r'); fpassthru($stream); fclose($stream);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これですべてがうまくいくはずです。



4. blobフィールドに中間アーカイブを使用してファイルを保存します。



次に、パフォーマンスの問題を検討します。 もちろん、場所を保存します。 ただし、ユーザーがファイルをサーバーにダウンロードするのを待つ代わりに、バックアップ時間とファイルがblobフィールドに追加された時間をユーザーに期待させます。 ユーザーにとって、ファイルのダウンロード時間は多くの場合2倍以上に増加します。 同様の方法で取得する場合、データを直接読み取るのではなく、保存、解凍、およびユーザーへの提供を開始します。 これはすべてあまり良くありません。 この場合、何ができますか？



1）最初に、ファイルをダウンロードするプロセスとアーカイブするプロセスを投稿できます。 つまり ユーザーはファイルを元の形式でアップロードします。 それから、ある頻度で実行されるスクリプトは、新しくダウンロードされたファイルを見てアーカイブします。 この場合、ユーザーはファイルをより速くダウンロードし、スペースを節約します。 さらに、このスクリプトの作業は別のサーバーで整理でき、Webサーバーのリソースを消費しません（高負荷のサーバーに強制的にアーカイブを実行させる必要があるのはなぜですか？）、このプロセスはゆっくりと行われます。



2）次に、すべての種類のファイルとは異なり、圧縮するのが理にかなっています。 たとえば、圧縮ファイルと非圧縮ファイルの違いが10％未満である場合、ゲームは明らかにキャンドルの価値がなく、スペースの節約は最小限です-プロセッサの負荷とユーザーの待ち時間が最大になります。 私自身は、アーカイバが触れず、単にチェックするだけの（処理済み-触れないように）次の種類の圧縮率の低いファイルを選択しました。 RAR、GZ、ZIP、JAR、TAR、ARJ、UC2、GZ、UUE、LHA、CAB、LZH、ACE、TGZ、7Z、AVI、MPG、3GP、WMV、ASF、FLV、MP3、AAC、WMA、AMR、 TIF、JPG、JP2、GIF、PNG。



PS： ivanbolhovitinovからの情報。 適切なXLSX、DOCXは常にZIPアーカイブです。 最初の2バイトはPKです。 次のように確認できます：file_get_contents（$ filename、NULL、NULL、0.2）



3）なぜなら ユーザーにファイルを抽出するときに、解凍作業も実行します。ファイルがアイテム2のタイプではない場合でも、アーカイブするのが理にかなっているという事実はありません。 空のアーカイブはリソースを使い果たし、さらにひどいのはユーザーの待機時間です。 したがって、システムは、ファイルをアーカイブする前に、これが適切かどうかを確認する必要があります。 これを行うには、予防的アーカイブのシステムを作成する必要がありました。 スクリプトは最初に「試行」します-ファイルをダウンロードしてアーカイブしますが、オリジナルをアーカイブで置き換える前に、アーカイブのサイズがオリジナルのサイズと何パーセント異なるかをチェックします。 この値も10％未満の場合、アーカイブは意味がありません。 このようなファイルは処理済みとしてマークされ、アーカイブされません。



このようなxlsxファイルの典型的な代表。 このフォーマットはすでに圧縮されていますが、実際には非常に異なるファイルがあり、50％圧縮できるファイルもあれば、5％圧縮できるファイルもあります。 充填に依存します。



4）サイズが250バイト未満のファイルをアーカイブすることも意味がありません。アーカイブは元のファイルより大きくなります。



5）大きなファイルをアーカイブする必要はありません。 これは15 mb以上の領域にあると経験的に推測されます。 たとえ圧縮率が高い場合でも（blobから解凍するのに加えて）解凍するのに時間がかかります-ユーザーのこのような一時的な期待はすでに負担になります。



5.ディレクトリ構造の編成、アクセス権の編成、ファイル操作、いくつかの特別な場合。



これまで、ファイルストレージシステムのみを検討してきました。 これは、他のすべてが基づいている基本的なものです。 ただし、本格的な「ファイルシステム」の場合は、これらのファイルを何らかの形で構造化し、アクセス権を割り当てるなどする必要があります。



おそらく、この章は誰にとっても興味深いものではないでしょう。なぜなら、 この構造の実装は、手元のタスクに大きく依存します。 この構造をerp-platforma.comクラウドサービスに実装したので、この章では、ファイルシステムが会社の組織サービスのために解決すべきタスクについて説明します。



1） クラシック -ディレクトリツリー、ファイル。 ファイルの適用、メタデータの編集、削除のメカニズム。



2）このアイテムには小さな紹介が必要です。 オートメーションシステムの作業で誰もが明らかなことを考慮しないでください。タスクにファイルを添付すると、そのファイルはタスクではなくディスクに物理的に保存されます。 タスクには、このファイルへのリンクのみが含まれています。



ディスク領域が不足した場合、システム管理者はそれをクリアする必要がある場合があります。 そして、20年以上にわたって彼のすべてのタスクを整理し、それらからファイルを削除することは、まあ、ばかげています。

つまり たとえば、ディスクに「タスク」サービスディレクトリなどのファイル構造が必要です。このディレクトリには、タスクに添付されたすべてのファイルが保存され、システム管理者は古いファイルを簡単に削除できます。



しかし、彼がそれらを削除するとどうなりますか？ タスクは、どこにも通じないリンクのままです！ また、ブザーはありません。 したがって、タスクはリンクではなく、ディスク内の特定の「ウィンドウ」である必要があります。このウィンドウでは、タスクはファイルのみを表示します。



しかし、「窓」はほんのわずかです。 ユーザーは自分がファイルを添付したことを「記憶」できます。「悪」システム管理者はそれを静かにディスクから削除し、ユーザーにクレイジーだと伝えます。 そのため、ファイルデータは削除できますが、ファイルがあった記録はビンのどこかに残り、「ウィンドウ」ではリンクが灰色の非アクティブな色で表示されたままになります。



例として「タスク」を引用しましたが、同様にファイルをプロジェクト、請負業者、従業員、オブジェクトなどに適用できます。 つまり システムはユニバーサルでなければなりません。



しかし、それだけではありません。 たとえば、顧客は、たとえば請求書が添付される領域とドキュメントが添付される領域など、2つのファイルアプリケーション領域を取引相手に単に持たせたい場合があります。 つまり これらの「ウィンドウ」は、ページとその入力データだけでなく、ページの特定の要素にも添付する必要があります。



要点をまとめると、 ファイルシステムは外部システムから「ウィンドウ」をサポートする必要があります。 各「ウィンドウ」には、そのフレームワーク内のファイルを操作する機能が必要です。



3）ユーザーは、そのようなカウンターパーティまたはそのようなプロジェクトに添付されたフォルダー内のファイルを見つける必要がある場合があります。または、他の理由により、これらのファイルの呼び出し方法は関係ありません。 つまり ファイル名だけでなく、外部構造への所属によっても特定の検索システムが必要です。



PS：私の意見では、そのようなことはハッシュタグを使用して最適に実装されます。 これらの目的のために、ファイルには、「システムハッシュタグ」と「カスタムハッシュタグ」というプロパティをさらに入力できます。 システム名は、取引先の名前など、システムに書き込まれます。 ユーザー-ファイルが添付されたとき、ユーザーが任意に。



4） アクセス権 。 もちろん、誰かが特定のフォルダを表示する権利を持っている必要があります。 追加、削除する権利。 または、ユーザーは、タスクとそれに添付されているファイル、およびこれらのアクセスファイルが含まれてはならないフォルダーにアクセスする必要がある場合があります。 つまり 「ウィンドウ」にはその権利が必要です。 システム管理者には、特定のユーザーにアクセス権を割り当てたり削除したりするメカニズムが必要です。



これらは、ファイルシステムの構造に対する結果の要件です。



これらすべての実装は、スクリプトおよびデータベース構造内のかなり複雑で分岐の多いコードであるため、この記事のフレームワーク内で引用することはできません。 そして、すでに非常に大きな記事が取得されています。

各タスクを実装するための基本原則を説明します。



ディレクトリ構造は簡単に管理できます。 これは、企業データベース内の次の単純なテーブルです。



1）フォルダー名

2）フォルダ作成者

3）このフォルダーが置かれているフォルダーのノード

4）フォルダーの状態

5）フォルダーID

6）デフォルトフォルダに対する一般的な権利（特別な権利が付与されていない場合、すべてのユーザーがフォルダ内で実行できる）



各アイテムの詳細：



1）フォルダーの名前は、ツリーのさまざまなレベルで、さまざまなノードに複製できます。 1つのノードで、フォルダー名を複製することはできません。 このメカニズムの実装は非常に簡単で、テーブルのフィールド1と3に一意のインデックスを置くだけです。 1つのノードで名前を複製すると、エラーが発生します。



2）フォルダーの作成者を記録する必要があります。 フォルダーの作成者は、ユーザーとして管理者によって特に指定されない限り、常にそのフォルダーに対する完全な権限を持ちます。 たとえば、ユーザーがフォルダを作成した場合でも、システム管理者はロールに適切なエントリを作成することにより、フォルダへのアクセスを閉じることができます。



フォルダーの作成者は、他のユーザーにデフォルトの権限を設定できます。 つまり 他のユーザーがフォルダを見るか、読み取り専用でファイルを見ることができるか、削除するか、ユーザーのハッシュタグを変更するかなど 繰り返しますが、これらの設定はシステム管理者によってブロックされる場合があります。



3）他のフォルダーのノードは、そのフォルダーに登録されます。 これは、フォルダのツリーシステムを構築するために必要です。



4）フォルダーのステータス。 フォルダーが機能しているか、削除されている可能性があります。 質問は本当に簡単ではありません。 ここでは、各開発者が自分で何をするかを決定できます。たとえば、「ごみ箱」サービスフォルダーを整理します。このフォルダーには、ステータスが削除されたフォルダーが表示されます。 本当に削除することができますが、システム構造内のフォルダー接続だけでなく、フォルダー内のファイルをどうするかを考える必要があります。 私の意見では、正しい決定は、システムにリンクがあり、その中にいくつかのファイルがある間、フォルダエントリを物理的に削除しないことです。 ファイルをクリーンアップし、接続をクリーンアップし、その後削除してください。 そうしないと、依存モジュールでグリッチが発生する可能性があります。



5）各フォルダーには独自の識別子が必要です。 異なるノードの異なるフォルダの名前は重複する場合がありますが、識別子は重複しない場合があります。 システムをプログラミングするとき、ユーザーがWebページでFile要素を作成するとき、ユーザーは常にこの要素のフォルダー識別子を示します。システムはこの要素を通してこのモジュールに適用されたファイルを保存します。



6）デフォルトのフォルダー許可。 ユーザーがフォルダーを表示するとき、システムは最初にこのフォルダーのエントリをユーザーとしてチェックする必要があります。少なくともいくつかの権限設定がある場合（すべてに対する権限、またはその逆）、何も書かれていない場合、これらのルールを適用する必要があります-その後フォルダの作成者が設定したルールを入力する必要があります。

私の開発では、フォルダーの権利システムを一般的な権利システムに統合し、フォルダーをユーザーロールに追加しても会社の管理者に問題が発生することはありません（例として、システム要素へのアクセス権の実装はここで読むことができます ）。



ファイルをページ要素にリンクするためのエレガントなソリューションがあります。

ハッシュ、ページ要素の一意の識別子が必要な量、およびページデータ（プロジェクト番号やタスク番号など）を計算する必要があります。このハッシュは常に一意であり、ファイルデータレコードに保存する必要があります。 「ウィンドウ」が表示された時点でページがロードされると、このリンクハッシュが計算され、ファイルが検索され、リストがページに表示されます。



また、「ウィンドウ」は、ファイルを新しいファイルに格納するディレクトリを知っている必要があります。



ファイルのハッシュタグエントリ。カスタム（任意）ハッシュタグには問題はありません;ファイルを追加するとき（または編集するとき）に、ユーザーがファイルにメモを追加できるようにする必要があります。



システムハッシュタグではより複雑です。たとえば、タスクに追加する各ファイルには、タグ「＃Task No. ...＃」を配置する必要があります。次に、タスクフォルダーで、ユーザーが検索バーに「No. ...＃」などを入力すると、目的のタスクのすべてのファイルが受信されます。この機能をプログラミング言語のレベルで、「ファイル」フォームの要素のプロパティに実装しています（記事では「ウィンドウ」と呼びます）。そのプロパティでは、識別子要素を含む文字列を指定し、これらの要素を必要なデータソースに関連付けることができます。システムの残りの部分は自動的に構築されます。



また、愉快なボーナスとして、ブロブフィールドを使用したファイルゲームの特別なケースである画像ストレージシステムを検討することができます。



ある時点で、内部プログラミング言語を開発する際に、非標準のデータ型を導入する必要に直面しました。整数、varchar、タイムスタンプなど、さまざまなデータ型があります。ただし、データベースにはイメージタイプはありません。そして、あなたはそれを必要とします。たとえば、データが移動する、データを削除するなどの上向き矢印、下向き矢印など、画像があるテーブルを表示して表示するように要求すると非常に便利です。これはすべてデータベース内にあり、基本レベルで処理され、ユーザーインターフェイスで毎回何かをブロックしないようにするためです。たとえば、ここではそのようなものを1つのリクエストで表示できます。







これは、blobフィールドを使用することで可能になります。たとえば、ファイルストレージテーブルに加えて、クライアントのファイルデータベースに、IMGテーブルを作成し、そこに画像ストレージを整理できます。物理レベルでは、このタイプのデータベースには、画像識別子のみが保存されます。データがページに出力されると、この識別子によって画像データタイプに適合したインタープリタースクリプトがファイルデータベースに移動し、blobフィールドから画像を表示します。同時に、ユーザーはこのすべての内部キッチンを見ることができません。これは、プロシージャの出力でイメージタイプのパラメータを単に示し、このパラメータにイメージタイプのテーブルフィールドを表示するプロシージャで要求を行います。非常に便利なメカニズム。



これでデータベースサイクルの終わりです。



記事で説明されているメカニズムを改善するための提案がある場合、または同様の機能を持つファイルを保存する別の構成がある場合は、コメントを書いてください。