Cheatah: Neuste 10 Datensätze ausgeben

Beitrag lesen

Hi,

auch eine auto_increment-Spalte darf nicht für eine Sortierung missbraucht werden. Der Wert dient *nur und ausschließlich* der Eindeutigkeit.

Wer sagt das? Das legt der Datenbank-Applikationsentwickler soch selber fest!

nein, tut er nicht. Welche Werte eine auto_increment-Spalte erzeugt, hängt vom DBMS ab - es ist (theoretisch, praktikabel wäre das nicht) möglich, dass die nächste MySQL-Version beispielsweise "Lücken füllt", oder dass beim Erreichen des Maximalwertes wieder von vorne an gezählt wird (derzeit wird einfach der letzte Wert ewig wiederholt).

Ich verstehe hier Deinen ewigen Einwand nicht.

Und jetzt? Wenn die Werte nach Deiner Beobachtung (oder gerne auch de facto) derzeit stets ansteigt, dann heißt das noch lange nicht, dass dies verlässlich ist.

Gute Datenbankdesigner geben allerdings jeder Tabelle einen Primärschlüssel,
Was?
Oh, entschuldige, ich wußte nicht, dass Du nicht dazugehörst.

Ich behaupte, ich habe schon ein wenig Ahnung von DB-Layouts. Einige meiner Arbeiten sind jedenfalls mit einigen Millionen Datensätzen in mehreren Dutzend Tabellen und recht intensiven Änderungsraten am Laufen. Es sind Tabellen dabei, die von nirgendwo referenziert sind und in denen teilweise _keine_ Spaltenkombination als PK hinreicht. Es wäre nötig gewesen, eine künstliche PK-Spalte zu erzeugen, welche ausschließlich zu ihrer eigenen Befüllung genutzt worden wäre. Hälst Du das für sinnvoll?

Der Schlüssel sollte z.B. immer ID_<Tablename> heißen
Nomenklaturen sind lokal. Bei mir [...]
Wie Du Deinen Schlüssel nennst ist mir eigentlich egal. Ich _empfehle_ [...]

Ja, da will ich Dich auch nicht dran hindern. Worauf ich hinaus will ist, dass das von Dir angesehene Optimum noch lange nicht das Nonplusultra für jeden anderen sein muss.

ID_<Tablename>

Wenn der Tabellenname von Relevanz ist - bei Joins etwa - dann deshalb, weil mehrere Tabellen im Spiel sind. In dieser Situation ist es empfehlenswert, _alle_ Spaltenzugriffe mit dem Tabellennamen (oder einem Alias) zu kennzeichnen, damit man nicht das DB-Layout auswendig kennen muss, un zu verstehen was da vor sich geht (Stichwort Wartbarkeit). Es heißt dann also ohnehin "<Tablename>.ID". Wenn man sich nur innerhalb einer Tabelle bewegt, ist eh klar, dass es sich um dessen ID handelt, das bedarf keiner Erwähnung.

Bei einem Join muss man dann bezüglich der IDs nicht erst mit Namenskonflikten rumhampeln.

Wie machst Du das bei anderen Spalten, die in unterschiedlichen Tabellen identisch heißen?

Und Autoincrements können nicht aus mehreren Spalten bestehen.

Primary Keys jedoch schon, und es ist keinesfalls zwingend nötig, dass eine der Spalten ein auto_increment ist.

Lies bitte in Zukunft genauer.

Da muss ich jetzt nichts zu sagen, oder?

Wenn man einen Kombinationsschlüssel benötigt, besteht dieser ja i.d.R. aus echten Datenwerten (z.B. Autonummer, Sozialversicherungsnummer, etc...)

Nö, in den meisten bei mir vorgekommenen Fällen waren es Referenzen auf andere ID-Spalten. Insbesondere bei Kreuztabellen.

Dies gilt wohlgemerkt nur für MySQL. Die meisten anderen DBMSse kennen ein solches Konzept nämlich nicht.
Ich kenne kein DBMS, dass keine Autoincrement-Keys kennt.

Interessehalber: Welche kennst Du?

Nenn mir bitte fünf, wenn Du meinst, dass das die Regel wäre.

Siehe Christians Antwort.

Es gibt Datenbanken, die dann auch automatisch nach diesem Schlüssel sortieren, wenn man nichts Anderes angibt.
Echt? Welche zum Beispiel? Ist das von bestimmten Bedingungen bei der Abfrage abhängig?
z.B. der MSSQL-Server, btrieve-scalable-sql, Sybase SQL, Informix SQL, ...

Danke. Worauf ich mit der letzten Frage hinauswollte: Bei welchem Ausführungsplan wird die Sortierung durchgeführt? Eine Sortierung kostet Zeit; und gewöhnlich sind DBMSse (auch) auf Geschwindigkeit getrimmt. Oft reicht es sogar, wenn zunächst die ersten paar gefundenen Datensätze zum Client zurückgeliefert werden, noch ehe das gesamte Resultset feststeht. Wenn erst sortiert werden muss, ist das nicht mehr möglich.

Cheatah

--
X-Will-Answer-Email: No