Quando um código físico codifica valores reais para o código, em vez de usar um banco de dados?

Uma pergunta de longa data para mim tem sido: quando armazeno dados (valores reais) em uma tabela de banco de dados e quando os armazeno diretamente no código?

O consenso incalculável normalmente tem sido assim (*):

Se for uma variável única ou uma estrutura simples, ou uma matriz de alguns valores, coloque os dados diretamente no código.

[* o consenso foi debatido em comentários e respostas, mas basicamente eu queria algum tipo de premissa para iniciar a questão, então fique à vontade para desafiá-la e aprimorá-la ]

Exemplo:

$number = 44;
$colors = array("blue", "yellow", ... "mauve");

Se tiver centenas de linhas de dados do mesmo tipo, use um banco de dados.

Mas parece haver uma área cinzenta; e os casos que não são tão claros? Quais considerações e fatores é preciso prestar atenção para tomar uma decisão?

Exemplo:
digamos que sua empresa use de 10 a 15 tipos diferentes de estruturas de motores que podem ser representadas como "412T". Você tem cerca de 30 deles e eles mudam raramente. Você pode criar uma tabela de banco de dados para eles ou codificá-los em um banco de dados. Nesse caso, os motores são coisas estáticas e físicas que provavelmente não mudam com frequência.

Mantê-los no código os sujeita ao controle de origem, onde, em um banco de dados, as alterações no banco de dados geralmente não são rastreadas. Mas mantê-los em um banco de dados libera (separa) o código dos dados.

Outro exemplo (real) que posso usar é esta minha pergunta: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (atualmente 48 linhas de dados da opção).

Não acho que essas duas declarações realmente representem um consenso sobre quando codificar dados:

Se for uma variável única ou uma estrutura simples, ou uma matriz de alguns valores, coloque os dados diretamente no código

Se tiver centenas de linhas de dados do mesmo tipo, use um banco de dados

Contra-exemplo simples (tenho certeza de que existem outros melhores): as tabelas de sintaxe da linguagem de programação são estruturas grandes e complexas que geralmente são codificadas. Veja um exemplo do código-fonte Perl .

Em vez disso, eu focaria primeiro em perguntar:

• Com que frequência os dados mudam?

• Quem pode precisar mudar isso?

Se a resposta para "com que frequência" é "com mais frequência do que eu quero implantar uma nova versão do meu aplicativo", você não deve codificar os dados.

Se a resposta para "quem o altera" for "alguém além do programador", você não deve codificar os dados.

Em uma pequena loja, é possível que a distinção entre o codificador e o usuário tenha desaparecido, e a ideia de "implantação" também tenha desaparecido. Nesse caso, você é o rei de seu próprio domínio e pode fazer o que quiser.

Mas mesmo nessa situação, a necessidade de colaborar pode surgir, e isso pode ser difícil se um aplicativo personalizado não seguir uma convenção que os programadores normalmente seguem.

Eu iria com a terceira opção: um arquivo de configuração!

Para aplicativos em que trabalho (em Java, todos os meus exemplos são Java + Spring), esses valores geralmente são armazenados em arquivos de configuração e injetados (via Spring) no código necessário quando o aplicativo é iniciado. Em um arquivo de propriedades:

motorFramesString=412T, 413T, ...

Na configuração da primavera:

<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames" value="${motorFrames}"/>
</bean>

A vantagem disso é que você pode alterar ou adicionar mais facilmente esses valores estáticos, sem recompilar, e não precisa se preocupar em preencher seu banco de dados (relacional) com dados de referência (pois isso parece ser um preocupação, e talvez nem tudo precise estar no banco de dados).

Por que esses valores devem entrar em um arquivo de configuração, em vez de em uma tabela de referência: você planeja usar esses valores principalmente no código ou principalmente no banco de dados? Se você possui muitas consultas, visualizações e procedimentos existentes que dependem desses valores, pode ser melhor colocá-los no banco de dados como dados de referência, pois é mais fácil carregá-los dos arquivos de configuração e enviá-los como parâmetros para todas as consultas possíveis / visão / procedimento que os referencia. Se os valores são usados ​​principalmente no código do aplicativo, o arquivo de configuração provavelmente é uma escolha melhor.

Um exemplo mais complicado, como o que você vincula, também pode ser feito, com ou sem propriedades.

Em products.properties:

productA.name=Product A 123
productA.hasMotor=true
productA.numFeet=1
productA.hasOutlet=true
productA.needsManual=true

productB.name=Product B 456
productB.hasMotor=false
productB.numFeet=1
productB.hasOutlet=true
productB.needsManual=true

No seu arquivo de configuração do Spring:

<bean name="productA" class="com.mycompany.Product">
   <property name="name" value="${productA.name}"/>
   <property name="hasMotor" value="${productA.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<bean name="productB" class="com.mycompany.Product">
   <property name="name" value="${productB.name}"/>
   <property name="hasMotor" value="${productB.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<!-- configure as many beans as needed -->
<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames"> <!-- assumes that MotorFrameManager has a property motorFrames which is a List<Product> -->
        <list>
            <ref bean="productA"/>
            <ref bean="productB"/>
        </list>
    </property>
</bean>

O bom disso é que, se os dados de origem forem uma planilha (como na pergunta à qual você vinculou), você poderá usar macros no Excel para gerar automaticamente as propriedades e os snippets de primavera.

Eu acho que a premissa da pergunta não está certa. O fator de divisão não é a quantidade de registros que precisam ser alterados, mas a frequência das alterações e quem as altera.

Frequência

Quando os dados são voláteis , no sentido de que são alterados com frequência e fora de um ciclo de lançamento do software, eles precisam ser configurados fora dos valores codificados ou mesmo dos arquivos de configuração. Um banco de dados faz sentido aqui, especialmente se o próprio aplicativo for capaz de mantê-lo.

Quem

Quando um cliente precisa alterar dados, ele precisa ser modificado de maneira amigável e fora de um ciclo de liberação.

Tópico comum

O ponto comum aqui é que, quando os dados precisam mudar fora de uma versão de software, eles devem ser armazenados em um banco de dados. Os bancos de dados podem ser atualizados durante uma liberação, mas os dados permanecem vivos sem serem redefinidos ou fortemente modificados. Quando um cliente precisa modificar dados (ou configurar a funcionalidade), ele deve ser armazenado em um banco de dados com um bom front end à prova de idiotas.

Teste

Certifique-se de escrever testes de unidade que validam seu software em uma variedade de configurações. Talvez o seu cliente ative um prompt opcional ou redefina um metro para ser igual a doze pés. Independentemente de quão razoável seja a alteração, se o seu software permitir, é muito melhor validar que a alteração funcione conforme o esperado, não importa quão insana seja.

Não é a frequência das alterações nem a quantidade de dados que decide onde armazenar os dados.

Se os dados são necessários para executar o programa, ele faz parte do código do programa, portanto, armazene-o como uma constante. Todos os outros dados vão para o banco de dados.

Obviamente, arquivos de configuração, imagens, sons etc. geralmente são melhor armazenados no sistema de arquivos.

Se houver a menor chance de você receber uma ligação, resultando na reconstrução de um aplicativo porque algo codificado permaneceu alterado, não o codifique. No mínimo, mantenha-o em um arquivo de configuração ou tabela db. Você não precisa fornecer nenhuma interface do usuário para mantê-la necessariamente, mas discar e alterar um arquivo de configuração ou executar um SQL UPDATE em uma tabela é certamente preferível à reconstrução de toda a partida de tiro.

A distinção é de fato uma área um tanto cinzenta, mas minha abordagem para esse tipo de problema é: os dados mudam na produção "? Tudo o que muda após a implantação em um ambiente de produção deve ir para o banco de dados, mesmo para coisas que raramente mudam.

Portanto, a pergunta que você deve fazer não é "com que frequência isso muda?", Mas "pode ​​mudar?". Se um valor para uma propriedade puder variar dentro da mesma iteração de código (sem tocar em mais nada no código) no ambiente de produção, ele entrará no banco de dados.

O que você também está perdendo são as informações do tipo "controle de programa", como tamanho máximo do buffer, número de itens em voz alta em um pedido, tamanho máximo da página para uma tela sempre é melhor codificado no programa ou em um arquivo de configuração.

Se você mantiver esse tipo de dados em um banco de dados, sempre haverá a possibilidade de alguém alterá-lo rapidamente e alterar completamente o comportamento de um sistema.

O outro problema é que não há uma maneira fácil de obter entradas do banco de dados através dos sistemas de controle de origem / gerenciamento de alterações / construção automática que você deve usar.

Uma coisa que você nunca deve manter no banco de dados são os detalhes necessários para acessar o banco de dados.
Você tem um pouco de dificuldade, se precisar acessar o banco de dados para recuperar as strings de conexão, o nome de usuário e a senha do mesmo banco de dados.

Codifique-o? hmm, pode funcionar se você estiver usando algum tipo de banco de dados que é instalado e enviado com o aplicativo.
Arquivo de configuração? Mais promissor, mas e a segurança da conta?

É claro que você pode armazenar as informações do banco de dados nesse arquivo de configuração em formato criptografado, mas precisará armazenar as chaves de descriptografia em algum lugar, e isso seria codificado com quase certeza.

Além disso, há coisas que nunca mudam. Coisas como as constantes naturais (G, pi, e, o que você quiser), coisas como certas expressões regulares, como validação de email.