I dati statici devono essere archiviati in un database o altrove?

Sto lavorando su alcuni software in quel momento e non sono sicuro di quale percorso prendere con questo. Ho alcuni dati da archiviare da qualche parte su un dispositivo mobile. I dati non cambieranno mai, hanno una relazione gerarchica e verranno utilizzati per popolare il display. C'è una quantità ragionevole di questi dati.

Ho le seguenti opzioni:

1. Un insieme di enumerazioni / oggetti
2. Un file XML
3. Il database SQLite incorporato

In questo caso particolare penso che l'opzione enums sia il minimo lavoro, ma ho un odore dai dati incorporati nel codice in quel modo.

Il file XML ha più senso secondo me, ma analizzarlo sarà un successo di risorse che sembra uno spreco poiché non cambierà mai.

Il database dovrebbe fornire un impatto negativo sulle prestazioni, ma sembra eccessivo per i dati statici.

Qual è il percorso di progettazione corretto qui?

Nota: per "Mai" il cambiamento intendo che raramente cambierà. I dati in questione sono un modello di una serie di standard governativi, quindi potrebbero cambiare a un certo punto in futuro, ma non saranno regolarmente e non aggiorneranno automaticamente il nostro software in quanto un cambiamento degli standard potrebbe benissimo innescare un cambiamento nei nostri requisiti.

Vorrei usare un oggetto per questo.

Hai detto che i dati non cambieranno mai, quindi puoi facilmente memorizzarli nell'applicazione. Il database sarebbe eccessivo e aumenterebbe la dimensione.
Il file XML sarebbe un po 'eccessivo e aumenterebbe anche le dimensioni.

Quindi secondo me l'opzione migliore sarebbe un enum o un oggetto.

non cambierà mai o cambierà? Questa è la domanda a cui devi veramente rispondere prima di ottenere una buona risposta.

I dati statici che non cambiano mai (ad esempio i nomi dei giorni della settimana) vanno bene nel codice;

Anche i dati che non cambiano praticamente mai (ad es. Il nome del tuo server dns) vanno bene nel codice, se devono essere modificati, è così raro che un aggiornamento del codice è ok.

I dati che non cambiano, ma che potrebbero (ad esempio un ritardo tra gli aggiornamenti periodici) sono probabilmente i migliori in una posizione facilmente modificabile, come un archivio di configurazione locale (sqlite o xml, non fa alcuna differenza)

L'archiviazione non è un problema: se non cambia mai o quasi mai, è possibile leggere tutto all'avvio del programma e memorizzarlo nella cache come dati del programma. Se, nel caso improbabile in cui debba mai cambiare, il riavvio dell'app non è un grosso problema.

Di solito le cose che "non cambiano mai" sono le prime a cambiare ...
Sia che tu utilizzi un database o qualche altro sistema esterno (come un file di configurazione) importa poco, purché sia ​​possibile accedervi facilmente e rapidamente quando necessario.
Tendo a utilizzare una tabella di database se ho già un database comunque, e ha senso (supponiamo che i dati debbano essere eventualmente modificati da persone che non hanno accesso al filesystem al server su cui è distribuita l'applicazione o che gira su più macchine e la configurazione deve essere sincronizzata tra loro).
Naturalmente un database non può contenere tutto. Le credenziali del database, ad esempio, dovranno essere archiviate altrove, molto probabilmente un file di configurazione.

La domanda da porre per qualsiasi dato non è se cambierà; probabilmente non lo sai, e anche se lo facessi, la risposta sarebbe probabilmente fuorviante.

La domanda da porsi è, quando cambia, chi dovrebbe cambiarla:

• l'autore del software: inseriscilo nel codice
• l'utente finale: ha un'opzione sulla GUI
• qualcun altro (ad es. un integratore di sistema, un servizio di internazionalizzazione, ecc.): tabella di database, file o qualsiasi altra cosa abbia senso (inclusa talvolta un'API di estensione).

Il martedì dovrebbe essere generalmente un enum non perché non può mai cambiare. Ma perché se un pazzo dittatore prendesse il comando e chiedesse che il martedì venisse nominato come lui, tu come autore del software dovrai cambiarlo (o essere nutrito con gli squali).

Non vorresti che tutti i tuoi utenti dovessero andare a scavare in file di configurazione o oscurare le tabelle del database per evitare quel destino ...

È possibile che i "tuoi" dati debbano essere modificati anche se le entità che i dati rappresentano nel mondo reale potrebbero non cambiare. Devi decidere se vale la pena includere un file di testo separato di qualche tipo che può essere aggiornato senza aggiornare l'intera app.

Esempi:

1. Errore tipografico / errore di ortografia.
2. Omissione accidentale.
3. Offri i dati in un'altra lingua.
4. Offri all'utente la possibilità di apportare le proprie modifiche.

Qualsiasi altro tipo di modifica della struttura dei dati avrà probabilmente bisogno di un aggiornamento dell'app, quindi non è un vantaggio.

Inizialmente ho scritto questa risposta per questa domanda su StackOverflow , ma penso che la stessa risposta si applichi anche a questa domanda.

C'è un articolo di Mathias Verraes che parla del tuo problema qui . Parla della separazione degli oggetti valore nel modello dai concetti che servono l'interfaccia utente.

Citando l'articolo quando viene chiesto se modellare Paesi come entità o oggetti valore:

Non c'è nulla di intrinsecamente sbagliato nel modellare i paesi come entità e memorizzarli nel database. Ma nella maggior parte dei casi, ciò semplifica le cose. I paesi non cambiano spesso. Quando il nome di un paese cambia, in effetti è, a tutti gli effetti pratici, un nuovo paese. Se un giorno un paese non esiste più, non puoi semplicemente cambiare tutti gli indirizzi, perché probabilmente il paese è stato diviso in due paesi.

Ha suggerito un approccio diverso per introdurre un nuovo concetto chiamato AvailableCountry:

Questi paesi disponibili possono essere entità in un database, record in un codice JSON o anche semplicemente un elenco codificato nel codice. (Dipende dal fatto che l'azienda desideri un facile accesso ad essi tramite un'interfaccia utente.)

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

Quindi sembra che esista una terza soluzione che consiste nel modellare le tabelle di ricerca come oggetti valore ed entità.

A proposito, assicurati di controllare la sezione dei commenti per alcune discussioni serie sull'articolo.

Cose da considerare:

• Quanto sono statici i dati? Se non cambierà mai, allora dovrebbe vivere nell'oggetto. Per modificare i dati, potrebbe essere necessario ricompilare e ridistribuire. Sei contento di fare una riassegnazione per un cambiamento minore?

• Se si tratta di un'applicazione Web e ce l'hai come parte di web.config, sei soddisfatto del riavvio dell'applicazione quando apporti modifiche a tali dati?

• Se lo si inserisce in un database, è sempre possibile memorizzarlo nella cache sul lato client (applicazione desktop) o sul lato server (servizio o sito Web). Database potrebbe essere una buona soluzione IMO.