Design-"Bauchschmerzen"

[asc]

Ich hänge derzeit an einem Softwaredesign das mir ein paar Bauchschmerzen bereitet, auch wenn ich aktuell nicht eine bessere Lösung finde. Das Problem ist auch das es nicht nur die eigentliche Softwareseite sondern auch das Datenbankdesign betrifft (Ich habe aber die Freiheiten beide Seiten anzupassen).

Fang ich erst einmal mit dem historisch gegebenen an. Wir haben eine Software mit der man u.a. Planungen durchführen kann (Im wesentlichen eine Art Terminkalender mit Konfliktprüfungen, die man aber optional und bewusst deaktivieren kann...). Die in der Planung verwendeten Objekte werden Ressourcen genannt, teilen sich eine gemeinsame eindeutige Kennung (DB-Id) und ein paar Eigenschaften, sind aber im Aufbau ansonsten stark unterschiedlich.

Aus DB-Sicht (Objektmodell ist ähnlich) sieht das ganze etwa wie folgt aus (Ich benenne es etwas Anders um die Begriffe möglichst allgemeiner verständlich zu halten:

[Ressource]1 - *[Terminressource]* - 1[Termin]
                  [-Id      ]     [-IdRessource   ]     [-Id   ]
                       ^          [-IdTermin      ]
                       |
           /-----------+----------\ <-- "Vererbung", Pro Element eine Ressource
           |           |          |     die sich die Id teilt.
       [Person]      [Raum]     [...]

Soweit komme ich damit noch zurecht. Dann führten wir ein recht feingliedriges Rechtekonzept ein, das nach kurzer Zeit weiter verfeinert werden musste, und zwar auf ebene der Ressourcen. Um es einigermaßen hantierbar zu halten, hatten wir nicht die Ressourcen selbst sondern "Tags"/Schlagwörter verwendet (Nach dem Motto: der Benutzer A darf nur Personen bearbeiten, denen als Schlagwort XYZ zugeordnet ist).

Des weiteren kamen noch benutzerdefinierte Zusatzfelder etc. auf Ressourcenebene hinzu. Es ist auch nicht abzusehen was sonst noch als "Erweiterungen" dazu kommen mag.

Nun muss das ganze aber massiv ausgeweitet werden. Nahezu jedes Stammdatum (ggf. auch über die eigentlichen Stammdaten hinaus) soll nun verschlagwortet werden, Zusatzdaten sollen mehrere davon erhalten können...

In der Theorie kein Problem, man könnte die obige Hirachie natürlich erweitern (was derzeit für einzelne weitere Typen auch schon passiert ist), und sagen alles ist eine Ressource (wobei der Begriff nicht ganz passt). Ich habe bei dem ganzen aber einige Bauchschmerzen.

Das fängt bei mir schon dann an, wenn ich für eine Klasse keinen gescheiten Namen mehr finde. Ressource passt nicht mehr, nicht alles davon sind Ressourcen. "Objekt" finde ich ein "Design Smell", sprich für mich ist das ganze nicht mehr wirklich "greifbar" was gemeint ist.

Und dann stellt sich auch die Frage, ob es für eine Datenbank wirklich noch ein gutes Design ist, wenn nahezu jede zweite Tabelle von genau einer anderen "abgeleitet" ist. Mir sind aber noch keine Alternativen eingefallen (zumal "logikarme" Clientdatenbanken wie SQL Server Compact noch nicht ganz ausgeschlossen werden)...

[Zeus]

Sollen dir Art der Ressource konfigurierbar sein?

[asc]

Zeus schrieb:

Sollen dir Art der Ressource konfigurierbar sein?

Nur in sofern welche "Erweiterungen" tatsächlich erzwingend (Pflicht), optional oder für diesen Typ nicht erlaubt sind. Es ist aber im Vorfeld bekannt welche überhaupt davon betroffen sein könnten (und das sind eigentlich alle Stammdaten + ggf. ein paar Datensätze darüber hinaus)