Am 27.09.2012 08:42, schrieb Martin Eckel:> Die Tabellen im phpmyadmin werden grundsätzlich in der Reihenfolge
> angezeigt, wie auch die autoincrement-ID ist, also chronologisch.
>
> Manche IDs sind aber vertauscht. Wie kommt das? Wieso steht ID 589 vor
> ID 588?
das kann beispielsweise dann passieren, wenn ein Datensatz mit einer ID kleiner 588 gelöscht wurde. Kommt dann ein neuer Datensatz in die Tabelle, wird er an die Stelle des gelöschten Datensatzes geschrieben und steht dann vor 588.
Martin Eckel <martin.ec...@t-online.de> wrote:
> Am 27.09.2012 11:19, schrieb John Kirste:
>> das kann beispielsweise dann passieren, wenn ein Datensatz mit einer ID
>> kleiner 588 gelöscht wurde.
> Hm, in der Tabelle wurde noch nie ein Datensatz gelöscht. Ist auch nicht > wichtig, nur seltsam.
SQL spezifiziert nicht, in welcher Reihenfolge die Daten
ausgegeben werden. Möchtest du eine bestimmte Sortierung
erreichen, gibt es ORDER BY.
-- Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
Martin Eckel wrote:
> mal eine Frage rein aus Interesse:
> Die Tabellen im phpmyadmin werden grundsätzlich in der Reihenfolge > angezeigt, wie auch die autoincrement-ID ist, also chronologisch.
Nein. Sie werden in der Reihenfolge angezeigt, wie sie der Server
liefert. Das ist aber per Definition nicht sortiert.
> das kann beispielsweise dann passieren, wenn ein Datensatz mit einer > ID kleiner 588 gelöscht wurde. Kommt dann ein neuer Datensatz in die > Tabelle, wird er an die Stelle des gelöschten Datensatzes geschrieben > und steht dann vor 588.
Falsch!
Wenn eine ID gelöscht wird, bleibt sie für alle Zeiten gelöscht. Es sei
denn, jemand fügt _manuell_ einen Datensatz mit dieser ID ein.
Martin Eckel <martin.ec...@t-online.de> wrote:
> Am 27.09.2012 13:17, schrieb Bastian Blank:
>> Nein. Sie werden in der Reihenfolge angezeigt, wie sie der Server
>> liefert. Das ist aber per Definition nicht sortiert.
> Ok, im Allgemeinen werden sie aber chronologisch angezeigt, daß ist das, > was ich meine.
Dann geh mal schnell ein Audit machen, wer die Tabelle manuell
verändert hat ;-)
-- Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of Directors
Volunteer Regional Contact, Germany - PostgreSQL Project
On Thu, 27 Sep 2012 18:50:51 Claus Reibenstein wrote:
> > [...], wenn ein Datensatz mit einer ID kleiner 588 gelöscht wurde.
> > Kommt dann ein neuer Datensatz in die Tabelle, wird er an die Stelle
> > des gelöschten Datensatzes geschrieben und steht dann vor 588.
> Falsch!
> Wenn eine ID gelöscht wird, bleibt sie für alle Zeiten gelöscht. Es sei
> denn, jemand fügt _manuell_ einen Datensatz mit dieser ID ein.
Du hast nicht genau gelesen. Es ging nicht um die _Nummer_ des neuen
Datensatzes, sondern um seine _Position_.
Servus,
Stefan
-- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
> On Thu, 27 Sep 2012 18:50:51 Claus Reibenstein wrote:
>>> [...], wenn ein Datensatz mit einer ID kleiner 588 gelöscht wurde.
>>> Kommt dann ein neuer Datensatz in die Tabelle, wird er an die Stelle
>>> des gelöschten Datensatzes geschrieben und steht dann vor 588.
Schrieb wer? Bitte die Namen der Zitierten stehen lassen!
>> Falsch!
Was soll daran falsch sein?
>> Wenn eine ID gelöscht wird, bleibt sie für alle Zeiten gelöscht. Es sei
>> denn, jemand fügt _manuell_ einen Datensatz mit dieser ID ein.
> Du hast nicht genau gelesen. Es ging nicht um die _Nummer_ des neuen
> Datensatzes, sondern um seine _Position_.
Welche "Nummer"? Datensätze haben keine "Nummer", und von einer Position
war bislang nirgends die Rede.
Es ging vielmehr um eine "autoincrement-ID" (steht so im OP, hatte ich
auch zitiert), also um eine normale Tabellenspalte, deren Werte
automatisch vergeben werden, und um die unrichtige Behauptung, dass beim
Einfügen eines Datensatzes diese Spalte den Wert eines zuvor gelöschten
Datensatzes erhalten soll.
phpMyAdmin zeigt mir meine Tabellen übrigens _immer_ nach ID sortiert
an, auch die, in denen ich des Öfteren Datensätze lösche und neue
einfüge. Könnte daran liegen, dass ich diese Spalte als Primary Key
festgelegt habe. Muss aber nicht.
>>>> Kommt dann ein neuer Datensatz in die Tabelle, wird er an die
>>>> Stelle des gelöschten Datensatzes geschrieben und steht dann vor
>>>> 588.
> Schrieb wer? Bitte die Namen der Zitierten stehen lassen!
Auch "SeaMonkey" sollte einen Thread anzeigen können.
Im speziellen Fall:
Bezugsnachrichten zu "Tabelle nicht sortiert nach Autoincr"
285 27.09 Martin Eckel Tabelle nicht sortiert n
333 27.09 ├──Bastian Blank
263 27.09 │ └──Martin Eckel
583 27.09 │ └──Andreas Scherbaum
544 27.09 └──John Kirste
251 27.09 ├──Martin Eckel
632 27.09 │ └──Andreas Scherbaum
472 27.09 └──Claus Reibenstein
738 27.09 └──Stefan Froehlich
1356 28.09 └──Claus Reibenstein
On Fri, 28 Sep 2012 17:38:41 Claus Reibenstein wrote:
> >>> [...], wenn ein Datensatz mit einer ID kleiner 588 gelöscht wurde.
> >>> Kommt dann ein neuer Datensatz in die Tabelle, wird er an die Stelle
> >>> des gelöschten Datensatzes geschrieben und steht dann vor 588.
> Schrieb wer? Bitte die Namen der Zitierten stehen lassen!
Eine Einleitungszeile reicht (mir), wer den Rest, auf den sich der Text
bezieht, geschrieben hat, ist ja bei Bedarf im Threading nachlesbar.
> >> Falsch!
> Was soll daran falsch sein?
Selbstverstaendlich gar nichts. Das war aber auch _Dein_ Text, den ich
ja genau deshalb hinterfragt hatte. Wenn also Du nicht weiss, was daran
falsch ist, wer dann sonst?
> > Du hast nicht genau gelesen. Es ging nicht um die _Nummer_ des neuen
> > Datensatzes, sondern um seine _Position_.
> [...] von einer Position war bislang nirgends die Rede.
Es ist empfehlenswert, den Thread, in dem man schreibt, vorher auch zu
lesen.
> Es ging [...] um die unrichtige Behauptung, dass beim Einfügen eines
> Datensatzes diese Spalte den Wert eines zuvor gelöschten Datensatzes
> erhalten soll.
Ich las unmittelbar vor Deinem Posting:
| > Wieso steht ID 589 vor ID 588?
| das kann beispielsweise dann passieren, wenn ein Datensatz mit einer
| ID kleiner 588 gelöscht wurde. Kommt dann ein neuer Datensatz in die
| Tabelle, wird er an die Stelle des gelöschten Datensatzes geschrieben
| und steht dann vor 588.
Wo entnimmst Du diesem Text, dass der neue Datensatz den _Wert_ des
zuvor geloeschten Satzes bekaeme? Es geht hier ausschliesslich um die
Position.
> phpMyAdmin zeigt mir meine Tabellen übrigens _immer_ nach ID sortiert
> an, [...]
Was ja erst einmal auch naheliegend ist. Beim OP ist es nun aber in
Einzelfaellen eben nicht so, weshalb er neugierig wurde und hier
nachgefragt hat. Welch Drama.
Servus,
Stefan
-- http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Mehr als man hofft. Stefan - armselig und begehrlich.
(Sloganizer)
> On Fri, 28 Sep 2012 17:38:41 Claus Reibenstein wrote:
>> Schrieb wer? Bitte die Namen der Zitierten stehen lassen!
> Eine Einleitungszeile reicht (mir), wer den Rest, auf den sich der Text
> bezieht, geschrieben hat, ist ja bei Bedarf im Threading nachlesbar.
Warum willst Du es den Lesern Deines Postings schwerer machen als
unbedingt erforderlich?
>> [...] von einer Position war bislang nirgends die Rede.
> Es ist empfehlenswert, den Thread, in dem man schreibt, vorher auch zu
> lesen.
Da bin ich absolut bei Dir.
> Ich las unmittelbar vor Deinem Posting:
> | > Wieso steht ID 589 vor ID 588?
> | das kann beispielsweise dann passieren, wenn ein Datensatz mit einer
> | ID kleiner 588 gelöscht wurde. Kommt dann ein neuer Datensatz in die
> | Tabelle, wird er an die Stelle des gelöschten Datensatzes geschrieben
> | und steht dann vor 588.
> Wo entnimmst Du diesem Text, dass der neue Datensatz den _Wert_ des
> zuvor geloeschten Satzes bekaeme? Es geht hier ausschliesslich um die
> Position.
Du hast Recht. Hatte ich anders aufgefasst.
>> phpMyAdmin zeigt mir meine Tabellen übrigens _immer_ nach ID sortiert
>> an, [...]
> Was ja erst einmal auch naheliegend ist. Beim OP ist es nun aber in
> Einzelfaellen eben nicht so, weshalb er neugierig wurde und hier
> nachgefragt hat.
Mich würden mal die genauen Randbedingungen interessieren, bei denen das
passiert ist.
> Stefan Froehlich schrieb:
>> Was ja erst einmal auch naheliegend ist. Beim OP ist es nun aber in
>> Einzelfaellen eben nicht so, weshalb er neugierig wurde und hier
>> nachgefragt hat.
> Mich würden mal die genauen Randbedingungen interessieren, bei denen das
> passiert ist.
Randbedingungen gibt es dazu nicht. Ist eine Tabelle, es werden Daten hinzugefügt, es werden niemals nicht ganze Datensätze raus gelöscht (natürlich werden mal die Daten modifiziert).
Und manchmal sind zwei IDs in der Reihenfolge vertauscht. Die Spalte steht auf autoincrement und primary key.
Ist auch völlig unwichtig, hat mich nur neugierig gemacht ;-)
