Laden...

SQL 2012, n:m Beziehungen; Datensätze hinzufügen, löschen ect.

Erstellt von DerPapenberg vor 11 Jahren Letzter Beitrag vor 11 Jahren 3.115 Views
D
DerPapenberg Themenstarter:in
116 Beiträge seit 2010
vor 11 Jahren
SQL 2012, n:m Beziehungen; Datensätze hinzufügen, löschen ect.

verwendetes Datenbanksystem: SQL 2012 Express

Guten Morgen zusammen,

zum beseren kennenlernen von SQL will ich mir eine 08/15 Buchverwaltung erstellen. Ich stehe jetzt leider vor dem Problem, wie ich codtechnisch n:m Bezeihungen darstellen soll (DataSet). Das erstellen der Tabellen und deren Verknüpfungen für eine n:m Beziehung über das SQL Server Manangement Studio stellt an sich kein Problem dar. Das Anzeigen der Daten und hinzufügen dieser über n:m Beziehungen per c# wiederum schlägt bei mir fehl. Leider wird im Buch SQL Buch darauf nicht eingegangen (ausser was n:m Beziehungen sind).
Im Netz finden sich viele Beispiele zu n:m Beziehungen, die sich aber primär um Access drehen. Kennt jemand eine Seite, wo n:m Beziehungen ADO-Technisch behandelt wird?

Ansonsten allen noch einen angenehmen Weihnachtstag 😃

1.552 Beiträge seit 2010
vor 11 Jahren

Hallo DerPapenberg,

für eine n:m benötigst du 3 Tabellen. Z.b.
Buch
Person
Verleihuebersicht

Um in Verleihübersicht, welche eine PersonId und BuchId besitzt, Daten speichern zu können, müssen die zu referenzierende Person und Buch bereits existieren. Denn dann kannst du ohne Probleme in Verleihübersicht Daten einfügen.

Gruß,
Michael

Mein Blog
Meine WPF-Druckbibliothek: auf Wordpress, myCSharp

D
DerPapenberg Themenstarter:in
116 Beiträge seit 2010
vor 11 Jahren

Hallo xxMUROxx,

bin jetzt wieder ein Stück und hänge an folgendes fest::

Hier ein einfache Datenbank...

[Book]

  • TitleID (guid) NULL Wert zulassen = Nein
  • AuthorID (guid) NULL Wert zulassen = Nein
  • Title (nvarchar(100))

[Rel_Book_Author]

  • AuthorID (uniqueidentifier) NULL Wert zulassen = Nein
  • TitleID (uniqueidentifier) NULL Wert zulassen = Nein

[Author]

  • AuthorID (uniqueidentifier) NULL Wert zulassen = Nein
  • AuthorName (nvarchar(100))

Mein Problem besteht nun wie folgt:
Wenn ich einen Titel hinzufüge und der Author noch nicht erfasst wurde, würde im Normalfall eine Fehlermeldung
angezeigt werden, weil die Spalte AuthorID in der Tabelle Book nicht leer sein darf. D.h., ich müsste erst
den Author in die Tabelle Author eintragen und mir dir erstellte Guid merken. Im Anschluss könnte ich die
Tabelle _Book _ bedienen und die Spalte _AuthorID _ im neuen Datensatz mit der sich gemerkten Guid füllen.
Im gleichen Atemzug müsste ich mir dann die neu erstellte Guid aus der Spalte _TitleID _ der Tabelle Book
merken und diese beiden Guids dann in der Tabelle Rel_Book_Author als neuen Datensatz einpflegen. Ich hoffe, dass
dieser Weg der beste ist 😉 Wie komme ich denn an die neu angelegte Guid ran?

F
10.010 Beiträge seit 2004
vor 11 Jahren

Warum willst Du Guids benutzen?
Es gibt zwar Gründe Guids als PK zu benutzen, aber man sollte sich das gut überlegen. Trotzdem sollte der Datensatz auch über einen einfachen eindeutigen Schlüssel ( Identity ) verfügen.
Den kannst du dann ganz einfach per @@Identity oder SCOPE_IDENTITY zurückbekommen, im Adapter.RowUpdated

Noch etwas, ein Buch kann mehrere Autoren haben, also lass die AutorID weg.

190 Beiträge seit 2012
vor 11 Jahren

Bei einem Buch empfiehlt es sich die Internationale Standardbuchnummer (ISBN) als PK zu verwenden. Die Nummer ist eine eindeutige Kennzeichnung.

  • Wer lesen kann, ist klar im Vorteil
  • Meistens sitzt der Fehler vorm Monitor
  • "Geht nicht" ist keine Fehlermeldung!
  • "Ich kann programmieren" != "Ich habe den Code bei Google gefunden"

GidF

344 Beiträge seit 2006
vor 11 Jahren

Hallo

Aber die AutorID hat in der Tabelle Book nigs verloren. Der Autor und das Buch werden in der Zwischentabelle zusammengeführt.

Gruss Lothi

Ergänzung: Ups... habe die letzte Zeile von FZelle nicht gelesen.

D
DerPapenberg Themenstarter:in
116 Beiträge seit 2010
vor 11 Jahren

Warum willst Du Guids benutzen?
Es gibt zwar Gründe Guids als PK zu benutzen, aber man sollte sich das gut überlegen. Trotzdem sollte der Datensatz auch über einen einfachen eindeutigen Schlüssel ( Identity ) verfügen.
Den kannst du dann ganz einfach per @@Identity oder SCOPE_IDENTITY zurückbekommen, im
>

Noch etwas, ein Buch kann mehrere Autoren haben, also lass die AutorID weg.

Was ist an den Guids als PK bedenklich?

Aufgrund der Begebenheit, dass ein Buch durch mehrere Authoren verfasst werden kann, habe ich ja die dritte Tabelle (Rel_Book_Author) eingeführt (n:m)

Danke für den Link

Gruß

F
10.010 Beiträge seit 2004
vor 11 Jahren

Die Diskussion hatten wir hier schon z.b.: GUID oder int als Primary Key?