Multi-Tenancy mit Mandanten teilen Daten

Question

Ich bin gerade dabei, eine Webapp, die Abonnements als Multi-Tenant-App zu verkaufen. Die Technik, die ich verwende, ist Schienen.

Es wird jedoch nicht nur isoliert Mieter mit der aktuellen App sein.

Jeder Mieter erstellt Produkte und veröffentlicht sie auf ihrer persönlichen Instanz der App. Jeder Mieter hat seine eigene Nutzerbasis.

Die problematische Spezifikation ist, dass ein Mieter sein Produkt mit anderen Mietern teilen kann, damit sie es weiterverkaufen können.

Erläuterung:

Fruitshop verkauft Apfel Orangen und Tomaten.
VegetableShop verkauft Rettich und Pfeffer Bell.

Fruitshop teilen Tomaten zu anderen Geschäften.

VegetableShop entschließen sich, Tomaten aus der Liste der freigegebenen Artikel zu holen und sie zu ihrem Inventar hinzuzufügen.

Jetzt ein Kunde, der Gemüsehändler grast, sieht Rettich, Pfefferglocke und Tomaten.

Wie Sie erraten können, ein select products where tenant_id='vegetableshop_ID' wird nicht funktionieren.

ich mit irgendeiner Art von tenant_to_product Tisch zu viele Beziehung dachte eine viele tun, die tenant_id, product_id, price_id und sogar veröffentlichen beginnen-Enddaten haben würde. Und Produkte wären eine "halbvermietete Tabelle", in der die Mieter-ID durch mieter_creator_id ersetzt wird, um zu wissen, wer der ursprüngliche Eigentümer ist.

Für mich scheint es umständlich, Hinzufügen würde es komplexe Abfrage bedeuten, auch für den Laden nur ihre eigenen Produkte zu verkaufen. die verkauften Produkte erhalten würde kompliziert sein:

select tenant_to_products.* 
where tenant_to_products.tenant_ID='current tenant' 
AND (tenant_to_products.product match publication constraints) 

for each tenant_to_product do 
    # it will trigger a lot of DB call 
    Display tenant_to_product.product with tenant_to_product.price 

Un-Sharing ein Produkts auch einen komplexen Update modifiziert alle tenant_to_products Verweis auf das Original-Produkt bedeuten würde.

Ich bin mir nicht sicher, ob es eine gute Idee wäre, diese Beschränkung so zu implementieren, was schlagen Sie mir vor? Habe ich vor, etwas Dummes zu tun oder ist es eine nicht so schlechte Idee?

Answer 1

Sie werden eine kompliziertere Subskription für den Produktmechanismus benötigen, wie Sie bereits ausgearbeitet haben. Es klingt, als ob du auf dem richtigen Weg bist.

Die Informationen so weit wie möglich abstrahieren. Rufen Sie beispielsweise nicht die Tabelle "tenant_to_product" auf, sondern nennen Sie sie "tenant_relationships", und weisen Sie die Produkt-ID als Spalte in dieser Tabelle auf.

Dann, wenn der Mieter Dienste haben möchte, können Sie einfach eine Spalte zu dieser Tabelle "Service-ID" hinzufügen, ohne eine ganze zusätzliche Tabelle hinzufügen.

Für die Leistung können Sie einen schreibgeschützten Datenbankserver mit Mandantenbeziehungen haben, der mit einer leichten Verzögerung aktualisiert wird. Azure oder ähnliche Cloud-Dienste würden dies leicht machen. Dies ist jedoch wahrscheinlich nicht erforderlich, es sei denn, Sie sind in der Größenordnung von 1 Million + Benutzer.

Ich würde vorschlagen, Sie betrachten:

• aktiv/inaktiv (Gemüseläden bevorzugen vorübergehend zu stoppen Tomaten zu verkaufen, da sie im Moment ziemlich fehlerhaft sind, bis die Züchter mit ihnen einschließlich Bugs stoppen)

• Serverseitige Dienste für Benachrichtigungen, z. B. "productRemoved" -Dienst. Diese Dienste führen Änderungen im Batch-Verfahren durch und bieten dem Benutzer schnelleres Feedback.

• Löschen Sie keine Informationen, sondern setzen Sie die Spalten 'delete_date' und 'delete_user_id' oder ähnliches.

• Vollständiger Überwachungsverlauf von Änderungen an Produkten, Mandanten, Beziehungen usw. Diese Tabelle wird sehr groß. Vermeiden Sie es, von ihr zu lesen und sicherzustellen, dass Aktualisierungen asynchron sind, damit der Aufrufer nicht auf die Aktualisierung der Tabelle warten muss . Aber aus betriebswirtschaftlicher Sicht wird es wahrscheinlich sehr nützlich sein.

EDIT:

Diese Frage im Zusammenhang nützlich sein können, wenn Sie nicht schon gesehen: How to create a multi-tenant database with shared table structures?

Answer 2

Multi-Tenancy die offensichtliche Antwort scheint, wie Sie mehrere Clients bieten Ihre System.

Als Alternative, vielleicht eine Reseller "Service-Schicht" betrachten, würde dies ein gewisses Maß an Isolation ermöglichen, während immer noch Integration bietet. Lassen Sie sich dazu inspirieren, wie Reseller-Accounts mit Drittanbietern wie Amazon funktionieren.

Ich realisiere, dass dies sehr abstrakte Argumentation ist, aber vielleicht die Integration auf einer höheren Stufe als die Datenschicht könnte von Vorteil sein.

Aus der Erfahrung, die Multi-Tenancy auf Ebene der Datenebene streng durchzusetzen, haben wir festgestellt, dass das Mietverhältnis manchmal auf einer Business-Ebene (wie Ihre Reseller-Ideen) so manipuliert werden muss, dass das Mietverhältnis zu einem kniffligen Konzept wird. Alternativen frühzeitig zu berücksichtigen, könnte helfen.