PrimaryKeys - welchen nehme ich? – SELFHTML-Forum Forum als Ergänzung zum SELFHTML-Wiki und zur Dokumentation SELFHTML https://forum.selfhtml.org/self PrimaryKeys - welchen nehme ich? Mon, 24 Jul 06 22:51:55 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999132#m999132 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999132#m999132 <p>Hallo allerseits,</p> <p>ich habe in einer Tabelle ein Attribut "URL" (varchar(255)), das bereits minimal identifizierend ist. Spricht irgendwas dagegen, das dann auch als Primary Key einzusetzen? Oder sollte ich besser einen extra Schluessel einfuehren?</p> <p>Danke für eure Hilfe,<br> Eddie</p> <div class="signature">-- <br> Old men and far travelers may lie with authority. </div> PrimaryKeys - welchen nehme ich? Mon, 24 Jul 06 23:30:11 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999155#m999155 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999155#m999155 <p>Hallo,</p> <p>das ist eine Prinzipienfrage. Prinzipiell kann man einen eindeutigen Wert natürlich als Schlüssel verwenden, man sollte sich allerdings der Konsequenzen bewusst sein. Wenn das zugrunde liegende Datenmodell wächst, dann werden früher oder später Beziehungen zu dieser Tabelle entstehen. Wenn du nicht mit einem künstlichen Schlüssel arbeitest, musst du die URL in den anderen Tabellen als Fremdschlüssel verwenden. Das ist speichertechnisch evtl. nicht sehr effizient.<br> Was in aller Regel schwerer wiegt ist die Frage "was passiert wenn sich eine URL ändert?" Im Normalfall (künstlicher Schlüssel), na ja Gott, da passt man halt die URL an, alle Schlüssel sind gewahrt. Wählst du allerdings einen sprechenden Schlüssel, dann zieht diese Änderung einen riesigen Rattenschwanz nach sich, weil du plötzlich überall die Fremdschlüssel anpassen muss. Das ist eine Situation, die man eigentlich gerne vermeiden möchte.</p> <p>MfG<br> Rouven</p> <div class="signature">-- <br> -------------------<br> "I wish it need not have happened in my time" - "So do I, and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us."  --  J.R.R. Tolkien: "The Lord Of The Rings: The Fellowship Of The Ring" </div> PrimaryKeys - welchen nehme ich? Mon, 24 Jul 06 23:46:13 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999134#m999134 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999134#m999134 <p>Moin!</p> <blockquote> <p>ich habe in einer Tabelle ein Attribut "URL" (varchar(255)), das bereits minimal identifizierend ist. Spricht irgendwas dagegen, das dann auch als Primary Key einzusetzen? Oder sollte ich besser einen extra Schluessel einfuehren?</p> </blockquote> <p>Ein Schlüssel des Typs varchar(255) benötigt schlimmstenfalls 255 Byte je Dateneintrag - auch bei Referenzierungen in anderen Tabellen.</p> <p>Ein Schlüssel vom Typ BIGINT benötigt 8 Byte (kleinere Int-Typen entsprechend weniger). Eine URL hingegen benötigt ja schon mindestens 3 Zeichen für "://", dann noch 3 bis 4 Zeichen für das Protokoll (ftp, http,...), und die Domain besteht auch mindestens aus 4 Zeichen (Länderdomain plus kürzestmögliche SecondLevelDomain = x.yz). In der Summe also 10 Bytes für eine extrem unwahrscheinliche URL.</p> <p>Natürlich muß die URL so oder so gespeichert werden, egal ob sie nun Primary Key ist, oder nicht. Aber der Sinn eines Primärschlüssels ist ja gerade, ihn als Fremdschlüssel in anderen Tabellen zu verwenden - und genau da wirds dann verschwenderisch beim Speicherplatz.</p> <p>Die URL grundsätzlich als UNIQUE-Index zu definieren ist davon unabhängig - dient aber in erster Linie dazu, dass die Datenbank Duplikate verhindert. Aber gerade sowas ist bei URLs problematisch, denn zwei unterschiedliche URLs können dennoch die gleiche Ressource bezeichnen - sei es durch Redirect, serverinterne Duplizierung oder unterschiedliche Codierung der URL. Umgekehrt kann unter einer einzigen URL durchaus unterschiedlicher Content erreichbar sein (Content Negotiation mit unterschiedlichen Sprachen oder Kompression).</p> <p>Eine URL ist daher bei genauer Betrachtung gar nicht so einzigartig, wie man es vielleicht gerne hätte. Und damit potentiell ungeeignet als Key in der Datenbank.</p> <p>- Sven Rautenberg</p> <div class="signature">-- <br> "Love your nation - respect the others." </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 00:06:03 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999133#m999133 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999133#m999133 <p>Danke euch beiden, hat mir sehr geholfen! Warum ich selbst nicht soweit gedacht habe (was den Speicherplatz und die Persistenz angeht), weiss ich jetzt auch nicht... Naja, 's ist ja schon spaet... :-)</p> <p>Eddie</p> <div class="signature">-- <br> Old men and far travelers may lie with authority. </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 05:11:03 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999135#m999135 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999135#m999135 <p>Salut,</p> <p>d'accord zum grössten Teil.</p> <p>Es hängt auch teilweise vom verwendeten DBMS ab, wie es mit mit Primary<br> Keys umgeht. Und es muss nicht immer der PK einer Tabelle sein, der<br> für Foreign Key Beziehungen verwendet werden kann. Evt. kann man auch<br> Unique Keys verwenden. Und imho liegt der hauptsächliche Sinn des PK<br> darin, den Datensatz in einer Tabelle physikalisch eindeutig zu identi-<br> fizieren. U.U. entscheidet der PK dann auch über die physikalische<br> Reihenfolge der Datensätze.</p> <p>In dem Fall sollte man folgende Best Practices zum PK befolgen:</p> <ul> <li>so klein wie möglich, so gross wie nötig</li> <li>eindeutig und statisch (unveränderlich)</li> <li>sequentiell fortlaufend</li> </ul> <p>Grüsse und einen hübsch heissen Arbeitstag :)<br> Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 08:45:30 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999136#m999136 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999136#m999136 <p>yo,</p> <blockquote> <p>Und imho liegt der hauptsächliche Sinn des PK<br> darin, den Datensatz in einer Tabelle physikalisch eindeutig zu identi-<br> fizieren.</p> </blockquote> <p>ich würde da eher logisch zu sagen. zum beispiel wäre bei oracle nicht der pk, sondern die rowid für die physikalische speicherung zuständig.</p> <blockquote> <p>U.U. entscheidet der PK dann auch über die physikalische<br> Reihenfolge der Datensätze.</p> </blockquote> <p>wäre mir neu, bzw, was genau meinst du damit ?</p> <blockquote> <ul> <li>sequentiell fortlaufend</li> </ul> </blockquote> <p>nicht wirklich, es werden zwar gerne autoincrement werte genommen, weil das wohl der einfachste weg ist, um den kind einen eindeutigen namen zu geben. aber bei tabellen handelt es sich sowieso um eine unsortierte menge, insofern spielt es auch keine rolle, wenn sie nicht sequentiell fortlaufend sind.</p> <p>Ilja</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 12:41:37 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999137#m999137 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999137#m999137 <p>Hi,</p> <p>deswegen schrieb ich als 2. Satz, es hängt vom verwendeten Datenbank-<br> system ab. Dafür hast du ja auch das Beispiel mit der rowid von Oracle<br> gebracht. :)</p> <blockquote> <p>sondern die rowid für die physikalische speicherung zuständig<br> tabellen handelt es sich sowieso um eine unsortierte menge</p> </blockquote> <p>Widersprichst du dir da nicht etwas selbst? Wenn die physikalische<br> Speicherung sich durch die rowid ausdrückt und diese durch einen<br> Algorithmus bestimmbar ist, dann ist die rowid ordbar und somit die<br> ganze Tabelle keine unsortierte Menge mehr. Und auch sonst, wenn<br> die Menge unsortiert ist, wie willst du gewährleisten, dass zum<br> deinem Schlüssel X die richtigen Werte gelesen werden, irgendwo<br> muss dann eine Verbindung zur physikalischen Speichermenge bestehen....</p> <p>Im Falle von MS SQL Server existieren die Clustered und Nonclustered<br> Keys. Der (es ist nur einer möglich) Clustered Key einer Tabelle<br> bestimmt die physikalische Reihenfolge der Daten in der Tabelle. Man<br> kann zwar auch reine Heaptabellen ohne Ordnung anlegen (-> unsortierte<br> Menge) aber im Normalfall sind Tabellen in MS SQL über ihren Clustered<br> Key geordnet. Und da für den Clustered Key fast identische Anforderungen<br> (aus logischer Sicht) gelten wie für einen Primary Key wird beides<br> meist zusammen als PRIMARY KEY CLUSTERED.</p> <p>Der Sinn von dann sequentiell fortlaufenden Werten für den Key<br> besteht darin, dass die neue Daten immer am Ende der Datenmenge<br> angehängt werden und keine Splits innerhalb der Datenmenge<br> durchgeführt werden müssen, was unweigerlich zur Fragmentierung<br> führt. Insofern ist die vielverfolgte Ideologie von .Net Entwicklern,<br> eine Guid zum PK zu machen, kontraförderlich mit steigender Daten-<br> menge. (Die Gründe kannst du dir denken).</p> <p>Aber, eben, wie ich sagte, es ist abhängig vom DBMS, wie es seine<br> Speicherallokation für Daten vornimmt. Und schaden tut ein<br> sequentiell fortlaufender key sicher nicht, und bequem zu<br> produzieren ist er auch :)</p> <p>Als denn, Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 13:06:07 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999148#m999148 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999148#m999148 <p>hi,</p> <blockquote> <p>Und schaden tut ein sequentiell fortlaufender key sicher nicht, und bequem zu produzieren ist er auch :)</p> </blockquote> <p>Aber nicht so bequem beizubehalten, wenn Datensätze gelöscht werden.</p> <p>gruß,<br> wahsaga</p> <div class="signature">-- <br> /voodoo.css:<br> #GeorgeWBush { position:absolute; bottom:-6ft; } </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 13:56:54 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999138#m999138 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999138#m999138 <p>yo,</p> <blockquote> <p>deswegen schrieb ich als 2. Satz, es hängt vom verwendeten Datenbank-<br> system ab. Dafür hast du ja auch das Beispiel mit der rowid von Oracle<br> gebracht. :)</p> </blockquote> <p>das hat mit orakel nichts zu tun, sondern kein dbms hat als pk einen bezug zu der physikalischen speicherung. wie sollte das im falle eines autoincrement wertes auch aussehen ? ich habe dann zum beispiel den wert 1373 für einen datensatz, der damit eindeutig in der tabelle idientiziert wird. und wie drückt sich mit dieser zahl der physikalische speicherort aus ? ich kann daran nicht physikalische, sondern nur logisches erkennen.</p> <blockquote> <p>Widersprichst du dir da nicht etwas selbst? Wenn die physikalische<br> Speicherung sich durch die rowid ausdrückt und diese durch einen<br> Algorithmus bestimmbar ist, dann ist die rowid ordbar und somit die<br> ganze Tabelle keine unsortierte Menge mehr.</p> </blockquote> <p>wie kommst du den darauf, was hat das eine mit dem anderen zu tun ? wenn ich einen plan habe, wo ich einen apfel und eine birne bei mir in der küche finden kann, da ist doch damit noch nicht gesagt, in welcher reihenfolge ich das obst essen werde.</p> <blockquote> <p>Und auch sonst, wenn<br> die Menge unsortiert ist, wie willst du gewährleisten, dass zum<br> deinem Schlüssel X die richtigen Werte gelesen werden, irgendwo<br> muss dann eine Verbindung zur physikalischen Speichermenge bestehen....</p> </blockquote> <p>relationale dbms bestehen auf der grundlage der mengenlehre. insofern sind alle tabellen per definition unsortiert. wie sollte es auch anders sei, die sortierreihenfolge kann sich ja je nach abfrage ändern. ich kann doch nicht für jede mögliche art der sortierung die daten abspeichern, nur damit sie hintereinander stehen.</p> <blockquote> <p>Der Sinn von dann sequentiell fortlaufenden Werten für den Key<br> besteht darin, dass die neue Daten immer am Ende der Datenmenge<br> angehängt werden und keine Splits innerhalb der Datenmenge<br> durchgeführt werden müssen, was unweigerlich zur Fragmentierung<br> führt.</p> </blockquote> <p>diese aussage kann ich für dbms nicht bestätigen. woher beziehst du diese information. wie gesagt, bei abfragen ist es doch in aller regel schnuppe, in welcher reifenfolge die pk nun gewählt werden, sondern nur, das er eindeutig ist und nicht NULL. autoincrement-werte sind doch nur deswegen so sinnvoll, weil es so schön einfach ist, den datensätzen einen eindeutigen namen zu geben. es könnte aber durchaus auch ganz "ungeordnet" passieren und das dbms hätte  damit keine probleme.</p> <blockquote> <p>Aber, eben, wie ich sagte, es ist abhängig vom DBMS, wie es seine<br> Speicherallokation für Daten vornimmt. Und schaden tut ein<br> sequentiell fortlaufender key sicher nicht, und bequem zu<br> produzieren ist er auch :)</p> </blockquote> <p>wie genau nun ein dbms seine daten physikalisch speichert, dass ist sicherlich individuell. aber es hängt mit sicherheit nicht von dem -> inhalt <- des pk ab. und nur dann würde es einen physikalischen bezug geben können.</p> <p>Ilja</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 14:21:27 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999139#m999139 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999139#m999139 <p>kurze Gegenfrage:</p> <p>Wenn du Birnen in deiner Küche suchst, fängst du dann zwischen den<br> Äpfeln an zu suchen?</p> <p>Ciao, Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 15:18:55 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999143#m999143 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999143#m999143 <p>hi,</p> <blockquote> <p>Wenn du Birnen in deiner Küche suchst, fängst du dann zwischen den<br> Äpfeln an zu suchen?</p> </blockquote> <p>Dafür hast du ja ein DBMS - dass du gar nicht zwischen irgendwas suchen musst. Sondern einfach sagst, gib mir alle Birnen, und gut is'.</p> <p>gruß,<br> wahsaga</p> <div class="signature">-- <br> /voodoo.css:<br> #GeorgeWBush { position:absolute; bottom:-6ft; } </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 16:48:48 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999140#m999140 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999140#m999140 <p>yo,</p> <blockquote> <p>Wenn du Birnen in deiner Küche suchst, fängst du dann zwischen den<br> Äpfeln an zu suchen?</p> </blockquote> <p>wie wahsaga schon sagte, bin ich gar nicht dafür verantworlich, wo die birnen und die äpfel nun sind. genau diese eigenschaft ist es, die datenbanken so universell macht.</p> <p>aber um von dem beispiel mit dem obst ein wenig wegzukommen und wieder hin zu dem pk. dein argument ist es ja, die datensätze mit "ähnlichen" bzw. forlaufenden inhalten zusammen zu halten, um abfragen letztlich effizienter zu machen. dies ist aber ein trugschluss. die aufgabe eines pk ist einzig und allein, den datensatz eindeutig zu identifizieren und nichts weiter.</p> <p>die eigenschaft, dass es sich bei dem einen pk eventuell um den nachfolger handelt (zum beispiel datensatz 14 und 15), hat überhaupt keine aussage darüber, ob diese beiden datensätze auch nun öfter zusammen abgerufen werden. ganz im gegenteil sind es allen anderen spalten aber nicht der pk. so könnte ich mir vorstellen, orte mit gleichen inhalt zusammen zuhalten oder datensätze, die über ein fremdschlüssel miteinander verbunden sind. dort ist die wahrscheinlichkeit wesentlich höher, dass ich sie zusammen abrufe. aber genau solche eine aussage kann ich über den pk nicht machen.</p> <p>Ilja</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 17:53:29 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999141#m999141 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999141#m999141 <p>Hallo nochmal,</p> <p>auf die Effizienz bei Abfragen, dass 15 nach 14 kommt wollte ich gar<br> hinaus, sondern auf der anderen Seite, wenn es darum geht, Daten zu<br> schreiben. Also nix mit "öfter gemeinsam abgerufen werden".</p> <blockquote> <p>bin ich gar nicht dafür verantworlich, wo die birnen und die äpfel nun sind.</p> </blockquote> <p>d'accord, hab ich auch nie behauptet. Das DBMS trägt die Verantwortung<br> dafür, einen beliebigen Datensatz X anhand deiner Kriterien zu finden<br> und dies zudem noch in einer entsprechend kurzen Zeit. Dazu kann es<br> die ganze Tabelle von vorn (einen Anfang muss die Tabelle ja haben)<br> bis hinten (ein Ende auch) one by one durchsuchen, bis es einen oder<br> entsprechend viele gefunden hat, die deinem Kriterium entsprechen.</p> <p>Und damit dies schneller vonstatten geht, benutzt man Indizes, denn<br> diese, da wirst du mir sicher nicht widersprechen wollen, sind sortiert.<br> Was ist denn genau der Primary Key einer Tabelle? Basiert er nicht auf<br> einem Index? Und welche Daten beinhaltet er? Und warum?<br> ... damit das DBMS weiss, an welcher Stelle es mehr oder weniger Sinn<br> macht im Datenbrei von Bytes zu lesen.</p> <p>Was passiert, wenn es keinen einzigen Index oder Primary Key auf einer<br> Tabelle gibt? Ein Full Table Scan, das hatten wir ja grad schon</p> <p>Keine Ahnung, wie MySQL seine Datensätze physikalisch ausfindig macht,<br> jedoch wird es wohl nicht viel anders funktionieren.<br> Bei Oracle ist lt. deiner Aussage die RowId für die physikalische<br> Speicherung verantwortlich, wie funktioniert diese RowId?<br> Zufallswerte?</p> <p>Stell dir einfach vor eine Tabelle mit einem alphanumerischen PK: A-Z0-9<br> Key     | Payload<br> -----------------------------------------------<br> Alf     | Hello World !<br> Frei    | Hello Ilja !<br> Kohl    | Hello wahsaga !<br> Zauber  | Hello SelfHtml !<br> im Datenbrei sieht das dann so aus (Beispiel)</p> <p>Alf|Hello World !||Frei|Hello Ilja !||Kohl|Hello wahsaga !||Zauber|Hello SelfHtml !EOF</p> <p>Jetzt kommt ein weiterer Datensatz hinzu,</p> <p>Key     | Payload<br> -----------------------------------------------<br> Muster  | Hello Cheatah !</p> <p>Wo wird dieser im Datenbrei dann hingeschrieben?</p> <p>[ ] Ans Ende     (wäre vernünftig und nicht unlogisch)<br> [ ] Zwischen "Kohl" und "Zauber"  (wäre das unlogisch?)</p> <p>Wo wird der Schlüssel-Wert des PK hingeschrieben?<br> [ ] Ans Ende     (warum?)<br> [ ] Zwischen "Kohl" und "Zauber"  (warum?)</p> <p>Was passiert im jeweils 2. Fall? Alles nach "Muster" kommt muss um<br> die Datenmenge des neuen Eintrages (Tabelle oder Index Node)<br> verschoben werden. In sofern wäre es günstig, wenn das nur beim Index<br> bzw. dem PK notwendig wäre, weil weniger Daten, oder?</p> <p>Am Beispiel MS SQL kann ich dem Primary Key sagen, dass er für die<br> Ordnung der Daten in den Blöcken und Seiten verantwortlich ist.<br> Ein numerischer PK mit aufsteigender Sortierordnung würde also<br> Datensätze, die einen niedrigen Schlüsselwert haben, am Anfang<br> speichern... usw. Lass ich den PK weg habe ich, wie du das so schön<br> behauptest, eine wirklich unsortierte Menge. Ansonsten eine sortierte.</p> <p>Ein streng fortlaufender Schlüsselwert ist sofern generell besser,<br> da er mindestens an einer Stelle das wiederholte unnötige Verschieben<br> von Daten unterdrücken kann, da neue Daten generell nur am Ende<br> angefügt werden. Weniger Fragmentierung, weniger Leseaufwand usw.<br> Alles was ich mitteilen wollte.</p> <p>Aber kläre doch mal bitte über Oracles RowID auf, oder wie es sich<br> bei MySQL verhält, das wäre sicher informativ für das Publikum.</p> <p>Ich hoffe, das ist jetzt angekommen.<br> Cheers,<br> Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 23:56:04 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999142#m999142 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999142#m999142 <p>yo,</p> <p>grundsätzlich bleibe ich dabei, das der inhalt des pk keinen bezug auf die physikalische reihenfolge der speicherung hat.</p> <p>allerdings habe ich ein wenig in einem mssql buch geschnuppert und festgestellt, dass mssql nicht nur einen index für einen pk anlegt, was einen zeiger auf den eigentlich datensatz beinhalten würde, welche wiederum unsortiert abgespeichert würden, sondern einen sogenannten gruppierten index, den du auch bei deinem letzten post angesprochen hast. insofern liegt mit einem pk auch automatisch eine sortierte tabelle unter mssql vor. aber dies ist nicht die regel und kann man somit auch nicht auf den pk verallgemeinern. hier geht mssql offensichtlich einen eigenen weg.</p> <blockquote> <p>Bei Oracle ist lt. deiner Aussage die RowId für die physikalische<br> Speicherung verantwortlich, wie funktioniert diese RowId?<br> Zufallswerte?</p> </blockquote> <p>eher umgekehrt, die rowid bestimmt nicht, wo etwas gespeichert wird, sondern beinhaltet vielmehr, wo der datensatz gespeichert wurde.</p> <p>Ilja</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 18:00:05 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999144#m999144 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999144#m999144 <p>Ja, toll ... klasse Antwort, und stell dir vor, du bist jetzt das DBMS. Mit welchen Hilfsmitteln gehst du als DBMS auf die Suche nach den Datensätzen?</p> <ul> <li>Für jedes gefundene, annähernd runde Objekt tue<br>   - kosten<br>     - wenn schmeckt wie Birne = richtiges Objekt<br>     - wenn nicht, weiter<br>   .. nächstes Objekt</li> </ul> <p>oder</p> <ul> <li>Birnen liegen frühestens in Stiege 2, also brauch ich in Stiege 1 gar nicht suchen, spart Zeit und ich muss keine Pferdeäpfel kosten ;)</li> </ul> <p>...</p> <p>Das (welche Anstrengung das DBMS zur Lokalisierung von Datensätzen unternehmen muss) ist genau der Kernpunkt der Diskussion, an dem du leider vorbeigeschrammt bist.</p> <p>Adios, so long<br> Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 18:32:36 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999145#m999145 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999145#m999145 <p>hi,</p> <blockquote> <p>Ja, toll ... klasse Antwort, und stell dir vor, du bist jetzt das DBMS. Mit welchen Hilfsmitteln gehst du als DBMS auf die Suche nach den Datensätzen?</p> <ul> <li>Für jedes gefundene, annähernd runde Objekt tue<br>   - kosten<br>     - wenn schmeckt wie Birne = richtiges Objekt<br>     - wenn nicht, weiter<br>   .. nächstes Objekt</li> </ul> </blockquote> <p>Wenn ich dummerweise keinen geeigneten Index hätte, müsste ich das wohl tun, ja.</p> <blockquote> <p>oder</p> <ul> <li>Birnen liegen frühestens in Stiege 2, also brauch ich in Stiege 1 gar nicht suchen, spart Zeit und ich muss keine Pferdeäpfel kosten ;)</li> </ul> <p>...</p> </blockquote> <p>Ja, ein (binärer) Suchbaum würde mir hierbei sicherlich schon ein wenig weiterhelfen.</p> <p>Aber der wird dann sicherlich auf der Spalte "Obstart" liegen - und nicht auf dem PK, der - wenn ich dich mit deiner Argumentation für einen "fortlaufenden" PK richtig verstanden habe - wohl als sowas wie das "Einlieferungsdatum" verstanden werden könnte.</p> <p>Nein, mich interessiert beim Suchen kein Bisschen, ob eine Birne als erstes Stück Obst, als 711tes oder als 3782tes eingeliefert wurde.<br> Was mich interessiert ist, dass sie alle in der Kiste mit der Aufschrift "Birnen" liegen. Das ist aber der Index auf der Obstart, und hat mit dem PK absolut nichts zu tun.</p> <blockquote> <p>Das (welche Anstrengung das DBMS zur Lokalisierung von Datensätzen unternehmen muss) ist genau der Kernpunkt der Diskussion, an dem du leider vorbeigeschrammt bist.</p> </blockquote> <p>Irgendwie habe ich das gefühl, dass du diesbezüglich noch ein wenig weiter vom Weg abgekommen bist als ich.</p> <p>gruß,<br> wahsaga</p> <div class="signature">-- <br> /voodoo.css:<br> #GeorgeWBush { position:absolute; bottom:-6ft; } </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 19:17:33 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999146#m999146 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999146#m999146 <p>Ja, irgendwie reden wir etwas aneinander vorbei ... ich hab mich dummer-<br> weise weiter auf die Obst- und Gemüsediskussion eingelassen. (Die ging<br> in eine andere Richtung)</p> <p>Vielleicht desterwegen einfach nochmal Klartext (zmd. ein Versuch):</p> <p>Unter der Voraussetzung, dass ein DBMS nicht nur Heaptabellen hat, sondern<br> Tabellen, deren Inhalte sortiert (PK, da sind wir uns doch einig, dass<br> ein PK eine Sortierung hat) sind, ist es physikalisch für das DBMS von<br> Vorteil, wenn neue Daten(sätze) sequentiell am Ende (der Blöcke, Seiten,<br> Nodes) angefügt werden, da damit eine implizite Neuorganisation der<br> Sortierung (Splits) und Verschiebung von Daten unterbunden wird. Es<br> führt zu einer kompakteren, weniger fragmentierten physikalischen<br> Speicherung der eigentlichen Daten so dass weniger Lese/Schreib-Sprünge<br> zwischen den physikalischen Einheiten notwendig sind, was bei grossen<br> Datenmengen zu höherer Transaktionsverarbeitung führt.</p> <p>Das mag bei verschiedenen DBMS mehr oder weniger deutlich oder<br> beeinflussend implementiert sein.</p> <p>Bei MS SQL und allem darauf basierenden ist es eine Best Practice,<br> das physikalische Modell so zu implementieren.</p> <p>Vielleich hätte ich das "MS SQL" heute früh um Sieben mit hinzufügen<br> sollen, um missverständnisse zu vermeiden, aber dafür war ich noch<br> nicht ausgeschlafen genug. Mir geht es auch nicht darum, zu sagen,<br> dass es jetzt mit MS SQL ultratoll gelöst ist, definitiv nicht,<br> sondern nur darum, dass es gewisse Prinzipien gibt, an die man sich<br> als Entwickler halten sollte, wenn man mit RDBMS'sen arbeitet.</p> <p>Als denn,<br> Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 20:20:54 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999147#m999147 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999147#m999147 <p>hi,</p> <blockquote> <p>Unter der Voraussetzung, dass ein DBMS nicht nur Heaptabellen hat, sondern Tabellen, deren Inhalte sortiert (PK, da sind wir uns doch einig, dass ein PK eine Sortierung hat) sind,</p> </blockquote> <p>Nein, da sind wir uns nicht einig.</p> <blockquote> <p>ist es physikalisch für das DBMS von<br> Vorteil, wenn neue Daten(sätze) sequentiell am Ende (der Blöcke, Seiten,<br> Nodes) angefügt werden, da damit eine implizite Neuorganisation der<br> Sortierung (Splits) und Verschiebung von Daten unterbunden wird. Es<br> führt zu einer kompakteren, weniger fragmentierten physikalischen<br> Speicherung der eigentlichen Daten so dass weniger Lese/Schreib-Sprünge<br> zwischen den physikalischen Einheiten notwendig sind, was bei grossen<br> Datenmengen zu höherer Transaktionsverarbeitung führt.</p> </blockquote> <p>Das mag ja sein - aber was hat der PK damit zu tun?</p> <blockquote> <p>Das mag bei verschiedenen DBMS mehr oder weniger deutlich oder<br> beeinflussend implementiert sein.</p> </blockquote> <p>Ode rauch gar nicht?</p> <blockquote> <p>Bei MS SQL und allem darauf basierenden ist es eine Best Practice,<br> das physikalische Modell so zu implementieren.</p> <p>Vielleich hätte ich das "MS SQL" heute früh um Sieben mit hinzufügen</p> </blockquote> <p>Wenn du mit der internen Arbeitsweise des DBMS MS SQL so vertraut bist, nehme ich das mal als Tatsache hin.<br> Aber daraus auf das Verhalten anderer DBMS zu schließen, würde ich nicht wagen.</p> <p>gruß,<br> wahsaga</p> <div class="signature">-- <br> /voodoo.css:<br> #GeorgeWBush { position:absolute; bottom:-6ft; } </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 14:18:43 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999149#m999149 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999149#m999149 <p>Hallo,</p> <blockquote> <p>Aber nicht so bequem beizubehalten, wenn Datensätze gelöscht</p> </blockquote> <p>werden.</p> <p>Könntest du dich bitte etwas näher erklären? Was willst du<br> beibehalten und warum? Zielst du auf das Wiederauffüllen von<br> Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.</p> <p>Ciao, Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 15:18:09 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999153#m999153 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999153#m999153 <p>hi,</p> <blockquote> <p>Zielst du auf das Wiederauffüllen von<br> Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.</p> </blockquote> <p>Eben.</p> <p>gruß,<br> wahsaga</p> <div class="signature">-- <br> /voodoo.css:<br> #GeorgeWBush { position:absolute; bottom:-6ft; } </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 16:15:08 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999150#m999150 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999150#m999150 <p>Hallo Frank,</p> <blockquote> <blockquote> <p>Aber nicht so bequem beizubehalten, wenn Datensätze gelöscht<br> werden.</p> </blockquote> </blockquote> <blockquote> <p>[...] Zielst du auf das Wiederauffüllen von<br> Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.</p> </blockquote> <p>Warum macht das keinen Sinn? Wenn ich einen begrenzten Wertebereich fuer meinen Primary Key habe (bspw. int), dann komme ich doch automatisch irgendwann ans Ende - auch wenn meine DB dann nur einen einzigen Eintrag hat. Oder?</p> <p>Und falls ich das nicht vollkommen falsch sehe: wie bekomme ich die Luecken dann gestopft? Macht das mein DBMS automatisch, oder bin ich mit autoincrement dann tatsaechlich am Ende?</p> <p>Eddie</p> <div class="signature">-- <br> Old men and far travelers may lie with authority. </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 18:18:10 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999152#m999152 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999152#m999152 <p>Hallo,</p> <p>int32 = int hat einen hat einen Wertebereich von ca. 2 Millarden wenn<br> man nur die positiven Werte nimmt aber ein Vorzeichen per Definition<br> ermöglicht.</p> <p>Wann wirst du die Grenze voraussichtlich erreichzen? Zur not gibt es<br> noch int64 = long .. verbraucht nur 4 byte mehr als ein int32 und<br> kann dafür 9.223.372.036.854.775.807 positive Werte annehmen. Und<br> dann gibt es auch noch int128 ... :)</p> <p>Warum es u.a. keinen Sinn macht:</p> <ul> <li>weil der Aufwand, die Lücken zu finden ungerechtfertigt hoch wäre (extra queries)</li> <li>weil es kein technisch rechtfertigendes Argument gibt, es zu tun</li> </ul> <p>... mehr fällt mir ad-hoc dazu grad nicht ein ... biernot :)<br> Aber das Archiv dieses tollen Forums kann dir sicher noch weitere<br> Argumente liefern.</p> <p>Ein PK ist ein rein technisches Feature von DBMS um für sich Datensätze<br> eindeutig zu identifizieren. Es sollte nie für Geschäftszwecke verwendet,<br> also einen Sinn jenseits der technischen Bedüütig haben. Eben aus o.g.<br> Gründen, dass das Auffüllen von Lücken unnötiger Aufwand ist.</p> <p>So long,<br> Frank</p> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 18:26:03 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999151#m999151 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999151#m999151 <p>hi,</p> <blockquote> <blockquote> <p>[...] Zielst du auf das Wiederauffüllen von<br> Lücken, die durch Löschen entstanden sind? Das macht keinen Sinn.</p> </blockquote> <p>Warum macht das keinen Sinn? Wenn ich einen begrenzten Wertebereich fuer meinen Primary Key habe (bspw. int), dann komme ich doch automatisch irgendwann ans Ende - auch wenn meine DB dann nur einen einzigen Eintrag hat. Oder?</p> </blockquote> <p>Dann sorgst du halt rechtzeitig dafür, dass dein Wertebereich nicht so schnell erschöpft ist.</p> <blockquote> <p>Und falls ich das nicht vollkommen falsch sehe: wie bekomme ich die Luecken dann gestopft? Macht das mein DBMS automatisch, oder bin ich mit autoincrement dann tatsaechlich am Ende?</p> </blockquote> <p>Du willst sie nicht stopfen, weil das absolut überflüssig ist, und dich schlimmstenfalls zu Dateninkonsistenzen führt. (Denke nur an einen gelöschten Datensatz mit der ID XY, zu dem in einer anderen Tabelle vielleicht noch eine Referenz besteht, weil das Löschen in dieser Fehlschlug oder vergessen wurde. Jetzt legst du einen neuen Datensatz mit der ID XY an - und plötzlich verweist aus der anderen Tabelle ein Datensatz auf diesen, obwohl er absolut nichts mit ihm zu tun hat. Kann doch nicht gewollt sein.)</p> <p>gruß,<br> wahsaga</p> <div class="signature">-- <br> /voodoo.css:<br> #GeorgeWBush { position:absolute; bottom:-6ft; } </div> PrimaryKeys - welchen nehme ich? Tue, 25 Jul 06 18:19:36 Z https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999154#m999154 https://forum.selfhtml.org/self/2006/jul/25/primarykeys-welchen-nehme-ich/999154#m999154 <p>Hab ich ursprünglich behauptet, dass es mir darum gänge?</p> <p>FF</p>