Wir hatten einige Diskussionen in unserer Entwicklungsgruppe darüber, ob die Zusammensetzung von Entitäten das Datenbankdesign vorantreiben sollte oder ob das Datenbankdesign die Zusammensetzung der Entitäten bestimmen sollte.
Für diejenigen, die damit umgegangen sind, was war Ihre Philosophie? Natürlich wird nicht jede Entität 1: 1 einer Datenbanktabelle zugeordnet. Aber für die, die das tun, wie haben Sie das gehandhabt? IOW, die zuerst kommt, die Datenbanktabelle und dann eine entsprechende Entität oder eine Entität und dann eine Datenbanktabelle, um es zu erhalten?
Danke.
Ihre Datenbank wird wahrscheinlich über alle Anwendungen hinausgehen, die Sie heute erstellen. Die gesamte Leistung und Skalierbarkeit wird von Ihrem Datenbankschema bestimmt. Ein solides Datenbankmodell ist die Grundlage, auf der jede Anwendung aufgebaut ist, und ich würde sagen, dass Sie dort am meisten in Design und Tests investieren sollten, da dies die größten Vorteile bietet.
Natürlich wird Ihre Anwendung es vorziehen, Domain-Entitäten zu manipulieren, und die Manipulation von unnatürlichen Entitäten, die von relationalen Theorien getrieben werden, im Gegensatz zu Business-Entitäten, wird die Dinge nur komplizieren. Meines Erachtens ist es die Aufgabe von ORM, die beiden so gut wie möglich zu kombinieren. Aber immer wenn unvermeidliche Konflikte auftreten, sollte das Vorrecht durch den treibenden Faktor Ihrer Leistung und Skalierbarkeit gegeben sein: das Datenbankschema.
"Entität und dann eine Datenbanktabelle, um sie zu erhalten"
Die Entity ist das, was Ihr Programm manipuliert. Das ist die Essenz dessen, was verarbeitet wird.
Die Datenbankdarstellung dieser Entität (wie Flat-File-Repräsentationen oder GUI-Repräsentationen) sind nur praktische Repräsentationen der Entität.
Sie müssen vielleicht etwas über die DB-Darstellung nachdenken, wenn es um bestimmte Dinge geht, bei denen relationale Datenbanken besonders schlecht sind. Viele-zu-viele-Beziehungen erfordern beispielsweise die Einführung einer zusätzlichen Tabelle, da die Datenbank über Einschränkungen verfügt, die Ihr Objektmodell nicht hat. Sie haben vielleicht einige Überlegungen zum Entwurf von Entitäten, um damit umzugehen, aber diese wenigen und gut verstanden.
Die Datenbank ist weniger wichtig.
Die Definitionen der Entitäten sind von zentraler Bedeutung.
Ich würde sagen, dass Sie Ihr logisches Datenmodell erstellen und die Datenbank und die entsprechenden Objekte erstellen.
Tatsächlich würde ich die Annahme in Frage stellen, dass die Datenbanktabelle und die entsprechenden Entitäten nicht korrespondieren können. Ich habe selten, wenn jemals einen Fall gesehen, in dem sie wirklich nicht konnten (wenn Sie eine Anwendung von Grund auf aufbauen). Außerdem würde ich sagen, dass jedes Mal, wenn das Objektmodell und das Datenbankschema auseinander gingen, eine Menge Probleme auftraten.
Ich bin wieder auf die Idee gekommen, dass alles einfacher ist, wenn man sie immer zusammenbringt, so häretisch das auch sein mag.
Tags und Links sql-server c# linq-to-sql orm entity