¿Deben almacenarse los datos estáticos en una base de datos o en otro lugar?

Estoy trabajando en algún software en ese momento y no estoy seguro de qué ruta tomar con esto. Tengo algunos datos para almacenar en algún lugar en un dispositivo móvil. Los datos nunca cambiarán, y tienen una relación jerárquica, y se usarán para llenar la pantalla. Hay una cantidad razonable de estos datos.

Tengo las siguientes opciones:

1. Un conjunto de enumeraciones / objetos
2. Un archivo XML
3. La base de datos SQLite incrustada

En este caso en particular, creo que la opción de enumeración es la que menos trabajo, pero me huelen los datos que se incrustan en el código de esa manera.

Creo que el archivo XML tiene más sentido, pero analizarlo será un éxito de recursos que parece un desperdicio ya que 'nunca' cambiará.

La base de datos debería proporcionar un impacto menor en el rendimiento, pero parece excesivo para los datos estáticos.

¿Cuál es la ruta de diseño correcta aquí?

Nota: Por "Nunca" cambio quiero decir que rara vez cambiará. Los datos en cuestión son un modelo de un conjunto de estándares gubernamentales, por lo que bien pueden cambiar en algún momento en el futuro, pero no será regular y tampoco actualizará automáticamente nuestro software, ya que un cambio en los estándares podría desencadenar un cambio en nuestros requisitos.

Yo usaría un objeto para esto.

Dijiste que los datos nunca cambiarán, por lo que puedes almacenarlos fácilmente en la aplicación. La base de datos sería exagerada y aumentaría el tamaño.
El archivo XML también sería un poco excesivo y también aumenta el tamaño.

Entonces, en mi opinión, la mejor opción sería una enumeración u objeto.

¿Nunca cambiará o cambiará? Esa es la pregunta que realmente tiene que responder antes de obtener una buena respuesta.

Los datos estáticos que nunca cambian (por ejemplo, nombres de días de la semana) son buenos para ir en código;

Los datos que prácticamente nunca cambian (por ejemplo, el nombre de su servidor DNS) también son buenos para ir en código, si es necesario cambiar, es tan raro que una actualización de código está bien.

Los datos que no cambian, pero que pueden (por ejemplo, un retraso de tiempo entre actualizaciones periódicas) probablemente sean mejores en una ubicación que se pueda cambiar fácilmente, como un almacén de configuración local (sqlite o xml, no hace una diferencia real)

El almacenamiento es poco preocupante: si nunca o casi nunca cambia, puede leerlo todo al inicio del programa y almacenarlo en caché como datos del programa. Si, en el improbable caso de que alguna vez necesite cambiar, un reinicio de la aplicación no es tan importante.

Por lo general, las cosas que "nunca cambian" son las primeras en cambiar ...
Ya sea que use una base de datos o algún otro sistema externo (como un archivo de configuración) importa poco, siempre que pueda accederse fácil y rápidamente cuando sea necesario.
Tiendo a usar una tabla de base de datos si ya tengo una base de datos de todos modos, y tiene sentido (digamos que los datos posiblemente deben ser cambiados por personas que no tienen acceso al sistema de archivos en el servidor en el que se implementa la aplicación, o se ejecuta en varias máquinas y la configuración debe mantenerse sincronizada entre ellos).
Por supuesto, una base de datos no puede contener todo. Las credenciales de la base de datos, por ejemplo, deberán almacenarse en otro lugar, probablemente un archivo de configuración.

La pregunta para preguntar por cualquier dato no es si cambiará; probablemente no lo sepas, e incluso si lo supieras, la respuesta probablemente sería engañosa.

La pregunta que debe hacerse es, cuando cambia, quién debería cambiarla:

• el autor del software: ponlo en código
• el usuario final: tenga una opción en la GUI
• alguien más (por ejemplo, un integrador de sistemas, servicio de internacionalización, etc.): tabla de base de datos, archivo o lo que tenga sentido (incluso a veces una API de extensión).

El martes generalmente debería ser una enumeración, no porque nunca pueda cambiar. Pero porque si un dictador loco se hizo cargo y exigió que el martes llevara su nombre, usted como autor del software tendrá que cambiarlo (o ser alimentado por los tiburones).

No querrás que todos tus usuarios tengan que buscar en los archivos de configuración u oscurecer las tablas de la base de datos para evitar ese destino ...

Existe la posibilidad de que "sus" datos necesiten cambiar a pesar de que las entidades que los datos representan en el mundo real pueden no tener Debe decidir si vale la pena incluir un archivo de texto separado de algún tipo que pueda actualizarse sin actualizar toda la aplicación.

Ejemplos:

1. Error tipográfico / falta de ortografía.
2. Omisión accidental.
3. Ofrecer los datos en otro idioma.
4. Ofrezca una forma para que el usuario haga sus propios cambios.

Cualquier otro tipo de cambio en la estructura de datos probablemente necesitará una actualización de la aplicación, por lo que no es un beneficio.

Originalmente escribí esta respuesta para esta pregunta en stackoverflow , pero creo que la misma respuesta también se aplica a esta pregunta.

Hay un artículo de Mathias Verraes que habla sobre su problema aquí . Habla sobre la separación de objetos de valor en el modelo de conceptos que sirven a la interfaz de usuario.

Citando el artículo cuando se le preguntó si modelar países como entidades u objetos de valor:

No hay nada intrínsecamente malo en modelar países como entidades y almacenarlos en la base de datos. Pero en la mayoría de los casos, eso complica las cosas. Los países no cambian a menudo. Cuando cambia el nombre de un país, es, de hecho, a todos los efectos prácticos, un nuevo país. Si un país ya no existe algún día, no puede simplemente cambiar todas las direcciones, porque posiblemente el país se dividió en dos países.

Sugirió un enfoque diferente para introducir un nuevo concepto llamado AvailableCountry:

Estos países disponibles pueden ser entidades en una base de datos, registros en un JSON o incluso simplemente una lista codificada en su código. (Eso depende de si la empresa quiere acceder fácilmente a ellos a través de una interfaz de usuario).

<?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];
    }
}

Parece que hay una tercera solución que consiste en modelar tablas de búsqueda como objetos de valor y entidades.

Por cierto, asegúrese de consultar la sección de comentarios para algunas discusiones serias sobre el artículo.

Cosas para considerar:

• ¿Qué tan estáticos son los datos? Si nunca cambia, entonces debería vivir en el objeto. Para cambiar los datos, es posible que deba volver a compilar y volver a implementar. ¿Está contento con hacer una redistribución para un cambio menor?

• Si es una aplicación web y la tiene como parte de web.config, ¿está contento con el reinicio de la aplicación cuando realiza cambios en esos datos?

• Si lo coloca en una base de datos, siempre puede almacenarlo en caché en el lado del cliente (aplicación de escritorio) o del lado del servidor (servicio o sitio web). La base de datos podría ser una buena solución de la OMI.