Wann werden tatsächliche Datenwerte nicht mit einem DB, sondern mit einem Hardcode in den Code eingegeben?

Eine langjährige Frage für mich war: Wann speichere ich Daten (Istwerte) in einer Datenbanktabelle und wann speichere ich sie direkt im Code?

Der unsagbare Konsens war typischerweise so (*):

Wenn es sich um eine einzelne Variable, eine einfache Struktur oder ein Array mit wenigen Werten handelt, fügen Sie die Daten direkt in den Code ein.

[* Konsens wurde in Kommentaren und Antworten diskutiert, aber im Grunde wollte ich eine Art Prämisse, um die Frage anzufangen, also zögern Sie nicht, sie herauszufordern und zu verbessern ]

Beispiel:

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

Wenn es Hunderte von Datenzeilen desselben Typs enthält, verwenden Sie eine Datenbank.

Aber es scheint eine Grauzone zu geben; was ist mit Fällen, die nicht so klar sind? Auf welche Überlegungen und Faktoren muss man achten, um eine Entscheidung zu treffen?

Beispiel:
Angenommen, Ihr Unternehmen verwendet 10-15 verschiedene Arten von Motorrahmen, die als "412T" dargestellt werden können. Sie haben ungefähr 30 von ihnen und sie ändern sich selten. Sie können entweder eine DB-Tabelle für diese erstellen oder sie in einer Datenbank fest codieren. In diesem Fall sind Motoren statische, physikalische Dinge, die sich wahrscheinlich nicht oft ändern.

Wenn Sie sie im Code behalten, unterliegen sie der Quellcodeverwaltung. In einer Datenbank werden DB-Änderungen normalerweise nicht nachverfolgt. Wenn Sie sie jedoch in einer Datenbank aufbewahren, wird der Code von den Daten getrennt.

Ein weiteres (aktuelles) Beispiel, das ich verwenden kann, ist meine Frage: /programming/26169751/how-to-best-get-the-data-out-a-lookup-table (derzeit 48) Zeilen mit Optionsdaten).

Ich glaube nicht, dass diese beiden Aussagen wirklich einen Konsens darüber darstellen, wann Daten hart codiert werden sollen:

Wenn es sich um eine einzelne Variable, eine einfache Struktur oder ein Array mit wenigen Werten handelt, fügen Sie die Daten direkt in den Code ein

Wenn es Hunderte von Datenzeilen desselben Typs enthält, verwenden Sie eine Datenbank

Einfaches Gegenbeispiel (ich bin sicher, es gibt bessere): Syntaxtabellen für Programmiersprachen sind komplexe, große Strukturen, die häufig hartcodiert sind. Schauen Sie sich ein Beispiel aus dem Perl-Quellcode an .

Stattdessen würde ich mich zuerst auf folgende Fragen konzentrieren:

• Wie oft ändern sich die Daten?

• Wer könnte das ändern müssen?

Wenn die Antwort auf "wie oft" lautet "öfter als ich eine neue Version meiner App bereitstellen möchte", sollten Sie die Daten nicht hart codieren.

Wenn die Antwort auf "Wer ändert das?" "Jemand anderes als der Programmierer" lautet, sollten Sie die Daten nicht hart codieren.

In einem kleinen Geschäft ist es möglich, dass die Unterscheidung zwischen dem Codierer und dem Benutzer verschwunden ist und die Idee des "Einsatzes" ebenfalls verschwunden ist. In diesem Fall sind Sie der König Ihrer eigenen Domain und können tun, was Sie wollen.

Aber selbst in dieser Situation kann die Notwendigkeit einer Zusammenarbeit aufkommen, und dies kann schwierig sein, wenn eine benutzerdefinierte Anwendung nicht einer Konvention folgt, die normalerweise von Programmierern befolgt wird.

Ich würde mit der dritten Option gehen: eine Konfigurationsdatei!

Für Anwendungen, an denen ich arbeite (in Java verwenden alle meine Beispiele Java + Spring), werden solche Werte normalerweise in Konfigurationsdateien gespeichert und (über Spring) in den Code eingefügt, der sie beim Start der Anwendung benötigt. In einer Eigenschaftendatei:

motorFramesString=412T, 413T, ...

In der Frühlingskonfiguration:

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

Dies hat den Vorteil, dass Sie diese größtenteils statischen Werte ohne erneute Kompilierung problemlos ändern oder hinzufügen können und sich nicht darum kümmern müssen, Ihre (relationale) Datenbank mit Referenzdaten zu füllen (da dies anscheinend ein Problem ist) Sorge, und vielleicht nicht alles Bedürfnis in der Datenbank sein , sowieso).

Was , warum diese Werte gehen sollten statt einer Referenztabelle in eine Konfigurationsdatei: Planen Sie diese Werte in Code meist zu verwenden, oder vor allem in der Datenbank? Wenn viele Abfragen, Ansichten und Prozeduren vorhanden sind, die von diesen Werten abhängen, empfiehlt es sich, sie als Referenzdaten in die Datenbank aufzunehmen, da es einfacher ist, sie aus Konfigurationsdateien zu laden und als Parameter an alle möglichen Abfragen zu senden. Ansicht / Prozedur, die auf sie verweist. Wenn die Werte hauptsächlich im Anwendungscode verwendet werden, ist die Konfigurationsdatei wahrscheinlich die bessere Wahl.

Ein komplizierteres Beispiel wie das, was Sie verknüpfen, könnte auch mit oder ohne Eigenschaften erfolgen.

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

In Ihrer Spring-Konfigurationsdatei:

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

Das Schöne daran ist, dass Sie, wenn es sich bei Ihren Quelldaten um eine Kalkulationstabelle handelt (wie in der Frage, zu der Sie einen Link erstellt haben), Makros in Excel verwenden können, um die Eigenschaften und Frühlingsschnipsel automatisch zu generieren.

Ich denke, die Prämisse der Frage ist nicht ganz richtig. Der Teilungsfaktor ist nicht die Anzahl der Datensätze, die geändert werden müssen, sondern die Häufigkeit der Änderungen sowie derjenige, der sie ändert.

Frequenz

Wenn Daten in dem Sinne flüchtig sind , dass sie sich häufig und außerhalb eines Veröffentlichungszyklus der Software ändern, müssen sie außerhalb von fest codierten Werten oder sogar Konfigurationsdateien konfiguriert werden können. Eine Datenbank ist hier besonders dann sinnvoll, wenn sie von der Anwendung selbst gepflegt werden kann.

Wer

Wenn ein Kunde in der Lage sein muss, Daten zu ändern, muss er benutzerfreundlich und außerhalb eines Freigabezyklus veränderbar sein.

Gemeinsamer Thread

Der rote Faden dabei ist, dass Daten, die außerhalb einer Softwareversion geändert werden müssen, in einer Datenbank gespeichert werden sollten. Datenbanken werden möglicherweise während eines Releases aktualisiert, die Daten bleiben jedoch erhalten, ohne zurückgesetzt oder stark geändert zu werden. Wenn ein Kunde in der Lage sein muss, Daten zu ändern (oder Funktionen zu konfigurieren), sollte er in einer Datenbank mit einem ansprechenden, idiotensicheren Front-End gespeichert werden.

Testen

Stellen Sie sicher, dass Sie Komponententests schreiben, die Ihre Software in einer Vielzahl von Konfigurationen validieren. Möglicherweise aktiviert Ihr Kunde eine optionale Eingabeaufforderung oder definiert einen Meter auf zwölf Fuß neu. Unabhängig davon, wie vernünftig die Änderung ist, wenn Ihre Software dies zulässt, ist es verdammt noch mal besser zu überprüfen, ob die Änderung wie erwartet funktioniert, egal wie verrückt sie ist.

Weder die Häufigkeit der Änderungen noch die Datenmenge entscheiden darüber, wo Daten gespeichert werden.

Wenn die Daten zum Ausführen des Programms erforderlich sind, sind sie Teil des Programmcodes. Speichern Sie sie daher als Konstante. Alle anderen Daten gehen in die Datenbank.

Natürlich werden Konfigurationsdateien, Bilder, Sounds usw. normalerweise besser im Dateisystem gespeichert.

Wenn es die geringste Chance gibt, dass Sie jemals einen Anruf erhalten, der dazu führt, dass Sie eine Anwendung neu erstellen müssen, weil sich etwas Hartcodiertes geändert hat, codieren Sie es nicht hart. Bewahren Sie es zumindest in einer Konfigurationsdatei oder einer DB-Tabelle auf. Sie müssen keine Benutzeroberfläche bereitstellen, um sie unbedingt zu verwalten, aber das Einwählen und Ändern einer Konfigurationsdatei oder das Ausführen eines SQL-UPDATES für eine Tabelle ist dem erneuten Erstellen des gesamten Schießspiels sicherlich vorzuziehen.

Die Unterscheidung ist in der Tat eine etwas graue Zone, aber meine Herangehensweise an diese Art von Problemen lautet: Verändern sich die Daten in der Produktion? Alles, was sich nach der Bereitstellung in einer Produktionsumgebung ändert, sollte in der Datenbank gespeichert werden, auch für Dinge, die sich selten ändern.

Die Frage, die Sie sich stellen sollten, lautet also nicht "Wie oft wird es sich ändern?", Sondern "Kann es sich ändern?". Wenn ein Wert für eine Eigenschaft innerhalb derselben Code-Iteration in der Produktionsumgebung variieren kann (ohne etwas anderes im Code zu berühren), wird er in die Datenbank eingegeben.

Was Sie auch vermissen, ist die Typinformation "Programmsteuerung", die besagt, dass die maximale Puffergröße, die Anzahl der lauten Elemente in einer Reihenfolge und die maximale Seitengröße für einen Bildschirm immer besser ist, entweder fest im Programm oder in einer Konfigurationsdatei codiert.

Wenn Sie diese Art von Daten in einer Datenbank aufbewahren, besteht immer die Möglichkeit, dass jemand sie im laufenden Betrieb ändert und das Verhalten eines Systems vollständig ändert.

Das andere Problem ist, dass es keine einfache Möglichkeit gibt, Datenbankeinträge über die Versionsverwaltung / Änderungsverwaltung / automatischen Erstellungssysteme abzurufen, die Sie verwenden sollten.

Eine Sache, die Sie niemals in der Datenbank behalten sollten, sind die Details, die für den Zugriff auf die Datenbank benötigt werden.
Sie haben einen kleinen Haken, wenn Sie auf die Datenbank zugreifen müssen, um die Verbindungszeichenfolgen, den Benutzernamen und das Kennwort für dieselbe Datenbank abzurufen.

Hardcode es? hmm, funktioniert möglicherweise, wenn Sie eine Datenbank verwenden, die mit der Anwendung installiert und ausgeliefert wird.
Konfigurationsdatei? Vielversprechender, aber was ist mit der Kontosicherheit?

Natürlich könnten Sie die Datenbankinformationen in dieser Konfigurationsdatei in verschlüsselter Form speichern, aber dann müssten Sie die Entschlüsselungsschlüssel irgendwo speichern, und das wäre mit ziemlicher Sicherheit hartcodiert.

Abgesehen davon gibt es Dinge, die sich nie ändern. Dinge wie die natürlichen Konstanten (G, pi, e, Sie nennen es), Dinge wie bestimmte reguläre Ausdrücke, wie die E-Mail-Validierung.