Quando si immettono valori di dati effettivi nel codice hard nel codice anziché utilizzare un DB?

Non penso che queste due affermazioni rappresentino realmente un consenso su quando utilizzare i dati del codice duro:

If it is a single variable or a simple structure, or an array of a few values, put data right in the code

If it has hundreds+ of rows of data of the same type, use a database

Semplice contro-esempio (sono sicuro che ce ne sono di migliori): le tabelle di sintassi del linguaggio di programmazione sono strutture complesse e di grandi dimensioni che sono spesso codificate. Dai un'occhiata a un esempio del codice sorgente Perl .

Invece vorrei concentrarmi innanzitutto sul chiedere:

• Quanto spesso cambiano i dati?

• Chi potrebbe aver bisogno di cambiarlo?

Se la risposta a "quanto spesso" è "più spesso di quanto voglio distribuire una nuova versione della mia app", allora non dovresti codificare i dati con precisione.

Se la risposta a "chi lo cambia" è "chiunque non sia il programmatore", allora non dovresti codificare i dati.

In un piccolo negozio è possibile che la distinzione tra codificatore e utente sia scomparsa e che anche l'idea di "distribuzione" sia scomparsa. In questo caso sei il re del tuo dominio e puoi fare quello che vuoi.

Ma anche in quella situazione, può sorgere la necessità di collaborare, e questo può essere difficile se un'applicazione personalizzata non segue una convenzione che i programmatori in genere seguono.

Vorrei andare con la terza opzione: un file di configurazione!

Per le applicazioni su cui lavoro (in Java, quindi tutti i miei esempi sono Java + Spring), tali valori vengono solitamente memorizzati nei file di configurazione e iniettati (tramite Spring) nel codice che li richiede all'avvio dell'applicazione. In un file delle proprietà:

motorFramesString=412T, 413T, ...

Nella configurazione di primavera:

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

Il vantaggio di questo è che puoi modificare o aggiungere più di questi valori per lo più statici abbastanza facilmente, senza una ricompilazione, e non devi preoccuparti di riempire il tuo database (relazionale) con i dati di riferimento (dato che sembra essere una preoccupazione, e forse non tutto ha bisogno di essere comunque nel database).

Per quanto riguarda perché questi valori dovrebbero essere inseriti in un file di configurazione anziché in una tabella di riferimento: prevedi di utilizzare questi valori principalmente nel codice o principalmente nel database? Se hai molte query esistenti e viste e procedure che dipendono da questi valori, allora sarebbe meglio metterli nel database come dati di riferimento, poiché è più facile che caricarli da file di configurazione e inviarli come parametri per ogni possibile query / vista / procedura che li fa riferimento. Se i valori sono utilizzati principalmente nel codice dell'applicazione, il file di configurazione è probabilmente una scelta migliore.

Un esempio più complicato come quello che si potrebbe fare anche con link, con o senza proprietà.

In 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

Nel tuo file di configurazione di primavera:

<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 cosa bella di questo è che se i tuoi dati sorgente sono un foglio di calcolo (come nella domanda a cui ti sei collegato) puoi usare le macro in Excel per generare automaticamente le proprietà e i frammenti di primavera.

Penso che la premessa della domanda non sia giusta. Il fattore di divisione non è la quantità dei record che devono essere modificati, ma la frequenza delle modifiche e chi le modifica.

Frequenza

Quando i dati sono volatili , nel senso che cambiano spesso e al di fuori di un ciclo di rilascio del software, devono poter essere configurati al di fuori dei valori codificati o persino dei file di configurazione . Un database ha senso qui, specialmente se l'applicazione stessa è in grado di mantenerla.

Chi

Quando un cliente deve essere in grado di modificare i dati, deve essere modificabile in modo user-friendly e al di fuori di un ciclo di rilascio.

Filetto comune

Il filo conduttore è che quando i dati devono cambiare al di fuori di una versione del software, devono essere memorizzati in un database. I database potrebbero essere aggiornati durante il rilascio, ma i dati sono attivi senza essere reimpostati o strongmente modificati. Quando un cliente deve essere in grado di modificare i dati (o configurare le funzionalità), deve essere memorizzato in un database con un front-end piacevole che sia a prova di idiota.

Test

Assicurati di scrivere test unitari che convalidino il tuo software in una varietà di configurazioni. Forse il tuo cliente attiva un prompt facoltativo o ridefinisce un metro a un metro e mezzo. Indipendentemente da quanto sia ragionevole il cambiamento, se il software lo consente, è meglio che il cambiamento funzioni come previsto, non importa quanto sia inane.

Non è né la frequenza delle modifiche né la quantità di dati che decide dove memorizzare i dati.

Se i dati sono necessari per eseguire il programma, fanno parte del codice del programma, quindi memorizzarlo come costante. Tutti gli altri dati vanno nel database.

Naturalmente, i file di configurazione, le immagini, i suoni, ecc. di solito sono meglio conservati sul filesystem.

Se c'è anche la minima possibilità che tu possa mai ricevere una telefonata che ti porta a dover ricostruire un'applicazione perché qualcosa di codificato è cambiato, allora non codificarlo. Per lo meno tenerlo in un file di configurazione o tabella db. Non è necessario fornire alcuna interfaccia utente per mantenerla necessariamente, ma la composizione e la modifica di un file di configurazione o l'esecuzione di un UPDATE SQL su un tavolo è sicuramente preferibile per la ricostruzione dell'intera partita.

La distinzione è in realtà un'area piuttosto grigia, ma il mio approccio a questo tipo di problemi è: i dati cambiano nella produzione? "Tutto ciò che cambia dopo la distribuzione in un ambiente di produzione dovrebbe andare nel database, anche per cose che potrebbero raramente cambia.

Quindi la domanda che dovresti porre non è "quanto spesso cambierà?", ma "può cambiare?". Se un valore per una proprietà può variare all'interno della stessa iterazione di codice (senza toccare altro nel codice) nell'ambiente di produzione, viene inserito nel database.

Ciò che manca è anche informazioni sul tipo "controllo programma", ad esempio dimensione massima del buffer, numero di elementi ad alta voce in un ordine, dimensione massima della pagina per uno schermo sempre migliore o codificata nel programma o in un file di configurazione.

Se mantieni questo tipo di dati in un database c'è sempre la possibilità che qualcuno lo modifichi al volo e cambi completamente il comportamento di un sistema.

L'altro problema è che non esiste un modo semplice per ottenere le voci del database attraverso i sistemi di controllo del codice sorgente / modifica della gestione / generazione automatica che dovresti utilizzare.

Una cosa che non dovresti mai tenere nel database sono i dettagli necessari per accedere al database.
Hai un po 'di catch-22 se hai bisogno di accedere al database per recuperare le stringhe di connessione, il nome utente e la password per quello stesso database dopo tutto.

Hardcode vero? hmm, potrebbe funzionare se stai usando una sorta di database che si installa e viene fornito con l'applicazione.
File di configurazione? Più promettente, ma per quanto riguarda la sicurezza dell'account?

Ovviamente è possibile archiviare le informazioni del database in tale file di configurazione in forma crittografata, ma in tal caso è necessario avere le chiavi di decrittografia memorizzate da qualche parte, e quasi sicuramente codificate.

A parte questo, ci sono cose che non cambiano mai. Cose come le costanti naturali (G, pi, e, tu lo chiami), le cose forse sono come certe espressioni regolari, come la convalida dell'email.