![]() |
Mit Autoincrement hat man eben ein "Unheil" im Lauf, deshalb darf es eben nicht so laufen, wie es für Dich angenehm wäre. ;) Ein manuell versorgtes Feld ist da das einzige Mittel zum Zweck.
|
sowas hab ich eh schon für diesen zweck geschrieben, nur habe ich mich diesmal gefragt, ob ich mir das nicht einfacher hätte machen können. offensichtlich nicht.
|
Zitat:
http://www.mysql.de/documentation/my...ml#Table_types HTH |
frage wo is das problem die id kann einem doch egal sein wenn ich das ganze ausgeb weiss ich doch ob es die X zeile is egal welche id ich hab
|
Zitat:
|
Zitat:
bild ich mir halt ein ... :) |
Zitat:
|
Ohne eindeutiger Identifikationsmöglichkeit von Datensätzen ist das Ausgeben aller Daten zu einem Foreign-Key kein Problem.
Spätestens beim Löschen - noch viel mehr beim Ändern - von Daten stößt du auf ein wesentliches Problem - der eindeutigen Identifikation der zu ändernden/löschenden Daten. ~ |
Zitat:
mir persönlich is es auch egal, ob bei den id's eine lücke entstanden ist, weil ein (oder mehrere) datensätze gelöscht wurden ... bei immensen datenmengen is es doch egal, ob auf den datensatz mit der id 68456315656431, der datensatz mit der id 68456315656438 folgt ... hauptsache, es sind die richtigen daten vorhanden! weiters kann man so (auch ohne zusätzliches journaling) feststellen, ob gelöscht wurde oder nicht ... |
Nein, nicht durchgängige Nummern - infolge einiger wieder gelöschter Datensätze - zu verwenden ist schlichtweg Pflicht. Besser noch als IDs sind Timestamps als ID in genügend großer Auflösung, z.B. einer Millisekunde. Damit habe ich den Zeitpunkt der Anlage (Creation Date) und eine eindeutige Nummer. Falls eine fortlaufende Nummer vonnöten ist, kann man diese zusätzlich oder statt dessen verwenden.
|
Alle Zeitangaben in WEZ +2. Es ist jetzt 18:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag