none
Designfrage: Datenbank pro Unternehmen oder eine Datenbank für alle Unternehmen

    Frage

  • Guten Abend,

    ich habe eine Anwendung, welche Dienste für Unternehmen anbietet. Dabei verwaltet eine Webanwendung mehrere Unternehmen. Um den Dienst für die Unternehmen bereitzustellen, wird eine Datenbank mit verschiedenen Tabellen benötigt. U.a. können auch in manchen Tabellen eigene Spalten vom Unternehmen, bzw. von einem Mitarbeiter des Unternehmens erstellt werden (z.B. eine Erweiterung der Kundendatentabelle). Sollte ich jetzt für jedes Unternehmen eine eigene Datenbank erstellen, oder sollte ich trotz der Anforderung, eigene Spalten zu definieren, die gleiche Datenbank verwenden (und wenn ja, wie)?

    Bei mehreren Datenbanken würde ich für jedes Unternehmen eine neue Datenbank mit dem Namen der Organisationsid erstellen, welche dann dynamisch aus der Webanwendung verwendet wird. Wäre das konzeptionell so in Ordnung?

    Mit freundlichen Grüßen,

    Bodenseecoder

    Mittwoch, 17. Januar 2018 17:30

Antworten

  • Hi,

    welches Modell Du wählst, hängt stark von deinen Anforderungen ab.

    Ein mandantenfähiges System (mit einer entsprechend aufgebauten Datenbank) ist sicherlich sinnvoll, um eben zu vermeiden, dass man x Instanzen bzw. Datenbanken (mit dem entsprechenden Aufwand für Updates, ...) vorhalten muss.

    Andererseits muss man hier natürlich auch auf die Datensicherheit achten, damit nicht auf einmal Kunde A Daten von Kunde B zu sehen bekommt. Aber Sicherheit sollte eh eines der wichtigsten Themen sein.

    Da Du angibst, dass die Kunden ihre Tabellenstruktur selbst erweitern können (was ich nicht empfehlen würde, dann eher eine Tabelle mit kundenindividuellen Datensätzen für die Metadaten der entsprechenden Felder) wäre es aber wohl eher angebracht, eigene Datenbanken zu verwenden, da die Spalten dann auch schnell kollidieren und es schnell passieren kann, dass Du die maximale Spaltenanzahl pro Tabelle erreichst.

    Bzgl. der Idee mit den Metadaten: Hier würde ich bspw. eine Tabelle wie folgt aufbauen:

    [CustomFields]
    ID           int PK
    CustomerId   int FK
    TargetObject int|nvarchar
    Name         nvarchar
    Description  nvarchar
    DataType     int
    MaxLength    int
    ...

    Dort kannst Du dann die Feldinformationen ablegen und dem Kunden in seinen Eingabemasken zur Verfügung stellen.

    Eine Adhoc Änderung der Datenbank würde ich tunlichst unterlassen. Zudem müsstest Du diese Spalten ja irgendwo auch in deiner Anwendung mal ansprechen, bei Nutzung von O/R Mappern wie dem Entity Framework müsstest Du dafür deine Anwendung erweitern, neu kompilieren, usw. Macht eigentlich wenig bis gar keinen Sinn.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    • Als Antwort markiert Bodenseecoder Mittwoch, 17. Januar 2018 19:08
    Mittwoch, 17. Januar 2018 17:45
    Moderator

Alle Antworten

  • Hi,

    welches Modell Du wählst, hängt stark von deinen Anforderungen ab.

    Ein mandantenfähiges System (mit einer entsprechend aufgebauten Datenbank) ist sicherlich sinnvoll, um eben zu vermeiden, dass man x Instanzen bzw. Datenbanken (mit dem entsprechenden Aufwand für Updates, ...) vorhalten muss.

    Andererseits muss man hier natürlich auch auf die Datensicherheit achten, damit nicht auf einmal Kunde A Daten von Kunde B zu sehen bekommt. Aber Sicherheit sollte eh eines der wichtigsten Themen sein.

    Da Du angibst, dass die Kunden ihre Tabellenstruktur selbst erweitern können (was ich nicht empfehlen würde, dann eher eine Tabelle mit kundenindividuellen Datensätzen für die Metadaten der entsprechenden Felder) wäre es aber wohl eher angebracht, eigene Datenbanken zu verwenden, da die Spalten dann auch schnell kollidieren und es schnell passieren kann, dass Du die maximale Spaltenanzahl pro Tabelle erreichst.

    Bzgl. der Idee mit den Metadaten: Hier würde ich bspw. eine Tabelle wie folgt aufbauen:

    [CustomFields]
    ID           int PK
    CustomerId   int FK
    TargetObject int|nvarchar
    Name         nvarchar
    Description  nvarchar
    DataType     int
    MaxLength    int
    ...

    Dort kannst Du dann die Feldinformationen ablegen und dem Kunden in seinen Eingabemasken zur Verfügung stellen.

    Eine Adhoc Änderung der Datenbank würde ich tunlichst unterlassen. Zudem müsstest Du diese Spalten ja irgendwo auch in deiner Anwendung mal ansprechen, bei Nutzung von O/R Mappern wie dem Entity Framework müsstest Du dafür deine Anwendung erweitern, neu kompilieren, usw. Macht eigentlich wenig bis gar keinen Sinn.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    • Als Antwort markiert Bodenseecoder Mittwoch, 17. Januar 2018 19:08
    Mittwoch, 17. Januar 2018 17:45
    Moderator
  • Hallo,

    Mehr-Mandantenfähige Datenbanken sind durchaus gängig, z.B. im Bereich ERP Software; da wird aber meistens die Datenbank von einem Unternehmen mit mehreren Filialen oder Firmierungen.

    Eine Datenbanken für viele unterschiedliche Unternehmen hat in der Praxis ein paar Nachteile:
    - Ein kleiner Programmfehler oder ein fehlender Filter auf die OrganisationID und schon liefern Auswertungen falsche Daten; schlimmer noch Unternehmen A sieht auch die Daten von Unternehmen B.
    - Bei einem Unternehmen werden durch einen Fehler Daten gelöscht und ein Restore des Backups der letzten Nacht ist nötig; dann werden die Daten von allen Unternehmen auf einen alten Stand zurückgesetzt.
    - Eine Unternehmen will die Daten z.B. für sein DWH abziehen; ob der immer brav auf die richtige ID filtert?

    Eine DB je Unternehmen ist da prakmatischer, einfacher und sicherer.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Mittwoch, 17. Januar 2018 17:50
  • Hi,
    ich kann mich nur den anderen anschließen.

    Unbedingt pro Mandant eine separate Datenbank mit eigenem Rechtesystem. Daten über Mandantenindex in jeder Tabelle zu verwalten, bringt früher oder später Probleme, vor allem Sicherheitsprobleme. Außerdem ist der gesamte Programmier- und Testaufwand nicht zu unterschätzen. Die dafür erforderlichen Kapazitäten sollten besser in die Verwaltung der Mandantendatenbanken gesteckt werden.

    Außerdem sollte das Datenbankschema "fest" sein und nicht durch den Kunden erweiterbar sein. Zusätzliche Eigenschaften und deren Werte sollten so wie von Stefan beschrieben in separaten Tabellen verwaltete werden. 


    --
    Viele Grüsse
    Peter Fleischer (ehem. MVP)
    Meine Homepage mit Tipps und Tricks

    Mittwoch, 17. Januar 2018 19:24