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

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 le dimensioni.
Anche il file XML sarebbe un po 'eccessivo e aumenterebbe anche la dimensione.

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

non cambierà mai, o cambierà? Questa è la domanda alla quale devi rispondere prima di ottenere una buona risposta.

I dati statici che non cambiano mai (es. i nomi dei giorni della settimana) sono validi per andare nel codice;

I dati che non cambiano praticamente mai (ad esempio il nome DNS del tuo server) è anche buono da inserire nel codice, se è necessario cambiarlo, è così raro che un aggiornamento del codice sia ok.

Dati che non cambiano, ma potrebbero (ad esempio il ritardo temporale tra gli aggiornamenti periodici) è probabilmente il migliore in una posizione facilmente modificata, come un archivio di configurazione locale (sqlite o xml, non fa alcuna differenza)

Lo storage è di scarsa importanza: se non cambia mai o quasi mai, puoi leggerlo tutto all'avvio del programma e metterlo in cache come dati del programma. Se, nel caso improbabile dovesse mai cambiare, il riavvio dell'app non è un grosso problema.

Di solito le cose che "non cambiano" sono le prime a cambiare ...
Che si utilizzi un database o qualche altro sistema esterno (come un file di configurazione) importa poco, purché sia facilmente e rapidamente accessibile quando necessario.
Tendo ad usare una tabella di database se ho già un database in ogni caso, e ha senso (ad esempio, è possibile che i dati vengano modificati da persone che non hanno accesso al filesystem al server in cui è distribuita l'applicazione o che funziona su più macchine e la configurazione deve essere mantenuta in sincronia tra loro).
Ovviamente un database non può contenere tutto. Ad esempio, le credenziali del database dovranno essere archiviate altrove, molto probabilmente un file di configurazione.

La domanda per chiedere dati non è se cambierà; probabilmente non lo sai, e anche se lo facessi, probabilmente la risposta sarebbe fuorviante.

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

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

Il martedì dovrebbe essere generalmente un enum non perché non possa mai cambiare. Ma perché se un folle dittatore ha preso il comando e chiede a Martedì di essere chiamato con lui, tu come autore del software dovresti cambiarlo (o essere nutrito con gli squali).

Non vorrai che tutti i tuoi utenti debbano scavare nei file di configurazione o oscurare le tabelle del database per evitare quel destino ...

C'è la possibilità che i "tuoi" dati possano dover cambiare anche se le entità che i dati rappresentano nel mondo reale potrebbero non esserlo. 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 ortografico.
2. Omissione accidentale
3. Offri i dati in un'altra lingua.
4. Offri un modo per consentire all'utente di apportare le proprie modifiche.

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

Originariamente ho scritto questa risposta per questa domanda su stackoverflow , ma penso che la stessa risposta valga anche per 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 dall'articolo quando è stato chiesto se modellare Paesi come entità o oggetto valore:

There’s nothing intrinsically wrong with modelling countries as entities and storing them in the database. But in most cases, that overcomplicating things. Countries don’t change often. When a country’s name changes, it is in fact, for all practical purposes, a new country. If a country one day does not exist anymore, you can’t simply change all addresses, because possibly the country was split into two countries.

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

These available countries can be entities in a database, records in a JSON, or even simply a hardcoded list in your code. (That depends on whether the business wants easy access to them through a UI.)

<?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 ci sia una terza soluzione che deve modellare le tabelle di ricerca sia come oggetti valore sia come entità.

BTW 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 eseguire una ridistribuzione per un piccolo cambiamento?

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

• Se lo inserisci in un database, puoi sempre memorizzarlo nella cache sul lato client (applicazione desktop) o lato server (servizio o sito Web). Il database potrebbe essere una buona soluzione IMO.