Entitätsspezialeigenschaften und Datenbanknormalisierung

Question

Angenommen, ich habe ein Kundenobjekt mit allen Standardeigenschaften des Kunden (Name, Adresse, Kontakt usw.). Wir erhalten einen neuen Kunden (Acme), der eine sehr spezifische Anfrage hat, dass Rechnungen, die wir an sie senden, unsere ID als Barcode haben. Wir wollen das nicht für alle anderen Kunden, deshalb beabsichtigen wir dies als Sonderfall für Acme. Nehmen wir nun an, dass viele Kunden diese kleinen einmaligen Anforderungen haben.

Ich sehe ein paar Möglichkeiten und ihre Vorteile/Nachteile:

1) Fest programmiert, an der Stelle der Abweichung, für ID oder Kundennamen überprüft, was diese Daten dem besten Weg, um Modus wäre.
Vorteile: Geringster Aufwand, Single Point of Integration
Kompromiss: Sloppy Code, sehr anfällig für Fehler. Das Ändern von Flags erfordert eine neue Bereitstellung. Schwierig, Abweichungen zu finden, wenn die Anzahl der Eigenschaften zunimmt.

2) DB-Spalten auf Kunden für jede Eigenschaft. Flags würden für den einen Kunden auf wahr gesetzt werden, für alle anderen falsch.
Vorteil: relativ einfach, Eigenschaften können im laufenden Betrieb geändert werden
Kompromiss: Macht sehr breite Datenbanken und schlampig Schema. Je mehr Eigenschaften hinzugefügt werden, desto unübersichtlicher werden die Daten. Der Code wird auch schlampig, da viele unnötige Eigenschaften zugeordnet werden müssen.

3) Fest codierte Eigenschaftenzuordnung. Eine Map, die spezielle Eigenschaften für Kunden enthält. Die Karte kann dann für spezielle Eigenschaften angefordert werden, und der Code-Ablauf kann von dort ausgehen.
Vorteile: Single Point of Management.
Nachteil: Hardcoded. Kundennummern/Namen wären im Code enthalten. Das Vornehmen von Änderungen erfordert Bereitstellungen.

4) CustomerProperty-Tabelle mit Schlüssel/Wert-Spalten.
Vorteile: Sauber. Einziger Punkt der Verwaltung. Dynamisch.
Nachteile: Relative Komplex, im Vergleich zu den anderen Lösungen.

Offensichtlich würden Entscheidungen je nach den Umständen variieren. Wenn wir Hunderte von Abweichungen haben, wäre es wichtig, einen einzigen Punkt der Verwaltung zu haben. Wenn es wirklich eine einmalige Abweichung wäre, denke ich, # 1 wäre okay, wenn auch hackisch.

Ich habe meine Meinungen über das Beste in diesem Fall .... aber ich würde gerne die Meinungen aller anderen kennen.

Answer 1

Ich würde mit Option 4 gehen. Aus Erfahrung, wenn ich mich für die schnelleren Optionen entschieden habe, war das Ergebnis zwangsläufig die Implementierung der optimalen Lösung und der Hack verursachte nur Probleme. Ich versuche immer, diese Probleme aus einer Domänenperspektive zu betrachten und in diesem Fall ist 4 das beste Modell. Der Unterschied in der Implementierung ist minimal im Vergleich zu der Wartung aller Artefakte und eventuellem Refactoring, das Sie durchführen müssen.

Answer 2

Ich bevorzuge den vollständig normalisierten Ansatz; Ich hätte eine Tabelle, die die verschiedenen einmaligen Sonderanfragen mit ihrem Primärschlüssel aufzählt. Dann hätte ich eine Join-Tabelle, die zwei Spalten hat, beide Fremdschlüssel, wobei die erste Spalte die Kunden-ID und die zweite Spalte die ID aus der Tabelle für spezielle Anforderungen enthält.

Answer 3

Ich habe eine Menge von 1) auf einem früheren Projekt von mir, und zog schließlich zu einer Lösung wie Nummer 4). Ich benutzte den Ort meiner Hacks, um Haken zur Anpassung zu platzieren. Es war auf jeden Fall einfacher zu verwalten, vor allem, da die Anpassungsanforderungen zunahmen.

Ich dachte ursprünglich, dass 2) für Ihr spezielles Szenario funktionieren würde (nicht die vermeintlichen zusätzlichen Anpassungsanforderungen, nur die Barcode-Anfrage), weil ich davon ausgegangen bin, dass andere Kunden eventuell auch einen Barcode auf ihren Rechnungen haben wollen. Ich könnte jedoch auch sehen, dass sie die Barcode-Informationen in einem anderen Format als ursprünglich für den ersten Kunden entworfen haben möchten, was zu dem Problem führen könnte, mit dem Sie begonnen haben.

Also sage ich gehen mit 4), und implementieren Sie daher eine Viele-zu-viele-Beziehung zwischen Ihren Anpassungsentitäten und Ihren Kundenentitäten. Zu Beginn sollten die Anpassungsentitäten nicht mehr als Werte für die Ausführung von Switch-Anweisungen in Ihrem Anwendungscode sein, in denen Anpassungen vorgenommen werden sollten.