nicht angemeldet
Primary ID immer sinnvoll ?
1 0 0
Primary ID immer sinnvoll ?
Hallo zusammen,
ich habe es mir im Laufe der Zeite angewöhnt, bei jeder tabelle die ich erstelle, auch einen Primarykey festzulegen. Nun gibt es ja auch Datensätze/Tabellen wo dieses nicht nötig scheint, da mann auf den einzelnen Datensatz nicht zugreifen muss.
Zum Beispiel speichere ich in einer Tabelle die id der Nutzer, die einen Newsletter erhalten haben (hier als beispiel mit Primary):
id | newsletter_id | user_id
nun werde ich wohl nie im Leben auf einen Datensatz davon zugreifen müssen, weil ich es ja nie ändern muss, sondern es handelt sich ja nur um ein Archiv.
Wie seht ihr das? Immer einen Primary festlegen, oder nur wenn nötig?
Gruß und Dank für Eure Meinung
Tunnel85
-
Hello,
ich habe es mir im Laufe der Zeite angewöhnt, bei jeder tabelle die ich erstelle, auch einen Primarykey festzulegen. Nun gibt es ja auch Datensätze/Tabellen wo dieses nicht nötig scheint, da mann auf den einzelnen Datensatz nicht zugreifen muss.
Zum Beispiel speichere ich in einer Tabelle die id der Nutzer, die einen Newsletter erhalten haben (hier als beispiel mit Primary):
id | newsletter_id | user_id
nun werde ich wohl nie im Leben auf einen Datensatz davon zugreifen müssen, weil ich es ja nie ändern muss, sondern es handelt sich ja nur um ein Archiv.
Wie seht ihr das? Immer einen Primary festlegen, oder nur wenn nötig?
Im Prinzip wird hier eine M:N-Beziehungstabelle aufgemacht, deren Primary Key bereits aus dem Kombinationsschlussel der Schlüssel newsletter_id + user_id gebildet werden kann.
Das wäre übrigens auch sinnvoll, wenn man vermeiden will, dass ein User denselben Newsletter zweimal bekommt. Eine zusätzlcieh ID für den Datensatz ist also obsolet.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Eine zusätzlcieh ID für den Datensatz ist also obsolet.
Aber meistens einfacher handhabbar.
-
Hello,
Eine zusätzlcieh ID für den Datensatz ist also obsolet.
Aber meistens einfacher handhabbar.
Dann erzähl mir mal, wie Du das folgende Szenario handhaben willst:
-> newsletter_id + user_id werden als Schlüssel in die Tabelle eingetragen
mit newsletter_id + user_id wird gearbeitet
newsletter_id + user_id werden wieder gelöscht aus der Tabelle
mit newsletter_id + user_id wird gearbeitet (in diesem Falle, dass sie _nicht_ enthalten sind)
-> newsletter_id + user_id werden als Schlüssel in die Tabelle eingetragen
usw.welchen künstlichen Schlüssel würdest Du denn für die jeweiligen Eintragungen (->) vergeben?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Mahlzeit Tom,
-> newsletter_id + user_id werden als Schlüssel in die Tabelle eingetragen
[...]
-> newsletter_id + user_id werden als Schlüssel in die Tabelle eingetragen
welchen künstlichen Schlüssel würdest Du denn für die jeweiligen Eintragungen (->) vergeben?
Ähm ... einen AUTOINCREMENT-Wert?
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Ähm ... einen AUTOINCREMENT-Wert?
Daran dachte ich jetzt auch - ist jedenfalls menschenlesbarer - wenn man einen Datensatz gefunden hat ist "DELETE FROM table WHERE id = '1247'" auch einfacher und schneller zu tippen als "DELETE FROM table WHERE user = '23' AND newsletter = '42'"
-
Hi!
Daran dachte ich jetzt auch - ist jedenfalls menschenlesbarer - wenn man einen Datensatz gefunden hat ist "DELETE FROM table WHERE id = '1247'" auch einfacher und schneller zu tippen als "DELETE FROM table WHERE user = '23' AND newsletter = '42'"
Achwas, man muss ja erst einmal die ID herausfinden, wenn man nur User und Newsletter zur Verfügung hat. Im Allgemeinen interessiert diese ID überhaupt nicht. Sie wird bei JOINs - dem Hauptanwendungsfall solcher Verknüpfungstabellen - nicht benötigt. Warum also sollte man sie vorliegen haben? Wenn man die Verknüpfungen selbst auflistet, um sie zu verwalten, wird dies der Fall sein, aber wenn du schon die Menschenlesbarkeit ins Spiel bringst - die sicherlich das kleinste Problem im gesamten Anwendungsfall ist - dann ist eher aus User-ID und Newsletter-ID eine Information zu entnehmen als aus einer unzusammenhängenden dritten Zahl.
Lo!
-
Hallo!
Ähm ... einen AUTOINCREMENT-Wert?
Daran dachte ich jetzt auch - ist jedenfalls menschenlesbarer -
Menschenlesbar ist an dieser Stelle nun wirklich kein Argument - eine zusätzliche ID ist einfach nur Ballast an dieser Stelle - die Verknüpfung zweier Schlüssel zu einem Datensatz ist doch selbsterklärend.
wenn man einen Datensatz gefunden hat ist "DELETE FROM table WHERE id = '1247'" auch einfacher und schneller zu tippen als "DELETE FROM table WHERE user = '23' AND newsletter = '42'"
Komm, bitte!
Ciao
GG
--
"If I do not seek to understand what is happening here
- then I've got peanuts in my head!"
(I. Hosein)-
Menschenlesbar ist an dieser Stelle nun wirklich kein Argument - eine zusätzliche ID ist einfach nur Ballast an dieser Stelle - die Verknüpfung zweier Schlüssel zu einem Datensatz ist doch selbsterklärend.
Für mich ist Menschenlesbarkeit immer ein Argument - zumindest ist das die Begründung warum man bei MediaWiki, phpBB oder TYPO3 keine Nested Sets verwendet :)
-
Hallo!
Menschenlesbar ist an dieser Stelle nun wirklich kein Argument - eine zusätzliche ID ist einfach nur Ballast an dieser Stelle - die Verknüpfung zweier Schlüssel zu einem Datensatz ist doch selbsterklärend.
Für mich ist Menschenlesbarkeit immer ein Argument -
Deshalb magst Du bestimmt auch XML so gern;)
zumindest ist das die Begründung warum man bei MediaWiki, phpBB oder TYPO3 keine Nested Sets verwendet :)
Ok!
Ciao
GG
--
"If I do not seek to understand what is happening here
- then I've got peanuts in my head!"
(I. Hosein)-
Für mich ist Menschenlesbarkeit immer ein Argument -
Deshalb magst Du bestimmt auch XML so gern;)
Richtig, ich bin Codefetischist :p
-
-
-
-
-
-
Hello,
Eine zusätzlcieh ID für den Datensatz ist also obsolet.
Ausnahme könnte nur durch eine beispielsweise vorgeschrieben (dateschutzrechtliche) Entkopplung der IDs gegeben sein.
Aber meistens einfacher handhabbar.
Dann erzähl mir mal, wie Du das folgende Szenario handhaben willst:
-> newsletter_id + user_id werden als Schlüssel in die Tabelle eingetragen
mit newsletter_id + user_id wird gearbeitet
newsletter_id + user_id werden wieder gelöscht aus der Tabellemit newsletter_id + user_id wird gearbeitet (in diesem Falle, dass sie _nicht_ enthalten sind)
Ich habe mir gerade die anderen Postings hierzu angesehen.
Wie wollt Ihr die obige Anforderung handhaben bei einer zusätzlichen ID?-> newsletter_id + user_id werden als Schlüssel in die Tabelle eingetragen
usw.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
Hi,
Wie seht ihr das? Immer einen Primary festlegen, oder nur wenn nötig?
Nur wenn nötig. Ich arbeite hier z.b. mit Meta-Datenbanken, die nichts anderes tun, als temporär Daten aufzunehmen, um dann später von anderen Applikationen modifiziert und wieder in andere Datenbanken weitergeschaufelt werden. Diese Datensätze bringen eigene ID-Strukturen mit, zusätzliche auto_increment IDs oder whatever wären also sinnlos bzw. sogar störend.
Die Anzahl der Einträge ist hier jeweils > 1000.000 Datensätzegruss
blotto -
moin,
ich habe es mir im Laufe der Zeite angewöhnt, bei jeder tabelle die ich erstelle, auch einen Primarykey festzulegen.
man kann über dieses thema streiten, aber ich habe mir das auch angewöhnt und es hat vorteile. zum einen benutze ich "eineindeutige" schlüssel für jeden datensatz über die gesamte datenbank. das ist mit dem dbms von oracle möglich, weil es dort keine autoincrement werte auf tabellen ebene benutzt werden, sondern eigene objekte, sogenannte sequenzen.
der vorteil liegt darin, dass du alle deine tabellen einheitlich aufbauen kannst, wir benutzen zum beispiel für den primarykey immer den Prefix, der in keiner anderen spalte benutzt wird. ich halte die administration damit für besser, zum beispiel wenn ich mit einem PL/SQL script über alle tabellen gehen und den primarykey erstelle. ich mache es mit einem script, um die namen der primary keys nach einem bestimmten schema zu erstellen.
bilden spalten zusammen einen eindeutigen schlüssel, dann legen wir dafür auch einen UNIQUE key an, damit die integrität gewahrt bleibt, als nebeneffekt hat man dann auch gleich einen guten index.
nun werde ich wohl nie im Leben auf einen Datensatz davon zugreifen müssen, weil ich es ja nie ändern muss, sondern es handelt sich ja nur um ein Archiv.
ändern ist was anderes als zugreifen. die tabelle wird schon einen sinn haben, sonst würdest du sie ja nicht erstellen.
Ilja