Laden...

Primärschlüssel erstellen

Erstellt von Snowwolf3000 vor 19 Jahren Letzter Beitrag vor 19 Jahren 4.590 Views
Snowwolf3000 Themenstarter:in
140 Beiträge seit 2004
vor 19 Jahren
Primärschlüssel erstellen

Hi,

nachdem gestern mein DB Problem so leicht gelöst werden konnte, hab ich mir überlegt ich mach es ein wenig komplizierter 😁

Also kurz was ich vorhab:
Ich will alle meine Mp3 Alben in eine DB schreiben. Der Name des Künstlers und die Bezeichung des Albums kann ich problemslos aus den Namen des Ordners für das Albums lesen.
Sowohl Künstler als auch Album bekommen eine eigene Tabelle. Diese ist über eine n:m Beziehung verbunden. Deshalb hab ich eine Zuordungstabelle AlbumKuenstler angelegt. (siehe auch Anhang). Die Primärschlüssel wurden bisher von der DB vergeben.

Ich muss jetzt also folgendes tun:

  1. Eintrag Künstler erstellen (nur falls er noch nicht vorhanden ist)
  2. Eintrag Album erstlellen (nur falls er noch nicht vorhanden ist)
  3. Primärschlüssel von Künstler und Album in die die Zuordungstabelle schreiben.

Punkt 1 und 2 ist kein Problem. Die Schwierigkeit ist für mich erstmal die grundsätzliche Vorgehensweise für Punkt 3. Muss ich jetzt irgendwie versuchen die von der Datenbank erstellten Primärschlüssel abzufragen oder sollte ich die Primärschlüssel selber erstellen? Bei letzteren ist mir dann halt überhaupt nicht klar, wie es schaffe das die noch nicht in der DB sind. Also das sie eindeutig sind.

Gruß,
Snowwolf

4.207 Beiträge seit 2003
vor 19 Jahren

Hallo,

ich würde die Datenbank eine ID automatisch vergeben lassen, das ist die einfachste Möglichkeit, um sicherzugehen, dass sie wirklich eindeutig ist, diese dann abfragen und als Fremdschlüssel in die m:n-Tabelle zu schreiben.

Und gib der m:n-Tabelle unbedingt auch eine ID-Spalte!

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

C
65 Beiträge seit 2004
vor 19 Jahren

Also, so ungern ich dem Meister widerspreche, in dem Fall muss es sein. ADO.NET kann alles, aber die Verwaltung von AutoIncrement-IDs ist eine sehr aufwändige Sache, zumal mit einer Datenbank, die nicht "Microsoft SQL Server" heißt. Ich würde die IDs selbst erzeugen, und das, was sich da geradezu aufdrängt, sind GUIDs.

Da Du früher oder später händisch in Deinen Tabellen rumhacken wirst (eher früher, nämlich in der Testphase), mach die ID-Spalte zum String mit 40 Zeichen Breite. String-GUIDs sind 38 Zeichen breit, aber die einfachste Methode, GUIDs zu generieren, nämlich die übers VS.NET, erzeugt Registry-GUIDs, und die sind um "{" und "}" ergänzt. Wenn Du dann in Access oder was-auch-immer rumhantierst und Deine ID-Spalte 40 Zeichen breit ist, kannst Du die Registry-GUID einfach über Clipboard in die DB-Tabelle kopieren und die geschweiften Klammern nach dem Einfügen weglöschen.

Wenn Du im Code die GUID generierst, brauchst Du keine speziellen (d.h. DB-spezifischen) Konstrukte, um für alle drei Tabellen die Keys zu erzeugen.

Nebenbei, um meinen Vorschlag zum "Patterns & Practises"-Forum zu forcieren, werde ich mal hier unter "ADO.NET" was zur Benamung von Datenbanken, Tabellen und Feldern posten.

/// <summary>
/// Signatur
/// </summary>

C
980 Beiträge seit 2003
vor 19 Jahren

Nicht nur MSSQL unterstützt Stored Procedures. Falls solche zur Verfügung stehen würd ich sie auch ausnützen (zumindest um beim Insert gleich die automatisch generierte ID als Skalar zurückzuliefern) ... falls nicht ist der GUID Weg durchaus auch nicht unelegant, sofern die DB effizient mit ihnen umgehen kann (also nicht etwa in einem textfeld ablegen)

C
65 Beiträge seit 2004
vor 19 Jahren

Stored procedures sind aber wieder DB-abhängig und damit nur in sehr engen Grenzen portierbar, wenn man die DB-Engine wechselt. Ist aber wie immer Geschmacksache, und 20 Dinge sprechen dafür, Programmlogik in die DB zu schieben (Speed vor allem), und 20 Dinge dagegen. Ich halte es so, dass ich die DB möglichst wenig mit Logik fülle (nichtmal Constraints), sondern so gut wie alles in den Code packe.

/// <summary>
/// Signatur
/// </summary>

X
2.051 Beiträge seit 2004
vor 19 Jahren

wenn man es etwas weiter treibt, dann erstellt man ein 3 Shicht-Anwendung

  1. PL - Presentation Layer (WinForms, Web, etc.)
  2. BL - Business Logic (die Anwendung-Engine so zu sagen)
  3. DAL - Data Access Layer (wie der Name schon sagt)

und genau der 3. Punkt erlaubt es, eine Anwendung Datenbank unabhänging zu machen.

ist natürlich mit einem gewissen Aufwand verbunden und lohnt sich für kleinere Anwendungen warscheinlich gar nicht. da muss man sich aber auch keine Sorgen wegen Stored Procedures und Co machen.

4.207 Beiträge seit 2003
vor 19 Jahren

Hallo,

einen 38 Zeichen breiten VARCHAR als Primärschlüssel? lach ... viel Spaß bei der Performance von JOINs 😉.

Der Primärschlüssel sollte so klein wie möglich gehalten werden, also beispielsweise als INTEGER.

Außerdem ... wo siehst Du Probleme bei anderen Datenbanken als dem SQL Server, ein Feld automatisch hochzählen zu lassen? Habe das bislang bei MS SQL Server, MySQL, PostgreSQL und DB2 gemacht, und es gab keinerlei Probleme.

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

S
18 Beiträge seit 2004
vor 19 Jahren

Wenn du schon die Guid benutzen willst dann mach daraus wieder nen INT64..

Cu Sco

Debuggers dont remove bugs, they only show them in slow-motion.

Snowwolf3000 Themenstarter:in
140 Beiträge seit 2004
vor 19 Jahren

Ich glaub ich sollt mich auch mal wieder zu Wort melden.

Also:
Die AlbumKuenstlertabelle hat inzwischen einen eigenen Primärschlüssel.
Das ganze hab ich bisher in Access gemacht. Wäre aber auch keine große Geschichte auf ne vernünftige DB zu wechseln, wenns den sein muss 🙂

Der Weg von golohaas funktoniert schon mal.

Access unterstützt erstaunlicherweise auch GUIDs. Nennt sich dann Replikations-Ids. Der Weg über GUIDs funktoniert eigentlich auch. Ich habs geschafft zwei Datensätze einzufügen. Das Problem ist aber das die Guids irgendwie nicht eindeutig sind. Die haben bei mir immer die Struktur {00000000-0000-0000-0000-000000000000}.

So hab ich die bisher erzeugt:


Guid myGuid = new Guid();

N
4.644 Beiträge seit 2004
vor 19 Jahren
Guid.NewGuid();