Das deutsche Python-Forum

Hallo,

ich stehe vor dem Problem, dass ich heterogene Daten irgend wie in einer relationalen Datenbank abbilden muss. D.h., ich habe unterschiedlichste Domänenobjekte, die als Persistenz definitiv nur die Datenbank haben. Alternative Ansätze a la KV-Store für genau dieses Teilproblem scheiden also aus.

Die Daten sind im Grunde genommen Konfigurationsdaten, wie Kombinationen aus URL, Username und Passwort für einen Webservice, ein Dateiname für das Ablegen einer zu generierenden Datei usw. Hinzu kommen noch Wertebereiche für Auswahllisten und Defaultwerte.

Als Datenbanken kommen sowohl MS Access als auch MS SQL Server zum Einsatz, als Sprachen C# und C++ (wobei das nicht unbedingt relevant für das Konzept sein sollte)

Nun fallen mir spontan drei Lösungen ein:

1.) Separate Tabellen für die einzelnen Typen
2.) Key-Value-Tabelle mit gruppierenden IDs
3.) Daten serialisiert in XML, JSON o.ä. in einer Spalte speichern.

Lösung 1 klingt zunächst am sinnvollsten bezüglich des relationalen Konzepts. Nachteil ist, dass ich *eine* fixe ID benötige, die in allen sonst wie verstreuten Tabellen identisch sein muss, um von einem gemeinsamen Ausgangsobjekt die spezialisierten Teile laden und generieren zu können. An sich klingt das noch machbar, aber: Es soll auch die Möglichkeit bestehen, Vorgaben für Einheiten zu hinterlegen und beim Konfigurieren auswählbar zu machen. Wie bekommt man solche Datensätze in dieselbe Tabelle? Und die Vorgaben dürfen durchaus "Lücken" enthalten; ``NOT NULL`` constraints usw. müsste ich also weglassen oder separate Tabellen für die Vorlagen basteln (was auch wieder doppelte Pflege bedeutet usw)

Lösung 2 ist bedeutet definitiv das Aufweichen des relationalen Konzepts... will man solche Konfigurationen basierend auf einem Kriterium als Menge ablegen, müsste man dabei auch wieder Spalten hinzufügen, z.B. eine Login-Kombination pro Standort o.ä.

Lösung 3 bietet zunächst viel Flexibiltität und das Serialisieren gibt es (in C#) quasi gratis. Haken ist dabei, dass man später Formatänderungen nicht einfach durchführen kann (ohne spezielle Mechanismen zum Transformieren der abgelegten Daten). Zudem bietet Access afaik keine Hilfe beim Auslesen von XML-Daten an.

Habt ihr Erfahrungen damit, womit man letztlich am glücklichsten wird?

DB-Zugriffe müssen übrigens von Hand gecodet werden; es gibt also keinen ORM o.ä. (Und ja, das klingt an sich schon eklig)

ORMs ausser SQLAlchemy sind eh ueberbewertet

Am Ende musst du einen Tod sterben, und nur du kannst beurteilen, welchen. Denn es haengst schlicht von der Aenderungsfrequenz in der Domaene ab, ob sich Ansatz 1 oder 3 anbieten. Ansatz 2 habe ich selbst auch schon gewaehlt, aber der ist im Grunde das Eingestaendnis "nix genaues weiss man nicht", und nur dann gerechtfertigt, wenn du mit SQL sinnvoll auf die Daten zugreifen musst. Sinnvoll heisst hier, dass du beliebige SQL-Abfragen erlauben moechtest, die irgendwie ueber die Daten aggregieren - danach klingt dein Problem aber nicht. Bei mir war es usage-reporting, da war so eine Struktur schon sinnvoll - wenn auch schmerzhaft, und oft benoetigte und beliebte Eigenschaften sind dann in eigene Spalten gewandert.

Ich wuerde darob erstmal fuer 1 plaedieren - sei praeziese, nutz die DB wofuer sie gut ist.

@Hyperion:
Ich würde das davon abhängig machen, inwiefern die Relationen wichtig sind. Wenn Du häufig mit Subentitäten hantieren musst, macht die Normalisierung Sinn. Sind die Eigenschaften sehr dünn besetzt, hilft evtl. das EAV-Modell, den relationalen Ansatz mit moderater DB-Komplexität zu retten.
Spielen einzelne/benachbarte Subentitäten keine Rolle, ist der "Dokument-Blob"-Ansatz DB-seitig sehr viel einfacher und schneller umsetzbar.

Die Transformationssache würde ich nicht als Argument für oder gegen einen gewählten Weg sehen, da dies immer nötig ist, wenn das Schema nicht mehr passt.