Wege optionale Eigenschaften zu speichern

[openshinok]

hallo,
ich erstelle gerade eine neue Datenbank. Die spätere Applikation soll vielleicht später mal Mandantenfähig sein. Bleiben wir beim Beispiel dass ich Aufträge speichern möchte.

Ich möchte Eigenschaften für diesen Auftrag speichern können. Die zu speichernden Eigenschaften können sich im Datentyp unterscheiden. Nicht jeder Mandant hat die gleichen Eigenschaften. Das heißt für mich, einfach gedacht, dass ich in der Tabelle Auftrag Felder für alle Eigenschaften vorsehen muss. Hätte wieder zur Folge dass ich bei einigen Mandaten überflüssige Felder nie fülle da die Funktionalität nicht benötigt wird.

Wie kann ich diesen Fall lösen? Der Mandant soll die Möglichkeit haben nach diesen Eigenschaften filtern zu können, auch in der Kombination.

[hwoess]

Vielleicht sollte man Kunden und Mandanten speziell auseinanderhalten, da u.U. ja ein Kunde eine mandantenfähige Datenbank braucht und man Unterscheidungen nicht nur zwischen Mandanten sondern auch zwischen Kunden haben können sollte. Ich habe dazu Parameterdateien, sowohl mit kundespezifischen Daten (Lizenzkey, freigeschaltetet Funktionen usw.) als auch für mandantenbezogene Eigenschaften, die dann vom Kunden verwaltet werden.
Klarerweise macht das die Sache nicht einfach, da ich zB kundenbezogene Abrechnungsläufe in den stored procs habe als auch procs, die mit mandantenbezogenen Definitionen arbeiten müssen.
Und in der Applikation richten sich natürlich die Fenster auch nach den freigeschalteten Funktionen, wobei manche Fenster sich sogar auf Feldebene für verschiedene Kunden unterschiedlich darstellen. Ist einfach viel Programmieraufwand, da etwa drei Viertel meiner Software Standard sind und ein Viertel bei jedem Kunden separat angepasst werden muss. Habe noch keinen einfachen Weg dafür gefunden. Einfach immer versuchen in Modulen mit Schnittstellen zu arbeiten, damit spätere Adaptierungen leichter fallen.

bye,
Helmut

[O. Helper]

Die spätere Applikation soll vielleicht später mal Mandantenfähig sein

Das sollte man frühzeitig überlegen, da es sich doch stark aufs DB-Design auswirkt. Werden zusammengesetzte PK verwendet, wie Mandat+Artikelnummer oder ein Surrogate Key (Identity); wenn dann ein Mandant in eine andere DB verschoben werden soll, müssen alle PK umgesetzt werden. Geht, stellt aber Aufwand dar.

Die zu speichernden Eigenschaften können sich im Datentyp unterscheiden

Wie willst Du das in der Anwendung handhaben; Du kannst dann eigentlich nicht mehr Typ-sicher arbeiten und muss alles selbst validieren.

[openshinok]

hallo,
ich führe bei allen relevanten Tabellen die MandantenID mit, jede Tabelle hat einen eigenen int Primärschlüssel. Im Fall Artikel speichere ich die Artikelnummer in einem nvarchar-Feld, so kann ich alphanumerische Matchcodes speichern. Also tbl_Artikel: ArtikelID, MandantID, Artikelnummer, Bezeichnung, usw..

Jaaaa so insgesamt ist das genau zu überlegen... Bei Statitabellen ist schon die nächste Überlegung anzustellen, normalerweise Stati für alle gleich ohne MandantID, was aber wenn einer nen anderen Status braucht oder einen Zwischenstatus oder sogar einen allgemeinen ausblenden muss.


Ich dachte evtl. daran die eigenschaften in einer anderen Tabelle zu speichern und pro Mandant und ggf. Tabelle diese Eigenschaften zu definieren. In der Definition würde ich den "Feldnamen" bzw. Eigenschaftsnamen hinterlgen, sowie einen regulären Ausdruck der mir die Daten prüft. Weiterhin für welche Tabelle ich die Eigenschaft setzen kann. Die Daten würde ich dann in einer Tabelle speichern in der der eigentliche Wert als NVARCHAR(MAX) abgelegt wird. MandantID, EigenschaftID, EigenschaftWert.

So wie MS das mit den Sharepointlisten macht finde ich das auch interessant, hier kann der Benutzer ja auch selbst Felder anlegen. Allerdings müsste ich mir erst mal eine Sharepoint Datenbank anschauen wie das gelöst wird. Vermute mal mit xml-Feldern....