Integrieren Sie zusätzliche Anforderungen in ein Legacy-databasedesign

Ich kämpfe mit einem database-Design, das ist was ich bisher habe.

Schema

Hier sind die Probleme.

  1. Ich muss einen neuen Benutzertyp einführen (Konglomerationsmanager) und sie werden die Sichtbarkeit von Unternehmensgruppen (ein Konglomerat) haben. Ein Konglomerationsmanager kann mehrere Unternehmen haben, und ein Unternehmen kann mehreren Konglomeratmanagern angehören. Es wäre vorteilhaft, wenn eine unabhängige Firma hinzugefügt werden könnte, und dann zu einem späteren timepunkt leicht als Teil eines Konglomerats aufgenommen werden könnte.

    Ich finde das schwierig zu modellieren, da alle meine bisherigen Benutzer (Manager, Treiber, Empfänger) alle in der Benutzertabelle existieren. Dies war von Entwurf, da sie alle fast die gleichen datafelder haben, und ich muss einen einzigen Anmeldepunkt für alle Benutzer auf meiner Website haben. Wenn ich der Benutzertabelle einen Konglomerationsmanager hinzufüge, haben sie Beziehungen zu anderen Tabellen, die meine vorhandenen Benutzertypen nicht haben.

  2. Ich bin unruhig über die Abhängigkeitsschleife, die von Benutzern, Besitzern, Paketen, Unternehmen und Benutzern gebildet wird. Das erscheint mir als schlechte Form, aber ich kann mir wirklich keinen path vorstellen, wie ich es vermeiden kann:

    Manager, Fahrer und Empfänger arbeiten alle für ein einzelnes Unternehmen. Diese Firma hat eine Reihe von Paketen, aber ich muss die Möglichkeit haben, eine Teilmenge dieser Pakete einem bestimmten Empfänger (ihren eigenen Paketen) und einem bestimmten Treiber oder Manager (der für die Lieferung dieser Pakete zuständig ist) zuzuordnen.

  3. Ich bin nicht zufrieden mit dem Feld "receive_emails" in Benutzern, da es nur für Benutzer vom Typ "Empfänger" relevant ist.

Um die Probleme hinzuzufügen, wird dieses Design bereits verwendet, und data müssen zu jedem neuen Design migriert werden.

Die häufigsten Vorgänge, die im System ausgeführt werden, sind die Statusanzeige nach Empfängern, gefolgt von der Erstellung von Status durch Manager und Fahrer.

Können meine Probleme mit einem eleganten neuen Design angesprochen werden?

Solutions Collecting From Web of "Integrieren Sie zusätzliche Anforderungen in ein Legacy-databasedesign"

Nun, hier ist ein weiterer Versuch. Ich denke immer noch

  • Sie sollten sich nicht zu viele Gedanken über das Feld receive_emails machen, wie in meiner anderen Antwort erklärt.
  • Sie müssen Benutzer nicht in Benutzerarten aufteilen.

Worüber Sie in 2 besorgt sind, sind die Abhängigkeiten. Abhängigkeiten sind in der Regel kein Problem, aber Sie sind sehr streng in Ihrem ID-basierten databaseentwurf und verstecken somit die Abhängigkeiten von Ihrem dbms. Wenn es nur wüsste, könnte es dir helfen 🙂

Du könntest das tun:

  • Halten Sie sich an Ihre Tabelle "Benutzer", aber entfernen Sie die Firmen-ID.
  • Sie müssen keine Änderungen an "Firmen", "Paketen", "Beteiligungen" und "Status" vornehmen.
  • Fügen Sie eine Tabelle hinzu, um Benutzer mit Unternehmen zu verknüpfen. Nennen wir die Tabelle im Moment "Zugehörigkeiten". (Ich weiß nicht, ob das ein passender Name wäre, mein Englisch fehlt mir hier.) Wie bei den Besitzern ist dies nur eine Linktabelle, also sind die einzigen Felder user_id und company_id (bilden den Primärschlüssel).
  • Fügen Sie jetzt Company_id zu "Ownerships" hinzu. (Ich weiß, es ist irgendwie implizit wegen Ihrer Verbindung zu "Paketen", aber das dbms weiß das nicht.) Also fügen Sie das Feld hinzu und jetzt, da Ihr dbms das Feld sieht, können Sie auch eine Einschränkung hinzufügen (fremd Schlüssel) für package_id plus company_id für "packages" und eine Einschränkung für user_id plus company_id für "Affilations".

Das ist es. Sie haben sich nicht viel verändert, aber jetzt kann ein Benutzer vielen Firmen (Konglomeratmanagern bis jetzt) ​​angeschlossen werden, aber vielleicht beschließen Sie eines Tages, Empfängern zu erlauben, mit mehreren Firmen zu arbeiten oder Fahrer für mehr als eine der Firmen an einer Arbeit zu lassen time). Und es besteht keine Gefahr von falschen Einträgen in "Besitzern" oder irgendwelchen Zweifeln über deren Inhalt und Verwendung.

Wenn Sie mit dem Feld receive_emails auf Nummer sicher gehen wollen, ist hier eine Möglichkeit, die Sie vielleicht gehen möchten (wie gesagt, es ist nicht wirklich notwendig): Haben Sie eine neue Tabelle email_recipients mit zwei Feldern: user_id und user_type. Ja, wieder Redundanz. Wenn Sie dies tun, können Sie eine Einschränkung für user_type haben, die nur bestimmte Typen zulässt (bisher nur "Empfänger"). Auch hier hätten Sie einen Fremdschlüssel nicht nur für user_id, sondern auch für user_id plus user_type.

Erweitern Sie die Benutzer!

Wie beim Erweitern einer class können Sie eine neue Tabelle "Manager" mit mehr Spalten und einem FK für Benutzer erstellen.

Sie können also eine relationale Tabelle zwischen Managern und Unternehmen erstellen.

Wenn Sie eine bessere Kontrolle über diese Konglomerat-Entität wünschen, erstellen Sie die Konglomerat-Tabelle und erstellen Sie eine FK für Manager, sodass Sie eine relationale Tabelle zwischen Conglomerate und Companies erstellen OR wenn eine Firma nicht von zwei Konglomeraten nur ein FK von Unternehmen zu Konglomerat gehört.

Ich muss einen neuen Benutzertyp einführen

In diesem Szenario, wenn das Hinzufügen eines neuen Typs erforderlich ist, würde dies zu einer Umstrukturierung des Schemas führen, führt mich zu einem Defekt im Design.

Tatsächlich sind das Verwalten und Fahren Rollen, die von einem Benutzer gespielt werden, die sich im Laufe der time ändern können.
In Wirklichkeit:
Ein Benutzer ist kein Manager (er ist eine Person).
Verwalten ist eine Rolle, die von einem Benutzer gespielt wird.
Denken Sie darüber nach, ob sich das Unternehmen für Helpdesk-Benutzer entscheidet.

Ich werde Role und User-Role Tabellen hinzufügen, um die Beziehung zwischen Benutzer und Rolle zu erhalten.

Ich bin nicht zufrieden mit dem Feld "receive_emails" in Benutzern.

Das receive-email Feld in der User-Role ist eine Option.

Ich brauche einen einzigen Anmeldepunkt für alle Benutzer auf meiner Website

Möglicherweise können Benutzer, Unternehmen und Rolle als Auswahlen auf der Anmeldeseite verwendet werden (dies hat direkte Auswirkungen auf das Anwendungsdesign).

Ich bin unruhig über die Abhängigkeitsschleife, die von Benutzern, Besitzern, Paketen, Unternehmen und Benutzern gebildet wird.

Konzeptionell haben wir Empfänger-Benutzer => Eigentümer => Paket => Firma => Treiber oder Manager-Benutzer.
BTW ist ein relationales model.

Konglomerate.

Bildbeschreibung hier eingeben

3: Sorgen Sie sich nicht zu sehr um das Feld receive_emails. Denken Sie daran, dass Ihre database nur ein model der realen Welt ist und nicht perfekt sein muss. Ja, Sie könnten "Empfänger" zu einer eigenen Tabelle machen. Überlegen Sie, was Sie gewinnen würden und was Sie verlieren würden. So wie es ist, ist es kein schlechtes Design. Sie können einen Trigger verwenden, um receive_emails auf "false" zu setzen, falls der Benutzer kein Empfänger ist. Oder verwenden Sie eine view, um das Feld für Apps mit Treibern oder Managern zu verbergen. Ganz wie du willst. Nun, wenn Sie das Feld wirklich loswerden wollen, könnten Sie eine Tabelle "emeil_recipients" haben, die alle Benutzer-IDs enthält, die Empfänger von E-Mails sind. Sie sehen, es gibt viele Möglichkeiten, dies anzugehen, und sie alle haben ihre eigenen Vor- und Nachteile. Ihr Design ist in Ordnung.

2: So weit ich es verstehe, hat jedes Paket bis zu einen Manager, einen Fahrer und einen Empfänger. Ist das so? Warum also überhaupt eine Tabelle "Eigentümerschaft"? Setzen Sie drei Felder in Ihre "Packages" -Tabelle; user_id_driver, user_id_manager, user_id_recipient. Ihr model ist also viel näher an der Realität. (Sie können eine view "Eigentumsrechte" erstellen, um die Tabelle "Eigentumsrechte" während der Migrationszeit zu replace.)

1: Nun zu den Konglomeraten. Am einfachsten wäre es, zwei neue Tabellen einzuführen: Zuerst würden Sie eine Tabelle "company_groups" mit einer ID und vielleicht einem Beschreibungsfeld haben. Ihre Tabelle "Benutzer" würde ein Feld "company_group_id" haben, das das Feld "company_id" replace würde. So verknüpfen Sie Benutzer mit Unternehmensgruppen und nicht mit einzelnen Unternehmen. Ihre zweite neue Tabelle wäre "company_group_members" mit nur zwei Feldern id_company_group und id_company. Sie würden "Gruppen" bilden, die nur aus einer einzigen Firma (für die Manager, Empfänger und Fahrer) und Gruppen bestehen, die aus mehr Firmen bestehen (Konglomerate für die Konglomeratmanager). Ihre database ändert also nicht viel, bietet aber alles, was Sie brauchen.

Wenn Sie das alles gesagt haben, könnten Sie immer noch daran denken, Ihre "Benutzer" -Tabelle auf die allgemeinen Felder zu reduzieren und die neuen Tabellen "Manager", "Empfänger", "Treiber" und "Konglomeration_Manager" mit zusätzlichen Feldern zu versehen. Dies bringt Sie näher an die Realität und macht die Verbindung zu Paketen klarer. Es kommt jedoch auf Kosten eines anderen models von Ihrem aktuellen. Und was, wenn Sie später Fahrer, Sekretärinnen oder was auch immer hinzufügen? Jedes Mal eine neue Tabelle für einen neuen Job? Nochmals: Es gibt viele Möglichkeiten, Ihr model zu erstellen. Wählen Sie diejenige, die am besten zu Ihnen passt.

Ich hoffe, dass mein Rat Ihnen hilft, alles durchzudenken.