Wie strukturieren Sie Konfigurationsdaten in einer Datenbank?

Question

Was ist bevorzugte Methode der Menschen von Anwendungskonfigurationsdaten in einer Datenbank zu speichern. Von habe in der Vergangenheit selbst dies getan, habe ich zwei Möglichkeiten, es zu tun genutzt werden.

1. Sie können eine Tabelle erstellen, in dem Sie Schlüssel / Wert-Paare speichern, in dem Schlüssel die Namen der Konfigurationsoption sind und Wert ist sein Wert. Pro hierfür ist das Hinzufügen neuer Werte ist einfach und Sie können die gleichen Routinen verwenden, um Set / Get-Daten. Nachteile sind Sie nicht typisierte Daten als Wert haben.
2. Alternativ können Sie auch eine Konfigurationstabelle codieren, wobei jede Spalte der Name des Wertes und dessen Datentyp zu sein. Der Nachteil ist, mehr Wartung neue Werte einrichten, aber es ermöglicht Ihnen eingegebene Daten haben.

beide verwendet hat, liegen meine Vorlieben mit der ersten Option als schnelle Dinge einzurichten, aber es ist auch riskanter und können die Leistung reduzieren (leicht), wenn Daten nach oben. Hat jemand irgendwelche alternativen Methoden haben?

Aktualisieren

Es ist notwendig, die Informationen in einer Datenbank zu speichern, weil, wie unten erwähnt, mehrere Instanzen des Programms sein kann, die die gleiche Art und Weise erfordern die Konfiguration, sowie gespeicherte Prozeduren möglicherweise die gleichen Werte verwendet wird.

Answer 1

Sie können erweitern Option 1 eine dritte Spalte zu haben, einen Datentyp geben. Ihre Anwendung kann als Sie mit diesem Datentyp Spalte den Wert werfen.

Aber ja, ich würde mit Option 1, wenn Konfigurationsdateien keine Option sind. Ein weiterer Vorteil der Option 1 ist, dass Sie es in ein Dictionary-Objekt (oder gleichwertig) für den Einsatz in Ihrer Anwendung wirklich leicht lesen können.

Answer 2

Da Konfiguration kann in der Regel in einer Textdatei gespeichert werden, sollte der Zeichenfolge Datentyp mehr als genug, um die Konfigurationswerte zu speichern. Wenn Sie eine verwaltete Sprache verwenden, ist es der Code, der Datentyp weiß, was sein sollte, nicht die Datenbank.

Noch wichtiger ist, betrachten Sie diese Dinge mit Konfiguration:

• Hierarchie : Offensichtlich Konfiguration wird von einem profitieren Hierarchie
• Versioning . Betrachten wir den Vorteil der Lage zu sein, auf die Konfiguration rückgängig zu machen, die zu einem bestimmten Zeitpunkt in Kraft war
• Distribution : Einige Zeit, könnte es schön sein, um eine Anwendung gruppieren. Einige Eigenschaften wahrscheinlich sollten in einem Cluster zu jedem Knoten lokal sein.
• Dokumentation : Je nachdem, ob Sie ein Web-Tool oder etwas haben, ist es wahrscheinlich schön, die Dokumentation zu einer Immobilie nahe den Code zu speichern, die es verwendet. (Code-Annotationen ist für diese sehr schön.)
• Mitteilung : Wie wird der Code nicht wissen, dass eine Änderung irgendwo im Konfigurations-Repository gemacht wurde

Persönlich Ich mag eine umgekehrte Art und Weise der Handhabung Konfiguration, wo die Konfigurationseigenschaften in die Module eingespritzt wird, die nicht wissen, wo die Werte kamen. Auf diese Weise kann das Konfigurationsmanagementsystem sehr komplex sein oder ganz einfach je nach (Strom) benötigt.

Answer 3

Ich verwende Option 1.

Answer 4

Es scheint Overkill die DB für Konfigurationsdaten zu verwenden.

EDIT (sorry zu lang für einen Kommentar-Box): Natürlich gibt es keine strengen Regeln, wie Sie einen Teil Ihres Programms umzusetzen. Aus Gründen der Argumentation, Schlitzschraubendreher auf einigen Kreuzschrauben arbeiten! Ich glaube, ich entschieden zu früh, bevor man weiß, was Ihr Szenario.

Relationale Datenbank zeichnet sich in massiven Datenspeicher, den Sie schnell Speicherung gibt, Aktualisierung und Wiederherstellung, so dass, wenn Sie Ihre Konfigurationsdaten aktualisiert und ständig lesen, dann mit allen Mitteln db verwenden.

Ein weiteres Szenario, in dem db Sinn machen kann, ist, wenn Sie eine Server-Farm, wo Sie Ihre Datenbank mögen Ihre zentrale Konfiguration speichern, aber dann können Sie das gleiche mit einem gemeinsam genutzten Netzwerk-Laufwerk zu tun, die die XML-Konfigurationsdatei verweisen.

XML-Datei ist besser, wenn Sie Ihre Konfiguration hierarchisch strukturiert ist. Sie können ganz einfach organisieren, finden und aktualisieren, was Sie brauchen, und für Bonus profitieren können Sie die Version der Konfigurationsdatei zusammen mit Ihrem Quellcode steuern!

Alles in allem, es hängt alles davon ab, wie die Konfigurationsdaten verwendet wird.

Das schließt meiner Meinung nach mit begrenztem Wissen Ihrer Anwendung. Ich bin sicher, Sie können die richtige Entscheidung treffen.

Answer 5

Ich denke, das mehr eine Umfrage ist, also wird ich den Spalt Ansatz (Option 2) sagen. Allerdings wird es ab, wie oft Sie Ihre Konfigurationsänderungen abhängen, wie dynamisch es ist, und wie viele Daten gibt es, etc.

Ich würde sicherlich diesen Ansatz für Benutzerkonfigurationen / preferences, etc.

Answer 6

Ihr Projekt verwendet eine Datenbank-Tabelle mit vier Spalten:

1. ID [pk]
2. Scope (default 'Anwendung')
3. Einstellung
4. Wert

Einstellungen mit einem Umfang von ‚Anwendung‘ sind globale Einstellungen, wie zum Beispiel maximale Anzahl der gleichzeitigen Benutzer.

Jedes Modul verfügt über einen eigenen Anwendungsbereich basiert; so unsere ResultsLoader und UserLoader haben unterschiedliche Bereiche, aber beide haben eine Einstellung namens ‚InputPath‘.

Standardwerte sind entweder im Quellcode zur Verfügung gestellt oder über unseren IoC Behälter injizieren. Wenn kein Wert eingespritzt wird, oder in der Datenbank zur Verfügung gestellt, wird der Standard von Code verwendet (falls vorhanden). Daher Standardwerte werden nie in der Datenbank gespeichert.

Dies funktioniert für uns ganz gut aus. Jedes Mal, wenn wir ein Backup der Datenbank wir eine Kopie der Konfiguration was recht praktisch ist. Die beiden sind immer synchron.

Answer 7

Gehen Sie mit Option 2. Option 1 ist wirklich eine Möglichkeit, eine Datenbank auf einer Datenbank der Implementierung, und das ist eine wohlbekannte Antipattern, die gerade geht Sie Probleme auf lange Sicht geben.

Answer 8

kann ich denke an mindestens zwei weitere Möglichkeiten:

(a) Erstellen Sie eine Tabelle mit Schlüsseln, String-Wert, Datum-Wert, int-Wert, Realwertspalten. Lassen Sie nicht genutzte Arten NULL.

(b) Verwenden Sie eine Serialisierung Format wie XML, YAML oder JSON und speichern sie alle in einem Blob.

Answer 9

Wo sehen Sie Sie speichern die Konfigurationseinstellungen Ihrer App auf die Datenbank verbinden muss?

Warum speichert nicht die andere Konfigurationsinfo es auch?

Answer 10

ich mit der Option gehen würde 1, es sei denn, die Anzahl der Konfigurationsoptionen sehr klein waren (sieben oder weniger)

Answer 11

In meiner Firma, wir arbeiten mit der Option ein (eine einfache Wörterbuch artiger Tabelle) mit einem Twist. Wir ermöglichen für String-Substitution unter Verwendung von Token, die den Namen des Konfigurationsvariable enthalten wechselt werden müsse.

Zum Beispiel könnten die Tabellenzeilen enthalten ( 'Datenbank-Verbindungszeichenfolge', 'jdbc: //% host% ...') und ( 'host', 'Foobar'). dass mit einem einfachen Service oder gespeicherte Prozedur Schicht einkapseln ermöglicht eine extrem einfache, aber flexible, rekursive Konfiguration. Es unterstützt unsere Notwendigkeit, mehrere isolierte Umgebungen (dev, test, prod, etc.) haben.

Answer 12

Ich habe beide 1 und 2 in der Vergangenheit verwendet, und ich denke, dass sie beide schrecklich Lösungen sind. Ich denke, Option 2 besser ist, weil es die Eingabe erlaubt, aber es ist viel mehr hässlich als Option 1. Das größte Problem, das ich mit entweder der Konfigurationsdatei wird Versionierung. Sie können Version SQL recht gut Standard Versionskontrollsysteme verwenden, aber Änderungen Verschmelzung ist in der Regel problematisch. Gegeben die Möglichkeit, diesen „richtig“ zu tun, würde ich wahrscheinlich eine Reihe von Tabellen erstellen, eine für jede Art von Konfigurationsparameter (nicht unbedingt für jeden Parameter selbst), wodurch der Nutzen der Typisierung erhalten und den Nutzen der Schlüssel / Wert Paradigma, wo angemessen. Sie können aber auch komplexere Strukturen auf diese Weise, wie Listen und Hierarchien implementieren, die dann direkt von der App abfragbare werden, anstatt die Config laden zu haben und es dann irgendwie in Erinnerung zu verwandeln.

Answer 13

Ich stimme für Option 2. Einfach zu verstehen und zu pflegen.

Answer 14

Option 1 ist gut für einen leicht erweiterbar, zentralen Speicherort. Neben einigen der großen Spalte Vorschläge von Leuten wie RB, Hugo, und elliott, Sie auch interessieren könnten:

Fügen Sie eine Global / Benutzereinstellung Flagge mit einem Benutzerfeld oder sogar ein Benutzer / Maschine-Feld (für maschinenspezifische UI-Typ-Einstellungen).

Die können, natürlich, in einer lokalen Datei gespeichert werden, aber da Sie die Datenbank trotzdem verwenden, macht, dass diese zur Verfügung eines Benutzers für Aliasing beim Debuggen - was wichtig sein kann, wenn der Fehler damit verbundenen setzt. Es ermöglicht auch ein Admin setings zu verwalten, wenn notwendig.

Answer 15

Ich benutze eine Mischung aus Option 2 und XML-Spalten in SQL Server. Sie können auch die Tabelle zu halten, bei einer Reihe wan't eine Check-Bedingung hinzuzufügen.

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)

Answer 16

für Einstellungen, die in keinem Verhältnis zu einem beliebigen DB-Tabellen haben, würde ich für den EAV Ansatz gehen wahrscheinlich, wenn Sie die db müssen mit den Werten zu arbeiten. andernfalls ein serialisierte Feldwert ist gut, wenn es für App-Code wirklich nur ein Geschäft ist.

aber was ist ein Format für ein einzelnes Feld mehr Konfigurationseinstellungen zu speichern, die von der DB genutzt werden?

wie ein Feld pro Benutzer, die alle ihre Einstellungen in Bezug auf ihre Messageboard-Ansicht enthält (wie Standardsortierreihenfolge, blockierten Themen, etc.), und vielleicht eine andere mit all ihren Einstellungen für ihr Thema (wie Textfarbe, bg Farbe, usw. ).

Answer 17

Speichern von Hierarchie und Dokumente in einer relationalen DB ist Wahnsinn. Zum einen müssen Sie entweder sie vernichten, nur um sie zu einem späteren Zeitpunkt rekombinieren. Oder es in einem BLOB bunged, noch dümmer.

Verwenden Sie keine relationale db für nicht-relationale Daten verwenden, wird das Werkzeug nicht passt. Betrachten wir so etwas wie MongoDB oder CouchDB dafür. Schema-weniger nicht-relationale Daten speichern. Bewahren Sie es als JSON, wenn es kommt unten den Draht in irgendeiner Weise an einen Client, verwenden XML für server.

CouchDB gibt Ihnen Versionierung aus dem Kasten heraus.

Answer 18

Speichern Sie keine Konfigurationsdaten in einer Datenbank, wenn Sie einen sehr guten Grund zu haben. Wenn Sie einen sehr guten Grund zu tun haben, und sind absolut sicher, dass Sie es tun werden, sollten Sie wahrscheinlich speichern sie in einer Datenserialisierung Format wie JSON oder YAML (nicht XML, es sei denn, Sie brauchen eigentlich eine Auszeichnungssprache Ihrer App zu konfigurieren - - glauben Sie mir, Sie nicht) als String zurück. Dann können Sie einfach die Zeichenfolge lesen und verwenden Werkzeuge in welcher Sprache arbeiten Sie darin zu lesen und zu ändern. Speichern Sie die Saiten mit Zeitstempel, und Sie haben ein einfaches Versionsschema mit der Fähigkeit, hierarchische Daten in einem sehr einfachen System zu speichern. Auch wenn Sie nicht hierarchische Konfigurationsdaten brauchen, zumindest jetzt, wenn Sie es in der Zukunft brauchen werden Sie nicht um es zu bekommen, um Ihre Config-Schnittstelle zu ändern. Natürlich verlieren Sie die Möglichkeit, relationale Abfragen auf Ihren Konfigurationsdaten zu tun, aber wenn Sie auf Speicher , dass viele Daten Config, dann sind Sie wahrscheinlich sowieso etwas sehr falsch zu machen.

Die Unternehmen neigen dazu, viele Konfigurationsdaten für ihre Systeme in einer Datenbank zu speichern, ich bin nicht sicher, warum, das glaube ich nicht viel Gedanken in diese Entscheidungen geht. Ich sehe nicht, diese Art der Sache zu oft in der OSS-Welt getan. Selbst große OSS-Programme, die viele Konfiguration wie Apache benötigen brauchen nicht eine Verbindung zu einer Datenbank eine Tabelle mit apache_config zu arbeiten. eine riesige Menge an Konfiguration mit in Ihren Anwendungen zu behandeln ist ein schlechter Code Geruch, Speicherung, dass die Daten in einer Datenbank nur mehr Probleme verursacht (wie dieses Thema zeigt).