Os dados estáticos devem ser armazenados em um banco de dados ou em outro local?

Estou trabalhando em algum software no momento e não tenho certeza de qual caminho seguir com isso. Eu tenho alguns dados para armazenar em algum lugar em um dispositivo móvel. Os dados nunca serão alterados e têm um relacionamento hierárquico e serão usados ​​para preencher a exibição. Há uma quantidade razoável desses dados.

Eu tenho as seguintes opções:

1. Um conjunto de enums / objetos
2. Um arquivo XML
3. O banco de dados SQLite incorporado

Nesse caso em particular, acho que a opção enums é o menos trabalhoso, mas sinto o cheiro dos dados sendo incorporados no código dessa maneira.

O arquivo XML faz mais sentido, mas analisá-lo será um acerto de recursos que parece um desperdício, pois 'nunca' mudará.

O banco de dados deve fornecer menos resultados de desempenho, mas parece um exagero para dados estáticos.

Qual é o caminho de design correto aqui?

Nota: Por "Nunca" mude, quero dizer que raramente mudará. Os dados em questão são um modelo de um conjunto de padrões governamentais, portanto podem ser alterados em algum momento no futuro, mas não serão regulares e não serão atualizados automaticamente nosso software, pois uma mudança nos padrões pode muito bem desencadear uma alteração em nossos requisitos.

Eu usaria um objeto para isso.

Você disse que os dados nunca serão alterados, para que você possa armazená-los facilmente no aplicativo. O banco de dados seria um exagero e aumentaria o tamanho.
O arquivo XML também seria um exagero e também aumenta o tamanho.

Então, na minha opinião, a melhor opção seria uma enumeração ou objeto.

isso nunca vai mudar ou vai mudar? Essa é a pergunta que você realmente precisa responder antes de obter uma boa resposta.

Dados estáticos que nunca mudam (por exemplo, nomes de dias da semana) são bons para inserir no código;

Dados que praticamente nunca mudam (por exemplo, o nome do DNS do servidor) também são bons para digitar o código, se precisar ser alterado, é tão raro que uma atualização de código seja aceitável.

Dados que não mudam, mas que podem (por exemplo, atraso de tempo entre atualizações periódicas) provavelmente são os melhores em um local facilmente alterado, como em um armazenamento de configuração local (sqlite ou xml, não faz diferença real)

O armazenamento é pouco preocupante - se ele nunca ou quase nunca mudar, você poderá ler tudo no início do programa e armazená-lo em cache como dados do programa. Se, no caso improvável, ele precisar mudar, uma reinicialização do aplicativo não será tão importante.

Geralmente, as coisas que "nunca mudam" são as primeiras a mudar ...
Se você usa um banco de dados ou outro sistema externo (como um arquivo de configuração) pouco importa, desde que possa ser acessado com facilidade e rapidez quando necessário.
Costumo usar uma tabela de banco de dados se já tiver um banco de dados, e isso faz sentido (digamos que os dados precisem ser alterados por pessoas que não têm acesso do sistema de arquivos ao servidor no qual o aplicativo está implantado ou é executado em várias máquinas e a configuração precisa ser mantida em sincronia entre eles).
É claro que um banco de dados não pode conter tudo. As credenciais do banco de dados, por exemplo, precisarão ser armazenadas em outro local, provavelmente um arquivo de configuração.

A questão para solicitar quaisquer dados não é se eles serão alterados; você provavelmente não sabe, e mesmo se soubesse, a resposta provavelmente seria enganosa.

A pergunta a fazer é, quando muda, quem deve mudar:

• o autor do software: coloque-o no código
• o usuário final: tenha uma opção na GUI
• outra pessoa (por exemplo, um integrador de sistemas, serviço de internacionalização, etc.): tabela, arquivo de banco de dados ou qualquer outra coisa que faça sentido (incluindo algumas vezes uma API de extensão).

Terça-feira geralmente deve ser um enum, não porque nunca pode mudar. Mas porque se um ditador insano assumiu o comando e exigiu o nome na terça-feira, você, como autor do software, precisará alterá-lo (ou ser alimentado aos tubarões).

Você não gostaria que todos os seus usuários tivessem que procurar em arquivos de configuração ou ocultar tabelas de banco de dados para evitar esse destino ...

Há uma chance de que "seus" dados precisem ser alterados, mesmo que as entidades que eles representam no mundo real talvez não. Você precisa decidir se vale a pena incluir um arquivo de texto separado de algum tipo que possa ser atualizado sem atualizar o aplicativo inteiro.

Exemplos:

1. Erro tipográfico / erro de ortografia.
2. Omissão acidental.
3. Ofereça os dados em outro idioma.
4. Ofereça uma maneira de o usuário fazer suas próprias alterações.

Qualquer outro tipo de alteração na estrutura de dados provavelmente precisará de uma atualização para o aplicativo, portanto não há benefício.

Originalmente, escrevi esta resposta para esta pergunta no stackoverflow , mas acho que a mesma resposta também se aplica a essa pergunta.

Há um artigo de Mathias Verraes que fala sobre seu problema aqui . Ele fala sobre como separar objetos de valor no modelo de conceitos que atendem à interface do usuário.

Citando o artigo quando perguntado se deseja modelar os países como entidades ou objeto de valor:

Não há nada intrinsecamente errado em modelar países como entidades e armazená-los no banco de dados. Mas na maioria dos casos, isso complica demais as coisas. Os países não mudam frequentemente. Quando o nome de um país muda, é de fato, para todos os efeitos práticos, um novo país. Se um país um dia não existir mais, você não poderá simplesmente mudar todos os endereços, porque possivelmente o país foi dividido em dois países.

Ele sugeriu uma abordagem diferente para introduzir um novo conceito chamado AvailableCountry:

Esses países disponíveis podem ser entidades em um banco de dados, registros em um JSON ou até simplesmente uma lista codificada no código. (Isso depende se a empresa deseja acesso fácil a eles por meio de uma interface do usuário.)

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

Portanto, parece que existe uma terceira solução que é modelar tabelas de pesquisa como objetos e entidades de valor.

Entre, verifique a seção de comentários para ver algumas discussões sérias sobre o artigo.

Coisas a considerar:

• Quão estáticos são os dados? Se isso nunca mudar, deve viver no objeto. Para alterar os dados, pode ser necessário recompilar e reimplementar. Você está satisfeito em fazer uma reimplantação para uma pequena alteração?

• Se for um aplicativo Web e você o tiver como parte do web.config, ficará satisfeito com a reinicialização do aplicativo ao fazer alterações nesses dados?

• Se você o colocar em um banco de dados, sempre poderá armazená-lo em cache no lado do cliente (aplicativo de desktop) ou no servidor (serviço ou site). O banco de dados pode ser uma boa solução IMO.