Doktrin: Tracking-Verlauf von sich langsam ändernden Dimensionen

Question

Ich entwickle eine Art von Webshop in Symfony3/Doctrine. Um die Dinge zu vereinfachen, lassen Sie uns sagen, ich habe eine Tabelle Repairs und eine Parts. Teile haben einen Namen und einen Preis, und eine Reparatur kann viele Teile verwenden, sowie verschiedene Teile können in verschiedenen Reparaturen (Viele-zu-viele) verwendet werden. Der Preis einer Reparatur ist die Summe der Preise der Teile und einiger anderer Faktoren.

langsam veränderliche Dimensionen

Nun sollte es möglich sein, den Preis von einem Part, zu ändern und dies sollte den Preis der Zukunft Repairs ändern. Alle in der Datenbank vorhandenen Repairs sollten jedoch nicht geändert werden, da sie für die Buchhaltung, Fakturierung und dergleichen verwendet werden.

"Soft aktualisierbar"

Löschen eines Part ist leicht mit SoftDeleteable gelöst. Dies hält die Beziehungen zwischen Parts und Repairs intakt. Ähnliches sollte beim Aktualisieren von Entitäten passieren. Nur wenn sich etwas Wichtiges (wie der Preis) ändert, sollte die Entität in der Datenbank aktualisiert werden. Es scheint jedoch keinen fertigen Code zu geben.

Ich habe folgendes versucht:

• einfach das alte Entity zu löschen und eine Kopie auf jedes Update zu speichern, die Code-intensiv, ineffizient und läßt viele Junk in der Datenbank. Ich
• EntityAudit verwenden, aber das doesn auch
• Versionable, aber das funktioniert nicht auf many-to-many-Einheiten
• Loggable, aber die Änderungen in einer separaten Log-Tabelle schreibt, nicht in der Tabelle tu was ich will und kann nicht auf viele zu manies verwendet werden.

Nähern Sie sich dem Problem anders?

Ich habe asked für die Hilfe bei meinen technischen Lösungen before, aber da ich, dass das Problem glauben, ein allgemeines ist, ich bin zu denken beginnen, dass der Mangel an einfachen, fertigen Lösungen bedeutet, dass ich bin das Problem falsch angehen. Vielleicht sollte ich einfach eine statische Tabelle für die Buchhaltung mit statischen Werten in ihnen gespeichert halten (aber das würde nicht erlauben, den Namen einer bestimmten Reparatur zu ändern, während der Preis beibehalten wird)? Oder?

Answer 1

Haftungsausschluss: Ihre Frage ist ziemlich breit, daher kann es mehr als eine gut genug Lösung geben. Dieser hier ist nur meine Meinung.

Ich denke, Sie sollten Ihre Domäne überdenken. Denken Sie noch einmal darüber nach, was der "Preis" tatsächlich ist. Wie Sie bereits bemerkt haben, variiert es je nach Sichtweise. In Ihren Beispielen gab es zwei Fälle:

• Strom (Basis) Preis des Produktes.
• der Preis in der Vergangenheit zu der Zeit wurde die Rapair gemacht.(Tatsächlich bezahlte Menge)

Aber es gibt noch mehr Standpunkte zu dem gleichen Preis. Der Preis kann sich nicht nur im Laufe der Zeit ändern, sondern kann auch mehrere Werte haben gleichzeitig. Nehmen wir an, Sie möchten die Rabattfunktion implementieren, wenn Sie Parts für eine Repair Kosten> 100 $ insgesamt geben, geben Sie einen Rabatt von 5%. In diesem Fall können zwei Kunden zum gleichen Zeitpunkt einen unterschiedlichen Preis haben.

Unter Berücksichtigung, könnten Sie feststellen, dass es nicht wirklich von Part Preis im Laufe der Zeit ist, aber es gibt zwei verschiedene Preiseigenschaften. One Basis Preis, und die zweite bezahlt Preis.

Da bezahlten Preis kann Werte haben, die nie als Basis existierte (beispielsweise in Rabatt-Fall), ist es klar, dass man mit zwei verschiedenen Werten zu tun hat, die nur von accidence price die gleichen Namen haben. Aber sie gehören zu zwei verschiedenen Entitäten.

tl; dr

Sie sind mit zwei verschiedenen Werten zu tun, und sie sollten getrennt aufbewahrt werden.

Lösungsvorschlag

Statt ManyToMany Beziehung, könnten Sie eine explizite Einheit machen RepairPart, die beiden Repair und Part Einheiten in ManyToOne Beziehung betreffen würde, aber es wird auch zusätzliche Daten enthalten, die Sie in benötigen die Zukunft, aber sie können sich in Quelle Part Tabelle ändern. In diesem Fall ist es der Preis.