Tweet
Ich würde gerne darüber diskutieren, wie man am Besten eine Tabelle für Einstellungen realisiert.
Ich benutze ein ORM, welches mir eine Zeile aus einer Tabelle als Klasse mit gettern und settern gibt. Desweiteren werden mehrere Zeilen aus der Tabelle als Array von Klassen synthetisiert.
Die Klassen generiere ich anhand des Schemas automatisch, wobei die vorhandene Tabelle und deren Daten gelöscht werden.
Jetzt benötige ich eine Tabelle für diverse Einstellungen, es ist noch nicht exakt absehbar, wieviele und es ist wahrscheinlich, dass die Anzahl wachsen wird.
Nun kann ich das in zwei Arten umsetzen:
pk: Primary key
fk: Foreign key
(nur für den Fall
)
Zu 1
Vorteile:
Ein Primary key. Generierte Klasse "Setting" hat alle getter und setter der Einstellungen, das ermöglicht implizites Wissen über die Einstellungen, getSendeEmail, setSendeEmail, usw...
Query ist simpel, ich bekomme ein einziges Setting Objekt, Verwaltung muss alle getter durchgehen, um die Werte zu bekommen (kann automatisiert werden)
Nachteile:
Neue Einstellung erfordert Anpassung des Schemas, was in der Regel eine Neugenerierung der Tabellen erfordert->Datenverlusst. Ich muss manuell zusehen, dass evtl im Produktivbetrieb gemacht Einstellungen 'portiert' werden und neue Sachen defaulten.
Zu 2
Vorteile: Generische Erzeugung von neuen Einstellungen, Schema bleibt dadurch unverändert. Kein Datenverlust durch Neugenerierung, keine Portierung vorhandener Daten.
Nachteile: Kein implizites Wissen über Einstellungen, es gibt nur getType und getValue. Die Logik muss auf Appliktionsseite verwaltet werden. Probleme wie sendeEmail und sendeMail müssen explizit verhindert werden. Daraus folgt erschwerte Verwaltung. Zusammengesetztes Primary key aus id und user_id, alternativ auch type und user_id. Ich kriege ein Array von Setting Objekten (mehr Datentransfer und mehr Objekte, die durchs ORM müssen), die ich zusätzlich durch mehr Aufwand verarbeiten muss.
Ich tendiere im Moment, da in der Entwicklung zu Lösung 1. Ich bin relativ frei mit der Erzeugung neuer Einstellungen, da keine Benutzerdaten existieren. In Prod muss ich dann das neue Schema mit Alter Table ändern, um Daten nicht zu verlieren. Für ein langfristiges Projekt wie dieses ist das Schema auch die Dokumentation, ich kann nie vergessen, welche Einstellungen bereits drin sind.
Ich würde mich über ein paar Kommentare sehr freuen
Ich benutze ein ORM, welches mir eine Zeile aus einer Tabelle als Klasse mit gettern und settern gibt. Desweiteren werden mehrere Zeilen aus der Tabelle als Array von Klassen synthetisiert.
Die Klassen generiere ich anhand des Schemas automatisch, wobei die vorhandene Tabelle und deren Daten gelöscht werden.
Jetzt benötige ich eine Tabelle für diverse Einstellungen, es ist noch nicht exakt absehbar, wieviele und es ist wahrscheinlich, dass die Anzahl wachsen wird.
Nun kann ich das in zwei Arten umsetzen:
- Eine Zeile pro Benutzer, es gibt dann Spalten wie sendeEmail, zeigeName, usw die alle als boolean existieren (Schema: user_id(pk), einstellung1, einstellung2, ...)
- Es gibt mehrere Zeilen pro Benutzer mit den Spalten type und value (Schema: id(pk), user_id(pk,fk), type, value)
pk: Primary key
fk: Foreign key
(nur für den Fall
)Zu 1
Vorteile:
Ein Primary key. Generierte Klasse "Setting" hat alle getter und setter der Einstellungen, das ermöglicht implizites Wissen über die Einstellungen, getSendeEmail, setSendeEmail, usw...
Query ist simpel, ich bekomme ein einziges Setting Objekt, Verwaltung muss alle getter durchgehen, um die Werte zu bekommen (kann automatisiert werden)
Nachteile:
Neue Einstellung erfordert Anpassung des Schemas, was in der Regel eine Neugenerierung der Tabellen erfordert->Datenverlusst. Ich muss manuell zusehen, dass evtl im Produktivbetrieb gemacht Einstellungen 'portiert' werden und neue Sachen defaulten.
Zu 2
Vorteile: Generische Erzeugung von neuen Einstellungen, Schema bleibt dadurch unverändert. Kein Datenverlust durch Neugenerierung, keine Portierung vorhandener Daten.
Nachteile: Kein implizites Wissen über Einstellungen, es gibt nur getType und getValue. Die Logik muss auf Appliktionsseite verwaltet werden. Probleme wie sendeEmail und sendeMail müssen explizit verhindert werden. Daraus folgt erschwerte Verwaltung. Zusammengesetztes Primary key aus id und user_id, alternativ auch type und user_id. Ich kriege ein Array von Setting Objekten (mehr Datentransfer und mehr Objekte, die durchs ORM müssen), die ich zusätzlich durch mehr Aufwand verarbeiten muss.
Ich tendiere im Moment, da in der Entwicklung zu Lösung 1. Ich bin relativ frei mit der Erzeugung neuer Einstellungen, da keine Benutzerdaten existieren. In Prod muss ich dann das neue Schema mit Alter Table ändern, um Daten nicht zu verlieren. Für ein langfristiges Projekt wie dieses ist das Schema auch die Dokumentation, ich kann nie vergessen, welche Einstellungen bereits drin sind.
Ich würde mich über ein paar Kommentare sehr freuen
Moderatorin
Kommentar