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?

17

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

Dennis
la source
3
Le consensus incalculable n'a généralement PAS é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.
Pieter B
Il existe un moyen terme: les données sont stockées dans une base de données. Ensuite, il est extrait pour écrire le code source (par exemple, dans un global_constants.hfichier).
mouviciel
@mouviciel mais ce qui constitue des données ... vous avez besoin de certaines données pour accéder à la base de données, donc vous ne pouvez pas y stocker toutes les données.
jwenting

Réponses:

33

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.

code x
la source
6
Semblable à la question de la fréquence, une autre question est: "À quelle vitesse faut-il changer?" Le facteur de déclenchement peut être le temps nécessaire au déploiement sur l'ensemble de votre base d'utilisateurs. Pour les logiciels serveur centralisés, la réponse peut être quelques minutes, mais pour les applications mobiles sur le terrain, cela peut prendre des semaines.
CuriousRabbit
Dans l'exemple Perl, je dirais que an array with a few values, peu étant des lignes de 377 ish de type de données fondamental. Peut-être plus que «quelques-uns» pour certains, mais c'est encore assez petit. J'ai des structures similaires mais légèrement moins plates codées en dur. Si c'était plus de mille lignes, je serais probablement plus réticent à le coder en dur de cette façon.
Dennis
14

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.

FrustratedWithFormsDesigner
la source
pendant que vous êtes sur l'exemple du cadre, c'est assez simple (une seule valeur de chaîne). Votre approche sera-t-elle fondamentalement la même pour le tableau d'options qui a n-tuples de variables mixtes (liées au bas de ma question)?
Dennis
@Dennis: Ajout d'un exemple plus complexe.
FrustratedWithFormsDesigner
8
Un fichier de configuration n'est qu'une forme de db.
DougM
3
@DougM, je suis d'accord, mais il y a un monde de différence entre configurer une série de tables de configuration dans Oracle et avoir un simple fichier de configuration XML. Le fichier de configuration a également l'avantage d'être contrôlé par le contrôle de version. Le fichier de configuration est un juste milieu et encourage les codeurs à séparer davantage de données de configuration. J'ai du mal à penser à des scénarios réalistes où le temps n'est pas une bonne chose
mcottle
2
@gbjbaanb: Pour la plupart des applications, un SGBDR est une surpuissance WAAAAAY, même pour des systèmes par ailleurs assez étendus. Sans oublier qu'ils sont lents et nécessitent beaucoup d'efforts pour être maintenus et intégrés. Les fichiers "ini" ne fournissent aucune sécurité de type, vous devez écrire l'analyseur vous-même et vous devez écrire votre propre vérification de type. Les fichiers XML Config, au moins en .Net, bénéficient de tous les avantages offerts par l'une ou l'autre de vos options préférées essentiellement GRATUITEMENT. Donc, votre affirmation selon laquelle un fichier de configuration XML est toujours un choix pire ne pourrait pas être plus fausse.
Dunk
10

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


la source
4

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.

accolade
la source
J'ai créé un programme d'assistance au centre d'appels entièrement piloté par la base de données; les données étaient nécessaires pour "exécuter le code", mais il aurait été absurde de les compiler.
DougM
1
J'ai été développeur Oracle pendant 8 ans, mais je n'aime toujours pas les applications qui ont un couplage aussi étroit avec la base de données sous-jacente.
winkbrace
2

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.

Alan B
la source
1

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.

Thyamarkos
la source
0

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.

James Anderson
la source
0

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.

jwenting
la source