Percorsi file con codifica hard - Soluzione?

6

Supponiamo che tu abbia un'applicazione che salva i file immagine (.jpg, .png ecc.) e di testo (.txt, .xml), e che l'applicazione abbia tutti i percorsi dei file codificati nel codice, come nell'esempio seguente.

Supponendo che la seguente struttura del percorso del file esista:

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

I file nei percorsi dei file di destinazione sono referenziati all'interno di una tabella, quindi in un esempio VBA il percorso del file sarebbe codificato come:

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 

Ora dì che devo dividere \MyFileServer in \MyMediaFileServer e \MyTextFileServer

Ciò che sarebbe stato l'ideale è che se avessi una posizione centrale avrei potuto semplicemente modificare un valore di tabella o una variabile, piuttosto che arrancare attraverso ogni singola funzione nell'applicazione per aggiornare il percorso codificato. Solo per cambiarlo di nuovo in futuro, se la situazione si ripresenta. Quindi, il mio obiettivo è di assicurarmi che l'immagine dei miei cuccioli possa essere mostrata con il minimo sforzo.

Riguardo allo standard del settore, mi chiedevo quale sia l'opzione migliore, sia che si tratti delle mie due opzioni in basso o di un'altra opzione separata.

Opzione 1:

Tabella referenziale singolo:

Definito nella risposta di Mike al database gerarchico / albero per le directory nel filesystem da una struttura gerarchica come la seguente:

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

Hai semplicemente una tabella come la seguente:

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

OPPURE Opzione 2: Tabella di riferimento automatico con radici principali:

Una leggera deviazione sull'opzione 1.

Forse un percorso del file master sarebbe più chiaro. Dove c'è una tabella separata.

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

Quindi nella struttura menzionata nell'opzione 1.

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

Ritengo che l'opzione 1 sia in generale più semplice da modificare, ma diventerà più confusa man mano che un albero si espande e l'opzione 2 consente una più semplice modifica del percorso del file. Opzione 1 IS la soluzione migliore per archiviare percorsi di file o esiste un altro standard di settore di cui non sono a conoscenza?

    
posta Elias 29.01.2015 - 22:13
fonte

2 risposte

10

Entrambe le opzioni sono eccessivamente ingegnerizzate, il che implica che il database non è appropriato e la struttura della directory è troppo profonda.

Invece, per il software amico dell'amministratore, vedo emergere i seguenti schemi:

  1. I percorsi sono configurati nei file di configurazione, non nel database.

    Di solito, vuoi essere in grado di copiare il dump del database su un altro sistema. Spesso, il server di database si trova su un altro sistema. Semplicemente non ti aspetti che il contenuto del database sia impigliato con i dettagli del file system, l'unica eccezione sono i percorsi strettamente relativi. Infine, dover apportare modifiche alla configurazione in un database è un problema.

  2. C'è solo una directory di dati da configurare, se esiste.

    Questo dipende dall'applicazione, ovviamente, ma quasi sempre vuoi avere tutto in una singola directory. Quindi l'applicazione, non il file di configurazione, si prende cura della sua struttura interna. Nel tuo caso, tutto ciò che voglio configurare è:

    \MyFileServer

    Un altro approccio comune non è di configurarlo affatto, ma in una sottodirectory ben definita. Questo è all'interno della directory HOME dell'utente o all'interno di una directory di dati di applicazioni generiche (diverse convenzioni su diversi sistemi operativi, ma questo è un altro argomento).

    Se vuoi un altro posto, semplicemente sostituisci quella directory con un link simbolico, come ad esempio:

    {...}\Data -> \MyFileServer

  3. La struttura interna della directory dei dati è gestita per origine.

    Le buone applicazioni hanno funzioni interne o tabelle delle proprietà per tutte le directory comuni, di solito tutti combinati in una singola classe o modulo.

    La base è qualcosa come getRootPath() che legge il file di configurazione e restituisce qualcosa come \MyFileServer .

    Quindi, funziona come getMediaPath() o getTextPath() che internamente chiamano solo getRootPath() (o l'un l'altro) e aggiungi il loro percorso relativo.

    Una variazione comune dal tema è quella di lasciare quelle funzioni prendere un nome file (o percorso file relativo) come argomento, e per restituire il percorso completo di quel file. Ad esempio, getMediaPath("great.jpg") restituirebbe \MyFileServer\Media\great.jpg .

    Idealmente, queste funzioni creano anche la directory se non esiste ancora. Un altro approccio è quello di creare ogni directory solo quando il primo file è scritto su di esso In entrambi i casi, il punto non è quello di aspettarsi una struttura di directory completamente popolata, che è una cosa in meno che l'amministratore (o l'installer) potrebbe sbagliare.

    Se una versione futura dell'applicazione richiede altre sottodirectory, di solito crea solo quelli, senza dare fastidio all'amministratore di crearli, o per costringerli ad aggiungere quei percorsi a un file di configurazione, o qualsiasi altro stupido fastidio. (vedi 2: c'è solo una directory di dati)

  4. Le strutture delle directory non sono più profonde del necessario.

    La struttura della directory è essenzialmente suddivisa per estensione del file.

    • {YourRoot}\Media\jpg\great.jpg
    • {YourRoot}\Media\png\great.png
    • {YourRoot}\Text\txt\great.txt
    • {YourRoot}\Text\xml\great.xml

    È davvero necessario? I file sono già determinati in modo univoco dalla loro estensione, quindi perché non saltare quei percorsi intermedi?

    • {YourRoot}\great.jpg
    • {YourRoot}\great.png
    • {YourRoot}\great.txt
    • {YourRoot}\great.xml

    Naturalmente, le applicazioni hanno buone ragioni per strutturare la directory dei dati. Ma di solito è una separazione per uso (o scopo), non solo per estensione del file.

  5. Se devi, dividi in modo uniforme.

    Le uniche ragioni per dividere ulteriormente le directory è se diventano troppo grandi. In tal caso, non si divide ancora per estensione di file, ma per qualcosa che fornisce una partizione uniforme.

    Spesso, questo è basato sul tempo, ad es. giornaliera o mensile:

    • {YourRoot}15-01\great.jpg
    • {YourRoot}15-01\stuff.png
    • ...
    • {YourRoot}15-02\others.jpg
    • ...

    Se hai nomi di file uniformi (ad es. hash), il loro prefisso viene spesso scelto come nome della sottodirectory (e taglia dal nome del file originale), come ad esempio:

    • {YourRoot}567.jpg
    • ...
    • {YourRoot}577.png
    • ...
risposta data 04.02.2015 - 10:07
fonte
0

L'opzione 1 è decisamente esagerata.

La risposta di Mike è fantastica, se vuoi memorizzare i dati relativi alle directory e alla loro struttura. Ma non è quello che ti serve qui. Non ti interessa davvero la gerarchia delle cartelle e le relazioni tra loro. Vuoi solo sapere quali sono i percorsi.

È possibile ottenere questi parametri da un file config / ini o da una tabella (come descritto in Opzione 2 ). Trovo che i file di configurazione siano più popolari, ma ci sono vantaggi per entrambi i metodi. Puoi trovare una buona discussione di questi nella risposta di Scriptin a Devo usare un file di configurazione o un database per memorizzare le regole di business?

    
risposta data 04.02.2015 - 09:32
fonte