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:
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
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
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>
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)
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>
wenn man es etwas weiter treibt, dann erstellt man ein 3 Shicht-Anwendung
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.
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
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.
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();