Laden...

Gibt es eine Alternative zu m:n?

Erstellt von eclere vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.085 Views
E
eclere Themenstarter:in
95 Beiträge seit 2006
vor 6 Jahren
Gibt es eine Alternative zu m:n?

verwendetes Datenbanksystem: <SQL-Server 2016 Express>

Hallo zusammen,

ich habe eine Tabelle Adressen und eine Tabelle Stichworte. Jeder Adresse sollen beliebige Stichworte zugeordnet werden können.
Normalerweise würde ich dies lösen in dem ich z.B. eine Tabelle Adresse2Stichwort anlege, welche die beiden Fremdschlüssel hält. Ich persönlich mag diese Vorgehensweise aber nicht.
Nun benötige ich zusätzlich noch die Information WANN und WER ein Stichwort einer Adresse zugeordnet hat. Diese Informationen müssten ja eigentlich in der Adresse2Stichwort Tabelle liegen, was wiederum zu dem Problem der Auswertung während Laufzeit führt. Ich habe die beiden Klassen Adresse und Stichwort und diese halten ebenfalls die Information WANN und WER diese erstellt hat. Die Zuordnung zu den Stichwörtern (WANN, WER) gehört m.E. in keine der beiden Klassen.

Ich frage mich daher ob es nicht auch ein anderes Datenmodel zur Auflösung von m:n Beziehungen gibt?

Viele Grüße
Thorsten

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo eclere,

das ist mehr od. weniger eine immanente Eigenschaft von relationalen Datenbanken.

Wenn du nicht an den SQL Server gebunden bist, so wäre hier ein Blick zu NoSQL-Vertretern (MongoDB, etc.) passend. Damit kann dieser Fall besser abgebildet werden.

Sonst lassen sich m:n-Beziehungen nur via einer "Verbindungstabelle" auflösen. Außer du verzichtest auf die Verknüpfung und legst die Daten einfach so ab, aber dann gibst du auch eine Eigenschaft, die referentielle Integrität, auf.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

C
2.121 Beiträge seit 2010
vor 6 Jahren

Ich persönlich mag diese Vorgehensweise aber nicht.

Gibt es einen bestimmten Grund dafür? Ein "ich mag nicht" ist eine seltsame Begründung um etwas nicht zu verwenden das genau für diesen Zweck gedacht ist.

16.806 Beiträge seit 2008
vor 6 Jahren

Davon abgesehen, dass relationalen Mappingtabellen bei m:n einfach technisch notwendig sind vermischt Du offensichtlich Entitäten mit Business Objekten.

Entitäten bilden genau eine Zeile in der Datenbank einer Tabelle ab.
Daher gibt es i.d.R. pro Tabelle genau eine Enität. Es gibt zudem nicht mehr Entitäten als Tabellen.

Dort gibt es dann natürlich auch eine Entität für die Mappingtabelle, in der wer und wann steht.

Business Modelle können aber müssen sich nicht in den Entitäten widerspiegeln.
Eigenschaften sind in den Business Modellen eben nach ihren Zugehörigkeit und der Domäne gestaltet.

E
eclere Themenstarter:in
95 Beiträge seit 2006
vor 6 Jahren

Hallo,
ich bin leider an den Sql-Server gebunden. Somit fallen NoSql-Vertreter erst einmal raus.

@Abt: Magst Du erläutern warum ich Entitäten und Business Objekte vermische? Diese Feststellung verwirrt mich gerade. 🤔

Warum ich m:n nicht mag: Nun ja, ich habe einerseites ein DBMS zur Haltung der Daten und anderseits meine Anwendung. In der Anwendung selbst habe ich meine Business nicht immer genau wie die Entitäten im Datenmodell abgebildet. Im konkreten Fall habe ich ja die Entitäten Kontake, Kontakte2Stichworte und Stichworte. In der Anwendung verzichte ich aber auf diese Kontakte2Stichworte Zuordnungsentität. Da haben Adressen einfach nur Stichworte...das ist eben praktischer.
Möchte ich aber nun eine Suche nach bestimmten Stichwörtern starten und benötige die Information, welcher Adresse diesen nun zugeordnet ist, brauche ich wieder die Zuordnungstabelle. Da diese aber nicht in meinen Business-Objekten vorgesehen ist, ist das blöd 😁
Und deshalb mag ich m:n nicht wirklich, denn die ZUordnungstabelle als Business Objekt macht das Bindung der Daten (ich verwende XAML) XAML meiner Meinung nach komplizierter als es nutzt.
Daher einfach mal de Fragen nach Alternativen von denen ich vielleicht bisher noch nie was gehört habe. Manche Dinge entwickeln sich ja weiter 👍

D
985 Beiträge seit 2014
vor 6 Jahren

An der Art wie du das Problem beschreibst, merkt man, dass du hier eine Vermischung vornimmst.

Erstelle dein BusinessObject, so dass es deinen Erwartungen/den Ansprüchen der Anwendung entspricht.

Wenn das erledigt ist, dann - und wirklich erst dann - überlegst du dir, wie du das BusinessObject in der Datenbank so ablegst, dass du das BusinessObject aus den Daten in der Datenbank exakt so wieder zusammenbauen kannst.

5.657 Beiträge seit 2006
vor 6 Jahren

Hallo eclere,

Da diese aber nicht in meinen Business-Objekten vorgesehen ist, ist das blöd 😄
Und deshalb mag ich m:n nicht wirklich, denn die ZUordnungstabelle als Business Objekt macht das Bindung der Daten (ich verwende XAML) XAML meiner Meinung nach komplizierter als es nutzt.

Nein, es ist nicht blöd, und XAML hat auch nichts mit der Art der Speicherung deiner Daten zu tun. Zwischen Speicherung und Anzeige der Daten liegt die Business-Logik deiner Anwendung. Diese kann die Daten in die Form transformieren, die für die Bearbeitung und Anzeige benötigt werden. Solange du aber Relationale Datenbanksysteme wie den SQL-Server zum Speicher benutzt, kommst du um eine relationale Form der Speicherung nicht herum.

Siehe dazu [Artikel] Drei-Schichten-Architektur, und wo wir schon dabei sind auch [Artikel] MVVM und DataBinding.

Weeks of programming can save you hours of planning

E
eclere Themenstarter:in
95 Beiträge seit 2006
vor 6 Jahren

Solange du aber Relationale Datenbanksysteme wie den SQL-Server zum Speicher benutzt, kommst du um eine relationale Form der Speicherung nicht herum.

Danke. Das wollte ich wissen.