web-dev-qa-db-ja.com

ハードコードされたファイルパス-解決策?

次の例のように、画像(.jpg、.pngなど)ファイルとテキスト(.txt、.xml)ファイルを保存するアプリケーションがあり、そのアプリケーションには、コード全体にハードコーディングされたすべてのファイルパスがあるとします。

次のファイルパス構造が存在すると仮定します。

  • jpg-\\MyFileServer\Media\jpg\
  • png-\\MyFileServer\Media\png\
  • txt - \\MyFileServer\Text\txt\
  • xml-\\MyFileServer\Text\xml\

宛先ファイルパスのファイルはテーブル内で参照されるため、VBAの例では、ファイルパスは次のようにハードコーディングされます。

Dim myFilePath as String
Dim myFileName as String
myFileName = "puppies.jpg" 'This would be the result of a query in a real scenario
myFilePath = "\\MyFileServer\Media\jpeg\" & myFileName 

今分割する必要があると言います\\MyFileServerから\\MyMediaFileServerおよび\\MyTextFileServer

理想的なのは、ハードコードされたパスを更新するためにアプリケーション内のすべての関数をたどるのではなく、テーブルの値または変数を変更できる中央の場所がある場合です。状況が再び発生した場合は、将来再び変更するだけです。したがって、私の目標は、私の子犬の画像を最小限の労力で表示できるようにすることです。

業界標準に関しては、以下の2つのオプションと別のオプションのどちらが最適なオプションなのか疑問に思いました。

オプション1:

単一の自己参照テーブル:

Mikeの回答 filesystem内のディレクトリの階層/ツリーデータベース で、次のような階層構造によって定義されています。

        (ROOT)
      /        \ 
    Dir2        Dir3
    /    \           \
  Dir4   Dir5        Dir6
  /          
Dir7

次のようなテーブルがあります。

ID  ParentID     FilePath
______________________________________________
1   NULL         \\MyFileServer 
2   1            \Images
3   2            \jpg
4   3            \10 MB Files

またはオプション2:マスタールートを持つ自己参照テーブル:

オプション1のわずかな逸脱。

マスターファイルのパスのほうがわかりやすいでしょう。別のテーブルがあるところ。

ID    Name               FilePath
______________________________________________
1     Image Root         \\MyMediaFileServer\Images
2     Text Root          \\MyTextFileServer\Text

次に、オプション1で述べた構造で。

ID  ParentID    RootID   FilePath
______________________________________________
1   NULL        1        \jpg 
2   1           NULL     \10 MB Files

オプション1の方が全体的に変更が簡単だと思いますが、ツリーが拡大するにつれて混乱しやすくなり、オプション2は絶対的なファイルパスの変更を容易にします。 ISオプション1は、ファイルパスを保存するための最良のソリューションですか、それとも、知らない業界標準がありますか?

6
Elias

どちらのオプションも過度に設計されており、データベースを使用することはここでは不適切であり、ディレクトリ構造が深すぎます。

代わりに、管理者が使いやすいソフトウェアの場合、次のパターンが出現します。

  1. パスはデータベースではなく、構成ファイルで構成されます。

    通常、データベースダンプを別のシステムにコピーできるようにする必要があります。多くの場合、データベースサーバーは別のシステム上にあります。データベースのコンテンツがファイルシステムの詳細に巻き込まれることを期待しないでください。唯一の例外は、厳密な相対パスです。最後に、データベースの構成を変更しなければならないのは面倒です。

  2. 設定するデータディレクトリが1つしかない場合

    もちろん、これはアプリケーションに依存しますが、ほとんどの場合、すべてを1つのディレクトリに配置したいと考えています。次に、設定ファイルではなく、アプリケーションがその内部構造を処理します。あなたの場合、私が設定したいのは次のとおりです:

    _\\MyFileServer_

    別の一般的なアプローチは、それをまったく構成するのではなく、明確に定義されたサブディレクトリに構成することです。これは、ユーザーのHOMEディレクトリ内またはいくつかの一般的なアプリケーションデータディレクトリ内にあります(異なるオペレーティングシステムでは異なる規則ですが、それは別のトピックです)。

    別の場所が必要な場合は、そのディレクトリを次のようなシンボリックリンクに置き換えるだけです。

    _{...}\Data -> \\MyFileServer_

  3. データディレクトリの内部構造はソースによって管理されます。

    優れたアプリケーションには、すべての共通ディレクトリの内部関数またはプロパティテーブルがあり、通常はすべて1つのクラスまたはモジュールにまとめられています。

    ベースはgetRootPath()のようなもので、設定ファイルを読み取って_\\MyFileServer_のようなものを返します。

    次に、getMediaPath()またはgetTextPath()などの関数が内部でgetRootPath()(または相互に)を呼び出し、それらの相対パスを追加します。

    テーマからの一般的なバリエーションは、これらの関数がファイル名(または相対ファイルパス)を引数として取り、そのファイルへのフルパスを返すことです。たとえば、getMediaPath("great.jpg")は_\\MyFileServer\Media\great.jpg_を返します。

    理想的には、これらの関数はディレクトリがまだ存在しない場合は、それも作成します。別のアプローチは、最初のファイルが書き込まれたときにのみ各ディレクトリを作成することです。どちらの場合でも、要点は、完全に設定されたディレクトリ構造を期待しないことです。これは、管理者(またはインストーラー)が誤って行う可能性があることの1つ少ないことです。

    アプリケーションの将来のバージョンでさらにサブディレクトリが必要になった場合、通常は管理者がそれらを作成したり、設定ファイルへのパスの追加や他の愚かな手間を強制したりすることなく、単にそれらを作成します。 (参照2:データディレクトリは1つだけです)

  4. ディレクトリ構造は必要以上に深くありません。

    ディレクトリ構造は、基本的にファイル拡張によって分割されます。

    • _{YourRoot}\Media\jpg\great.jpg_
    • _{YourRoot}\Media\png\great.png_
    • _{YourRoot}\Text\txt\great.txt_
    • _{YourRoot}\Text\xml\great.xml_

    それは本当に必要ですか?ファイルはすでに拡張子によって一意に決定されているので、これらの中間パスをスキップしてみませんか?

    • _{YourRoot}\great.jpg_
    • _{YourRoot}\great.png_
    • _{YourRoot}\great.txt_
    • _{YourRoot}\great.xml_

    もちろん、アプリケーションには、データディレクトリを構造化する十分な理由があります。ただし、これは通常、ファイル拡張子だけではなく、使用法(または目的)による分離です。

  5. 必要に応じて、均等に分割してください。

    ディレクトリをさらに分割する唯一の理由は、ディレクトリが大きくなりすぎる場合です。その場合でも、ファイル拡張子で分割するのではなく、均一なパーティションを提供するもので分割します。

    多くの場合、これは時間ベースです。毎日または毎月:

    • _{YourRoot}\2015-01\great.jpg_
    • _{YourRoot}\2015-01\stuff.png_
    • ...
    • _{YourRoot}\2015-02\others.jpg_
    • ...

    統一されたファイル名(ハッシュなど)がある場合、それらのプレフィックスは、サブディレクトリ名として選択されます(元のファイル名から切り取られます)。

    • _{YourRoot}\12\34567.jpg_
    • ...
    • _{YourRoot}\13\43577.png_
    • ...
10
vog

オプション1 間違いなくやりすぎです。

ディレクトリとその構造に関するデータを保存したい場合、マイクの答えは素晴らしいです。しかし、それはここで必要なものではありません。フォルダー階層とそれらの間の関係については特に気にしません。経路が何であるかを知りたいだけです。

これらのパラメーターは、config/iniファイルまたはテーブルから取得できます( オプション2)。構成ファイルの方が人気があるようですが、どちらの方法にも利点があります。これらについての良い議論は、Scriptinの回答 ビジネスルールの保存に構成ファイルまたはデータベースを使用する必要がありますか?

0
Zackie