Quand faut-il coder en dur les valeurs réelles des données dans le code plutôt que d'utiliser une base de données?

Une question de longue date pour moi a été: quand dois-je stocker des données (valeurs réelles) dans une table de base de données, et quand dois-je les stocker directement dans le code?

Le consensus incalculable a généralement été comme tel (*):

S'il s'agit d'une seule variable ou d'une structure simple, ou d'un tableau de quelques valeurs, mettez les données directement dans le code.

[* le consensus a été débattu dans les commentaires et les réponses, mais en gros je voulais une sorte de prémisse pour relancer la question, alors n'hésitez pas à la contester et à l'améliorer ]

Exemple:

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

S'il contient des centaines + de lignes de données du même type, utilisez une base de données.

Mais il semble y avoir une zone grise; qu'en est-il des cas qui ne sont pas si clairs? À quels facteurs et facteurs faut-il faire attention pour prendre une décision?

Exemple:
supposons que votre entreprise utilise 10 à 15 types différents de cadres de moteurs pouvant être représentés par "412T". Vous en avez environ 30 et ils changent rarement. Vous pouvez soit créer une table DB pour ceux-ci, soit les coder en dur dans une base de données. Dans ce cas, les moteurs sont des choses statiques et physiques qui ne sont pas susceptibles de changer souvent.

Les conserver dans le code les soumet au contrôle de code source, où dans une base de données, les modifications de base de données ne sont généralement pas suivies. Mais les conserver dans une base de données libère (sépare) le code des données.

Un autre exemple (réel) que je peux utiliser est ma question: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (actuellement 48 lignes de données d'option).

Je ne pense pas que ces deux déclarations représentent vraiment un consensus sur le moment de coder en dur les données:

S'il s'agit d'une seule variable ou d'une structure simple, ou d'un tableau de quelques valeurs, mettez les données directement dans le code

S'il contient des centaines + de lignes de données du même type, utilisez une base de données

Contre-exemple simple (je suis sûr qu'il y en a de meilleurs): les tables de syntaxe du langage de programmation sont de grandes structures complexes qui sont souvent codées en dur. Jetez un oeil à un exemple du code source Perl .

Au lieu de cela, je me concentrerais d'abord sur la question:

• À quelle fréquence les données changent-elles?

• Qui pourrait avoir besoin de le changer?

Si la réponse à la «fréquence» est «plus souvent que je ne souhaite déployer une nouvelle version de mon application», vous ne devez pas coder en dur les données.

Si la réponse à "qui le modifie" est "quelqu'un d'autre que le programmeur", alors vous ne devez pas coder en dur les données.

Dans une petite boutique, il est possible que la distinction entre le codeur et l'utilisateur ait disparu, et l'idée de "déploiement" a également disparu. Dans ce cas, vous êtes le roi de votre propre domaine et vous pouvez faire ce que vous voulez.

Mais même dans cette situation, la nécessité de collaborer peut apparaître, et cela peut être difficile si une application personnalisée ne suit pas une convention que les programmeurs suivent généralement.

J'irais avec la troisième option: un fichier de configuration!

Pour les applications sur lesquelles je travaille (en Java, donc tous mes exemples utilisent Java + Spring), ces valeurs sont généralement stockées dans des fichiers de configuration et injectées (via Spring) dans le code qui en a besoin au démarrage de l'application. Dans un fichier de propriétés:

motorFramesString=412T, 413T, ...

Dans la config du printemps:

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

L'avantage de cela est que vous pouvez modifier ou ajouter plus de ces valeurs principalement statiques assez facilement, sans recompilation, et vous n'avez pas à vous soucier de remplir votre base de données (relationnelle) avec des données de référence (car cela semble être un et peut-être que tout ne doit pas être de toute façon dans la base de données).

Quant à savoir pourquoi ces valeurs devraient aller dans un fichier de configuration au lieu d'une table de référence: prévoyez-vous d'utiliser ces valeurs principalement dans le code, ou principalement dans la base de données? Si vous avez de nombreuses requêtes et vues et procédures existantes qui dépendent de ces valeurs, il peut être préférable de les placer dans la base de données en tant que données de référence, car il est plus facile que de les charger à partir de fichiers de configuration et de les envoyer en tant que paramètres à chaque requête possible / vue / procédure qui les référence. Si les valeurs sont principalement utilisées dans le code d'application, le fichier de configuration est probablement un meilleur choix.

Un exemple plus compliqué comme ce que vous liez pourrait aussi être fait, avec ou sans propriétés.

Dans 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

Dans votre fichier de configuration de printemps:

<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>

La bonne chose à ce sujet est que si vos données source sont une feuille de calcul (comme dans la question à laquelle vous avez lié), vous pouvez utiliser des macros dans Excel pour générer automatiquement les propriétés et les extraits de printemps.

Je pense que la prémisse de la question n'est pas tout à fait correcte. Le facteur de division n'est pas la quantité d'enregistrements qui doivent changer, mais la fréquence des changements ainsi que la personne qui les change.

La fréquence

Lorsque les données sont volatiles , dans le sens où elles changent souvent et en dehors d'un cycle de version du logiciel, elles doivent pouvoir être configurées en dehors des valeurs codées en dur ou même des fichiers de configuration. Une base de données est logique ici, surtout si l'application elle-même est capable de la maintenir.

Qui

Lorsqu'un client doit pouvoir modifier des données, celles-ci doivent être modifiables de manière conviviale et en dehors d'un cycle de publication.

Dénominateur commun

Le fil conducteur ici est que lorsque les données doivent changer en dehors d'une version logicielle, elles doivent être stockées dans une base de données. Les bases de données peuvent être mises à niveau pendant une version, mais les données perdurent sans être réinitialisées ou fortement modifiées. Lorsqu'un client doit être en mesure de modifier des données (ou de configurer des fonctionnalités), celles-ci doivent être stockées dans une base de données avec un joli front-end à l'épreuve des idiots.

Essai

Assurez-vous d'écrire des tests unitaires qui valident votre logiciel dans une variété de configurations. Peut-être que votre client active une invite facultative ou redéfinit un mètre pour égaler douze pieds. Peu importe à quel point le changement est raisonnable, si votre logiciel le permet, il vaut mieux valider que le changement fonctionne comme prévu, peu importe à quel point il est insensé.

Ce n'est ni la fréquence des changements ni la quantité de données qui décide où stocker les données.

Si les données sont nécessaires pour exécuter le programme, elles font partie du code du programme, alors stockez-les en tant que constante. Toutes les autres données sont enregistrées dans la base de données.

Bien sûr, les fichiers de configuration, les images, les sons, etc. sont généralement mieux stockés sur le système de fichiers.

S'il y a la moindre chance que vous receviez un appel téléphonique vous obligeant à reconstruire une application parce que quelque chose de codé en dur a changé, alors ne le codez pas en dur. Gardez-le à tout le moins dans un fichier de configuration ou une table db. Vous n'avez pas besoin de fournir d'interface utilisateur pour le maintenir nécessairement, mais la numérotation et la modification d'un fichier de configuration ou l'exécution d'une mise à jour SQL sur une table est sûrement préférable à la reconstruction de l'ensemble du match de tir.

La distinction est en effet une zone quelque peu grise, mais mon approche de ce type de problèmes est la suivante: les données changent-elles en production "? Tout ce qui change après le déploiement dans un environnement de production doit aller dans la base de données, même pour des choses qui peuvent rarement changer.

Donc, la question que vous devriez vous poser n'est pas "à quelle fréquence cela changera-t-il?", Mais "cela peut-il changer?". Si une valeur pour une propriété peut varier dans la même itération de code (sans toucher à quoi que ce soit d'autre dans le code) sur l'environnement de production, elle va dans la base de données.

Ce qui vous manque également, ce sont les informations de type «contrôle de programme», par exemple la taille maximale du tampon, le nombre d'éléments à haute voix dans un ordre, la taille maximale de la page pour un écran est toujours meilleure, soit codée en dur dans le programme ou dans un fichier de configuration.

Si vous conservez ce type de données dans une base de données, il est toujours possible que quelqu'un les modifie à la volée et change complètement le comportement d'un système.

L'autre problème est qu'il n'y a pas de moyen facile d'obtenir des entrées de base de données via les systèmes de contrôle de source / gestion des modifications / génération automatique que vous devriez utiliser.

Une chose que vous ne devriez jamais conserver dans la base de données sont les détails nécessaires pour accéder à la base de données.
Vous avez un petit problème si vous devez accéder à la base de données pour récupérer les chaînes de connexion, le nom d'utilisateur et le mot de passe pour cette même base de données après tout.

Le coder en dur? hmm, cela pourrait fonctionner si vous utilisez une sorte de base de données qui s'installe et est livrée avec l'application.
Fichier de configuration? Plus prometteur mais qu'en est-il de la sécurité des comptes?

Bien sûr, vous pouvez stocker les informations de la base de données dans ce fichier de configuration sous forme cryptée, mais vous devrez alors stocker les clés de décryptage quelque part, et elles seront codées en dur presque certainement.

En dehors de cela, il y a des choses qui ne changent jamais. Des choses comme les constantes naturelles (G, pi, e, vous l'appelez), des choses comme certaines expressions régulières, comme la validation des e-mails.