Allerdings gibt es natürlich einige Unternehmen, die befürchten, dass ihre Daten kompromittiert werden könnten, daher evaluieren wir andere Lösungen.
Dies ist bedauerlich, da Kunden manchmal unter dem Missverständnis leiden, dass nur eine physische Isolation ausreichende Sicherheit bieten kann.
Es gibt einen interessanten MSDN-Artikel mit dem Titel Mehrinstanzenfähige Datenarchitektur , die Sie vielleicht überprüfen möchten. So gingen die Autoren auf das Missverständnis bezüglich des gemeinsamen Ansatzes ein:
Ein weit verbreiteter Irrglaube besagt, dass nur physische Isolation ein angemessenes Maß an Sicherheit bieten kann. Tatsächlich können Daten, die mit einem gemeinsamen Ansatz gespeichert werden, auch eine hohe Datensicherheit bieten, erfordern jedoch die Verwendung ausgefeilterer Entwurfsmuster.
In Bezug auf technische und geschäftliche Überlegungen enthält der Artikel eine kurze Analyse, wo ein bestimmter Ansatz geeigneter sein könnte als ein anderer:
Die Anzahl, Art und Bedürfnisse der Mandanten, die Sie bedienen möchten, wirken sich alle auf unterschiedliche Weise auf Ihre Datenarchitekturentscheidung aus. Einige der folgenden Fragen könnten Sie zu einem eher isolierten Ansatz verleiten, während andere Sie zu einem eher gemeinsamen Ansatz verleiten könnten.
-
Wie viele Mietinteressenten erwarten Sie? Sie sind vielleicht noch lange nicht in der Lage, die voraussichtliche Nutzung zuverlässig einzuschätzen, aber denken Sie in Größenordnungen:Erstellen Sie eine Anwendung für Hunderte von Mietern? Tausende? Zigtausende? Mehr? Je größer Sie Ihren Mieterstamm erwarten, desto wahrscheinlicher werden Sie einen stärker geteilten Ansatz in Erwägung ziehen.
-
Wie viel Speicherplatz belegen Ihrer Meinung nach die Daten eines durchschnittlichen Mandanten? Wenn Sie davon ausgehen, dass einige oder alle Mandanten sehr große Datenmengen speichern, ist der Ansatz mit separaten Datenbanken wahrscheinlich am besten. (Anforderungen an die Datenspeicherung können Sie sogar dazu zwingen, ein Modell mit separater Datenbank zu verwenden. Wenn dies der Fall ist, ist es viel einfacher, die Anwendung von Anfang an auf diese Weise zu entwerfen, als später zu einem Ansatz mit separater Datenbank überzugehen.)
-
Wie viele gleichzeitige Endbenutzer wird Ihrer Meinung nach der durchschnittliche Mandant unterstützen? Je größer die Zahl, desto angemessener ist ein isolierterer Ansatz, um die Anforderungen der Endbenutzer zu erfüllen.
-
Erwarten Sie, Mehrwertdienste pro Mandant anzubieten, z. B. Sicherungs- und Wiederherstellungsfunktionen pro Mandant? Solche Dienste sind durch einen isolierteren Ansatz einfacher anzubieten.
AKTUALISIERUNG: Weitere Informationen zur erwarteten Mieterzahl.
Diese erwartete Anzahl von Mandanten (10.000) sollte den Ansatz mit mehreren Datenbanken für die meisten, wenn nicht alle Szenarien ausschließen. Ich glaube nicht, dass Ihnen die Idee gefallen wird, 10.000 Datenbankinstanzen zu verwalten und jeden Tag Hunderte von neuen erstellen zu müssen.
Allein aufgrund dieses Parameters sieht es so aus, als wäre der Ansatz mit gemeinsamer Datenbank und einem einzigen Schema am besten geeignet. Die Tatsache, dass Sie nur etwa 50 MB pro Mandant speichern und dass es keine Add-ons pro Mandant geben wird, macht diesen Ansatz noch angemessener.
Der oben zitierte MSDN-Artikel erwähnt drei Sicherheitsmuster, die Sicherheitsüberlegungen für den Shared-Database-Ansatz angehen:
Wenn Sie von den Datensicherheitsmaßnahmen Ihrer Anwendung überzeugt sind, können Sie Ihren Kunden ein Service Level Agreement anbieten die starke Datensicherheitsgarantien bietet. In Ihrem SLA könnten Sie neben den Garantien auch die Maßnahmen beschreiben, die Sie ergreifen würden, um sicherzustellen, dass Daten nicht kompromittiert werden.
AKTUALISIERUNG 2: Anscheinend sind die Microsoft-Leute zu diesem Thema umgezogen / haben einen neuen Artikel erstellt, der ursprüngliche Link ist weg und das ist der neue:Mandantenfähige SaaS-Datenbank-Mandantenmuster (Huldigung an Shai Kerer)
