Ein SaaS-Abonnementdatenmodell

SaaS (Software as a Service) ist eine der drei Hauptkomponenten des Cloud Computing. Normalerweise sind SaaS-Anwendungen webbasiert und können viele verschiedene Benutzer gleichzeitig bedienen. Abonnementbasierte Lösungen sind sehr beliebte SaaS-Angebote. Einige bekannte SaaS-Produkte sind Microsoft Office 365, Amazon Web Services (AWS), Slack, Jira, Stripe und (natürlich) Vertabelo! Heute werfen wir einen Blick auf ein Datenmodell, mit dem wir SaaS-Abonnements verwalten können.

Die Idee

SaaS-Produkte können sehr unterschiedlich sein. Einige berechnen ihre Dienste regelmäßig, z. monatlich oder jährlich; andere berechnen nur die Zeit oder die verbrauchten Ressourcen (oder eine Kombination aus diesen beiden). Um die Dinge in diesem Artikel einfach zu halten, konzentriere ich mich nur auf monatlich bezahlte Abonnements.

Nehmen wir an, wir haben ein paar verschiedene SaaS-Lösungen und müssen alle unsere Abonnenten in einer Datenbank verfolgen. Dies könnte der Fall sein, wenn wir Datenbanklösungen (z. B. Amazon DynamoDB), Analysetools (z. B. Amazon Athena) oder Robotikanwendungen (z. B. AWS RoboMaker) anbieten. Wenn wir uns Amazon ansehen, sehen wir tatsächlich, dass es viele verschiedene Anwendungen gibt. Wir würden nur diejenigen auswählen, die wir wirklich brauchen.

Datenmodell

Das Modell besteht aus drei Themenbereichen:

• Users & groups
• Software & plans
• Subscriptions, plans & payments.

Wir beschreiben jeden dieser Themenbereiche in der Reihenfolge, in der sie aufgeführt sind.

Abschnitt 1:Benutzer und Gruppen

Die Users & groups Themenbereich speichert Informationen über alle Benutzer unserer Anwendung. Wir gehen davon aus, dass Benutzer gruppiert werden können, z. B. wenn ein Unternehmen Lizenzen für mehrere Mitarbeiter kaufen möchte. Wir erstellen eine Gruppe, auch wenn nur ein Benutzer ihr angehört. Dies gibt uns die Flexibilität, dieser Gruppe später neue Mitglieder hinzuzufügen.

Die wichtigste Tabelle hier ist das user_account Tisch. Wir verwenden es, um alle Details zu Benutzerkonten zu speichern. Diese sind:

• first_name & last_name – Vor- und Nachname des Benutzers. Bitte beachten Sie, dass jeder hier gespeicherte Benutzer eine Privatperson ist.
• user_name – Ein Benutzername (vom Benutzer gewählt).
• password – Ein Hashwert des Passworts des Benutzers. (Benutzer legen ihre eigenen Passwörter fest.)
• email – Die E-Mail-Adresse des Benutzers, die während des Registrierungsprozesses festgelegt wurde.
• confirmation_code – Der Code, der während des E-Mail-Bestätigungsprozesses verwendet wird.
• confirmation_time – Wann die Registrierung/Bestätigung abgeschlossen wurde.
• insert_ts – Der Zeitstempel, als dieser Datensatz ursprünglich eingefügt wurde.

Benutzer können Gruppen erstellen; Gruppen haben vordefinierte Typen. Eine Liste aller möglichen Gruppentypen ist im user_group_type Tisch. Jeder Typ wird EINZIGARTIG durch seinen type_name definiert . Wir definieren auch die minimale und maximale Anzahl von Gruppenmitgliedern, die für jeden Gruppentyp zulässig sind. Dieser Bereich wird mit zwei Werten definiert – members_min (die untere Grenze) und members_max (die obere Grenze).

Beim Erstellen eines neuen Kontos wählen Benutzer auch ihre Benutzergruppe aus. Dadurch wird ein neuer Datensatz in der user_group Tabelle, die auf den ausgewählten Gruppentyp verweist und den Zeitstempel speichert (insert_ts ), als dieser Datensatz eingefügt wurde. Die customer_invoice_data -Attribut ist eine Textbeschreibung dessen, was wir auf die Rechnung für diese Benutzergruppe drucken werden.

Die letzte Tabelle in diesem Themenbereich ist in_group Tisch. Für jede Gruppe speichern wir eine Liste aller ihrer Mitglieder. Neben Verweisen auf die Benutzergruppe (user_group_id ) und Benutzerkonto (user_account_id ), speichern wir auch den Zeitstempel, wann ein Benutzer zur Gruppe hinzugefügt wurde (time_added ) oder aus der Gruppe entfernt (time_removed , die nur dann einen Wert enthält, wenn der Benutzer entfernt wurde). Wir haben auch ein Flag, um anzuzeigen, ob der Benutzer der group_admin ist oder nicht. Gruppenadministratoren können Gruppenmitglieder aktualisieren und neue Mitglieder hinzufügen.

Abschnitt 2:Software und Pläne

Als nächstes müssen wir alles definieren, was wir unseren (potenziellen) Kunden anbieten werden. Wir bieten möglicherweise nur eine Art von Software an, aber es besteht die Möglichkeit, dass wir mehrere verschiedene Angebote haben. Ein gängiges Beispiel für diesen Fall ist ein SaaS-Tool, das von seiner Analyseanwendung getrennt ist, z. Stripe und Stripe-Sigma. Wir werden solche Fälle in unserem Datenmodell abdecken.

Wir beginnen mit der software Tisch. In diesem Wörterbuch speichern wir eine Liste aller unserer SaaS-Angebote. Für jeden speichern wir:

• software_name – Ein EINZIGARTIGER Softwarename.
• details – Alle Details, die diese Software beschreiben.
• access_link – Ein Ort oder Link, wo wir auf diese Software zugreifen können.

Wir sollten in der Lage sein, unsere SaaS-Lösungen in einem oder mehreren verschiedenen Plänen anzubieten. Jeder Plan enthält verschiedene Optionen. Zum Beispiel könnten wir einen Premium-Plan haben, der alle von uns angebotenen Optionen enthält, und einen Basis-Plan, der nur das Wesentliche enthält. Wir speichern alle unterschiedlichen Pläne im plan Tisch. Für jeden Plan definieren wir:

• plan_name – Der Name, den wir für diesen Plan ausgewählt haben. Zusammen mit dem Verweis auf die Software (software_id ), bildet dies den alternativen/EINZIGARTIGEN Schlüssel dieser Tabelle.
• user_group_type_id – Eine Referenz, die den Typ der Gruppe angibt, die diesen Plan verwenden kann. Dies kann eine Einzelbenutzergruppe oder eine Standardgruppe sein. Diese Referenz definiert auch die maximale Anzahl von Gruppenmitgliedern für diesen Plan – z. Wenn unser Plan fünf verschiedene Konten für ein Abonnement zulässt, sollten wir auf den entsprechenden user_group_type verweisen .
• current_price – Der aktuelle Preis für diesen Plan.
• insert_ts – Der Zeitstempel, als dieser Datensatz eingefügt wurde.
• active – Ein Flag, das angibt, ob dieser Plan aktiv ist oder nicht.

Wir haben bereits erwähnt, dass Pläne für dieselbe Software unterschiedliche Optionen enthalten. Eine Liste aller unterschiedlichen Optionen wird in option Wörterbuch. Jede Option wird EINZIGARTIG durch ihren option_name definiert .

Um verschiedenen Plänen Optionen zuzuweisen, verwenden wir den option_included Tisch. Es speichert Verweise auf den zugehörigen Plan (plan_id ) und Option (option_id ). Dieses Paar zusammen mit dem date_added Attribut, bildet den UNIQUE-Schlüssel dieser Tabelle. Das date_removed Das Attribut enthält nur dann einen Wert, wenn wir uns entschieden haben, eine bestimmte Option aus einem Plan zu entfernen. Dies könnte passieren, wenn wir eine neue Option erstellen, um die alte zu ersetzen, oder wenn wir uns entscheiden, eine bestimmte Option nicht mehr zu haben, weil nur wenige Leute sie verwenden.

Der letzte Teil dieses Themenbereichs bezieht sich auf Sonder- oder Werbeangebote. Im Allgemeinen bieten solche Angebote den Kunden mehr Service für weniger Geld und gelten für eine bestimmte Zeit. Sie könnten darauf abzielen, neue Kunden zu gewinnen oder Plan-Upgrades (oder eine breitere Palette von Dienstleistungen) an bestehende Kunden zu verkaufen.

Alle unsere Werbeangebote sind im offer Tisch. Für jedes Angebot müssen wir Folgendes definieren:

• offer_name – Ein EINZIGARTIGER Name, den wir für dieses Angebot ausgewählt haben.
• offer_start_date und offer_end_date – Der Zeitraum, in dem dieses Angebot verfügbar ist.
• description – Eine ausführliche Textbeschreibung des Angebots.
• Rabatte:Wir brauchen die Flexibilität, zwei Arten von Rabatten zu haben – einen auf einem festen Betrag basierenden Rabatt (z. B. 50 $ Rabatt) und einen prozentualen Rabatt (z. B. 25 % sparen). Wenn wir einen festen Rabatt anbieten, fügen wir diesen Wert in den discount_amount ein Attribut; Wenn wir einen prozentualen Rabatt anbieten, fügen wir diesen Prozentsatz in discount_percentage ein Attribut.
• Dauer:Wir verwenden hier dieselbe Logik wie bei den Rabatten. In einigen Fällen gelten Angebote für eine festgelegte Anzahl von Monaten (z. B. für 24 Monate nach Anmeldung des Kunden); in diesen Fällen definieren wir die duration_months Wert. Andere Angebote gelten bis zu einem bestimmten festen Datum (z. B. bis 31.12.2019); für diese definieren wir das Datum und speichern es im duration_end_date Attribut.

Wir werden die verbleibenden zwei Tabellen in diesem Themenbereich verwenden, um zu definieren, was jedes Angebot enthält und welche Voraussetzungen es hat. Zu diesem Zweck verwenden wir zwei Tabellen:include und prerequisite . Sie haben dieselbe Struktur und enthalten dasselbe EINZIGARTIGE Paar offer_id – plan_id . Einige Angebote haben möglicherweise keine Voraussetzungen, während andere – z. wenn wir einen Rabatt für das Upgrade auf einen Plan mit mehr Benutzern oder ein Softwareabonnement für Benutzer einer anderen Software anbieten.

Angebote können komplex sein, daher gebe ich einige Beispiele.

1. Wenn wir derzeit Plan A verwenden und ein Angebot für ein Upgrade auf Plan B haben, ist dies unkompliziert.
2. Wenn wir zwei Angebote haben, „Upgrade von Plan A auf Plan B“ und „Upgrade von Plan B auf Plan C“, sollten wir ein weiteres Angebot erstellen:„Upgrade von Plan A direkt auf Plan C“. Dies ermöglicht es Benutzern, ihre Pläne in einem statt in zwei Schritten zu aktualisieren. Ein Beispiel für ein solches Upgrade ist die Änderung eines Abonnements, das derzeit fünf Benutzer pro Gruppe zulässt, in eines, das 20 Benutzer pro Gruppe zulässt, ohne dabei bei einem Zwischenplan mit zehn Benutzern pro Gruppe anzuhalten.
3. Wenn eine Gruppe Produkt A verwendet, könnten wir ein Sonderangebot haben, um die Produkte B und C zu einem Aktionspreis zu abonnieren. Wir könnten auch zwei separate Angebote haben, um nur Produkt B und nur Produkt C zu abonnieren.

Im Allgemeinen sollten wir ein Angebot haben, das den aktuellen Plan ohne Zwischenschritte in den gewünschten Plan umwandelt, und nur ein Angebot, um ein oder mehrere neue Produkte zu abonnieren.

Abschnitt 3:Abonnements, Pläne und Zahlungen

Der letzte Themenbereich verbindet die beiden zuvor genannten Bereiche und ist das eigentliche Herzstück dieses Modells.

Alle Abonnements werden im subscription Tisch. Wir behandeln jeden einzelnen Plan als separates Abonnement, auch wenn diese Abonnements/Pläne das Ergebnis desselben Angebots sind. Der Grund dafür ist, dass wir Abonnements separat verwalten können – z. stornieren sie separat, wenn wir wollten. Wir müssen hier einige Details definieren:

• user_group_id – Die ID der Gruppe, die diesen Plan abonniert. Dies ist wichtig, da Benutzer nicht einzeln abonniert werden; sie werden indirekt als Teil der Gruppe abonniert.
• trial_period_start_date und trial_period_end_date – Die unteren und oberen Grenzen des Testzeitraums (falls vorhanden) für dieses Abonnement.
• subscribe_after_trial – Ein Flag, das angibt, ob das Abonnement nach Ablauf des Probezeitraums (falls vorhanden) automatisch verlängert wird.
• current_plan_id – Der aktuelle Plan für dieses Abonnement. Wenn das Abonnement nicht mehr aktiv ist, enthält dieses Attribut den Wert des letzten aktiven Plans.
• offer_id – Ein Hinweis auf das Angebot, auf das sich dieses Abonnement bezieht. Dieses Attribut enthält nur dann einen Wert, wenn dieses Abonnement das Ergebnis eines bestimmten Angebots war.
• offer_start_date und offer_end_date – Die untere und obere Grenze des Zeitraums, in dem dieses Angebot aktiv war. Diese Attribute werden nur definiert, wenn dieses Abonnement das Ergebnis eines bestimmten Angebots war.
• date_subscribed – Wann diese Gruppe dieses Abonnement abonniert hat.
• valid_to – Das letzte Datum, an dem dieses Abonnement gültig ist. Bei einem monatlichen Abonnement können wir davon ausgehen, dass valid_to wird auf das Ende des laufenden Monats gesetzt. Wenn ein Kunde das Abonnement zu irgendeinem Zeitpunkt während eines Monats abbestellt, kann er seine Software noch bis zum Ende des Monats verwenden.
• date_unsubscribed – Das Datum, an dem diese Gruppe dieses Abonnement gekündigt hat. Wir können davon ausgehen, dass dieses Datum vom Gruppenadministrator manuell festgelegt wird, wenn die Gruppe beschließt, den Dienst nicht mehr zu nutzen. Es könnte aber auch automatisch nach vordefinierten Kriterien gesetzt werden – z.B. Automatische Abmeldung einer Gruppe von ihrem Dienst, wenn zwei oder mehr unbezahlte Rechnungen vorhanden sind.
• insert_ts – Der Zeitstempel, als dieser Datensatz eingefügt wurde.

Abonnementpläne ändern sich oft im Laufe der Zeit. Um einen vollständigen Verlauf all unserer Pläne zu führen, speichern wir alle Planänderungen in plan_history Tisch. Für jeden Datensatz hier benötigen wir ein:

• subscription_id – Die ID des zugehörigen Abonnements.
• plan_id – Die ID des zugehörigen Plans.
• date_start und date_end – Der Zeitraum, in dem dieser Plan aktiv war.
• insert_ts – Der Zeitstempel, als dieser Datensatz eingefügt wurde.

Die letzte Tabelle in unserem Modell speichert unsere invoices . Für jede Rechnung speichern wir die folgenden Details:

• customer_invoice_data – Eine Beschreibung des Kunden, dem diese Rechnung in Rechnung gestellt wird. Dies sind die Daten aus user_group.customer_invoice_data in dem Moment, in dem die Rechnung erstellt wurde.
• subscription_id – Die ID des zugehörigen Abonnements.
• plan_history_id – Die ID des Plans, der während dieses Rechnungszeitraums aktiv ist.
• invoice_period_start_date und invoice_period_end_date – Das von dieser Rechnung abgedeckte Zeitintervall (z. B. 1. Januar 2019 bis 31. Januar 2019).
• invoice_description – Eine kurze Textbeschreibung der Rechnung.
• invoice_amount – Der für diese Rechnung fällige Zahlungsbetrag.
• invoice_created_ts – Wann diese Rechnung erstellt und in die Tabelle eingefügt wurde.
• invoice_due_ts – Wann diese Rechnung fällig ist.
• invoice_paid_ts – Der Zeitstempel, wann diese Rechnung bezahlt wurde.

Sagen Sie uns Ihre Meinung zum SaaS-Datenmodell

Ich schätze, dass die meisten von Ihnen SaaS kennengelernt haben, entweder als Entwickler oder als Benutzer. Ich freue mich auf Ihre Meinung dazu und zu diesem Datenmodell. Fühlen Sie sich frei, Ihre Erfahrungen und Vorschläge in den Kommentaren unten zu teilen.