2016-07-03 25 views
0

Ich habe eine grundlegende ERP-Webanwendung mit Django-Tenant-Schema gemacht. Jetzt ist mein Problem jedes Mal, wenn sich ein neuer Benutzer anmeldet, eine Ausfallzeit (wegen der Migration, die beim Erstellen eines neuen Schemas für jeden Benutzer hilft). Also, das ist sicherlich nicht skalierbar. Ich benutze psotgresql als meine Datenbank, Apache und DO.Skalierbarkeit von Django Tenant Schema

Gibt es eine mögliche Antwort auf dieses Weh?

Das Problem, mit dem ich konfrontiert bin, ist die Planung dieses ERP-System für mehrere KMU. Nun stellt jeder dieser KMU 10-15 Mitarbeiter ein, die alle über ein Konto verfügen, das vom Arbeitgeber mit der erforderlichen Erlaubnis erstellt wurde. Nun, ist das ohne Schema möglich? Fügen Sie dem Problem hinzu, jedes Mal einen sehr großen Tisch zu scannen.

Antwort

0

Ich schrieb eine Anwendung in Django/Postgres, die Multi-Tenant war. Die Technik, die ich verwendete, war:

1) jeden Mieter mit eindeutigen Anmeldeinformationen anmelden. 2) Jeder Mandant hat eine mandant_id 3) Jede Tabelle hat eine mandant_id 4) Erstellen Sie Ansichten in Postgres mit der Tenant_id für jede Tabelle. Wenn also ein Tenant aus einer Tabelle auswählt, sieht er alle Zeilen in dieser Tabelle, die zu ihrer Tenant-ID passen.

Das funktionierte ziemlich gut für mich. Sie haben Overhead hinzugefügt. Sie müssen eine Mieter-ID mit einer Sitzung verknüpfen. Sie müssen Ihrer Datenbank ein Schema hinzufügen, um die Ansichten für jede Tabelle zu erstellen, auf die der Mandanten Zugriff haben soll.

Dies hat den zusätzlichen Vorteil, dass Tabellen, die nicht mandantenspezifisch sind und schreibgeschützt sind, zwischen Mandanten gemeinsam genutzt werden können.

-g

+0

Also, wenn ich nicht falsch liege Greg, was du getan hast, war Multi-Tenant mit demselben Schema. Das habe ich anfangs gedacht. Aber das geht nicht gut mit meinem Anwendungsfall. Hier liegt das Problem. In meinem Fall wird die Komplexität hinzugefügt, wobei jeder Mieter mehrere Benutzer erstellen kann. Zum Beispiel, wenn jemand mein ERP benutzt, muss er Sub-Benutzer für verschiedene Module des ERP erstellen, wie eines für Accounts, eines für SCM, etc .. Es fügt also Komplexität hinzu, wenn das Schema nicht verwendet wird. – SG2791

+0

Ich hatte das gleiche Problem. Außerdem könnten meine Benutzer verschiedenen Mietern angehören. es funktioniert. Der Teil, den ich vermisse, ist, dass sie, obwohl sie das gleiche Schema haben, getrennt sind, als wären sie unterschiedliche Schemas. Sie erstellen die Trennung mit dem Login. Sie erinnern sich an die mandant_id und Ihre Anwendung greift über Views auf die db zu, die alles mit der richtigen tenant_id auswählt. Vielleicht ist es nicht passend für dich, dachte nur, ich würde es da rauswerfen. – Greg

+0

Vielen Dank Greg !! Sicherlich muss ich auch etwas in Ihren Zeilen nachdenken. Ich denke auch darüber nach, Migrationsschemas nur für neue Mieter durchzuführen. Wie Migration nur für ein Schema (die Art und Weise, wie Migrationsschema --public nur das öffentliche Schema migriert). Lassen Sie mich den Quellcode von django & d-t-s ausgraben und drücken Sie mir die Daumen – SG2791