Einstellungen in eigener Tabelle speichern

Question

Hallo,

ich möchte bestimmte globale Einstellungen für eine Web-Anwendung in der Datenbank (MySQL) speichern, anstatt wie bisher als Konstanten in einer Konfigurationsdatei. Der Grund ist, dass ich diese dann später über die Anwendung ändern kann.

Mein Plan ist, dass ich hierfür eine Tabelle 'settings' erstelle mit einem Datensatz pro Einstellung. Aufbau der Spalten wäre demnach:

- eindeutige ID
- Name
- Wert

Hatte diesen Aufbau schon in mehreren Anwendungen, u. a. auch Wordpress, gesehen und denke daher, dass dieser Ansatz relativ flexibel und skalierbar ist.

Wo es bei mir hakt, ist:
- Wenn ich mehrere Einstellungen ändern will, muss ich ja mehrere Querys abfeuern (für jede Einstellung eine). Ist das überhaupt noch sinnvoll?
- Wie selektiere ich den zu ändernden Datensatz? Ich könnte in dem Form für die Verarbeitung ja den Einstellungsnamen als Feldname verwenden, damit ich beim einlesen die richtigen Werte den richtigen Formularfeldern zuordne. Aber wozu brauch ich dann noch die eindeutige ID? Den namen müsste ich ja zumindest auch Unique machen?

Konnte leider auch nicht rausfinden, wie das z.b. im Wordpress läuft. Wollte mich da ehrlich gesagt nicht durch den ganzen Code hangeln.

Kann mir jemand nen Tipp oder ne bessere Alternative geben?

Gruß

Answer 1

Hi ich_bin_nur_gast,

du solltest in einer Tabelle immer einen Unique Key haben, ob das eine ID oder der Name ist, ist erst mal gleichgültig solange es ein unique Key ist. In Datenbanksystemen kann man sogar Keys aus mehreren Feldern zusammesetzen um unique Keys zu erzeugen.

Das Ganze ist aber immer am einfachsten über eine ID zu lösen. Stell dir vor, du willst aus irgeneinem Grund einmal den Namen eines Datensatzes ändern und deine Tabellen sind nicht ordentlich normalisiert, dann bekommst du schon Probleme.

Mit einer eindeutigen ID ist man immer auf der sicheren Seite, über die man dann auch die Datensätze ansprechen kann.

Gruß Fabian

Answer 2

Einen Primärschlüssel hab ich immer in meinen Tabellen, und das dies über mehrere Felder geht, weiß ich auch. Trotzdem danke.

Wie gesagt hakt es nur an der Umsetzung. Ich versuch das mal anders zu erklären:

Fall A: tabellenstruktur ist wie beschrieben ID / Name / Wert. ID ist PK.
Verwende ich nun überall die ID (z.b. beim Lesen oder später beim Update), kann ich mir ja die Spalte Name gleich sparen. D.h. wenn ich irgendwo in meiner Anwendung genau diese Einstellung prüfen will, muss ich ja vorher schon die ID wissen?

Fall B: ich lasse die ID weg, Name ist PK. Dann kann ich mit diesem Namen sehr leicht die Einstellung in der DB prüfen und auch updaten. Auch der Code ist damit doch wieder besser wartbar.

Wozu also ne ID in der Tabelle mitführen? In Fall B ist ein umbenennen einer Einstellung zwar nicht mehr so einfach, aber in Fall A hab ich die Spalte ja nicht mal benutzt!

seltsam alles...