Frage zu Lücken durch auto_increment

[Herbert]

Hi,

hat das eigendlich irgendwelche Nachteile, daß durch löschen von Datenbankeinträgen und trotzdem fortlaufenden Hochzählen der "Eintrags-ID" durch auto_increment teilweise gravierende Lücken innerhalb der IDs entstehen oder ist das völlig Wurscht?

Grüße

Herbert

[Ilja]

yo,

hat das eigendlich irgendwelche Nachteile, daß durch löschen von Datenbankeinträgen und trotzdem fortlaufenden Hochzählen der "Eintrags-ID" durch auto_increment teilweise gravierende Lücken innerhalb der IDs entstehen oder ist das völlig Wurscht?

so pauschal gesagt ist es wurscht, dass kind (datensatz) muss halt einen eindeutigen namen bekommen und daseinfachste ist halt die zahlen hochzuzählen. und lücken haben dabei keine auswirkungen, es ist quasi nur eine namensgebung. es gibt situationen, wo der speicherort des datensatzes anhand seiner id ausgerechnet wird. das ist aber hier nicht der fall.

Ilja

[Mastershrimp]

Heyho!

Das kommt ganz auf die Anwendung an. Wenn du mit einem Script bild1, bild2, bild3 anhand des auto_increments aufrufst, entstehen dadurch fehler.
Grundsätzlich allerdings ist das nicht allzu schlimm.
Wie gesagt, kommt auf die Anwendung an.

Chapeau!

Mastershrimp

[Cheatah]

Hi,

hat das eigendlich irgendwelche Nachteile, daß durch löschen von Datenbankeinträgen und trotzdem fortlaufenden Hochzählen der "Eintrags-ID" durch auto_increment teilweise gravierende Lücken innerhalb der IDs entstehen oder ist das völlig Wurscht?

es ist völlig wurscht, da dem eigentlichen Wert einer ID-Spalte exakt gar kein Wert beigemessen werden darf. Sie dient nur und ausschließlich der eindeutigen Identifizierung eines Datensatzes, daher dürfen völlig beliebige Werte vorliegen. Dass diese zumeist fortlaufend sind liegt lediglich daran, dass dies am einfachsten zu implementieren ist.

Cheatah

[Ole]

hi Herbert

wenn du nicht zufällig eine anwendung hast die auf durchgängige IDs besteht, was normalerweise nciht der fall sein sollte, ist das ziemlich wurscht.

da die ID meistens auch als Primärschlüssel dient ist es sogar durchaus wünschenswert das die IDs gelöschter datensätze nicht mehr vergeben werden, damit keine verwechselungen oder ähnliches stattfinden.

so long
ole
(8-)>

[Lude]

Hi,

wenn du nicht zufällig eine anwendung hast die auf durchgängige IDs besteht, was normalerweise nciht der fall sein sollte, ist das ziemlich wurscht.

ich kenne Anwendungen, die auf lueckenlos fortlaufende ganzzahlige IDs bestehen.   ;-)

Gruss,
Lude

[Daniela Koller]

Hi Herbert

Zusätzlich zu dem was die anderen gesagt haben noch etwas: Es kann Probleme geben, wenn du sehr viele Datensätze löscht. Das Problem ist dann, dass der Autoincrement die höchste Zahl erreicht. Du hast dann quasi wenige Einträge und trotzdem kein Platz mehr für neue. Das ist dann aber eher ein Problem mit falsch gewählten Grössen und den genauen Einstellungen des Autoincrements.

Eine Reihenfolge solltest du niemals mit diesem Autoincrement-Feld erzeugen (die Art wie MySQL es verwendet). Es ist gefährlich und falsch. Wenn du eine Reihenfolge willst, erzeuge die anders, zb mit einer zusätzlichen Spalte.

Gruss Daniela

[Herbert]

Hi,

erstmal danke an alle für die Antworten. Klar, von der durchs auto_inc. erzeugten Zahl mache ich natürlich nichts, außer dem Datensatz selber abhängig.
Ich glaube, nichtmal meine Scripte selber greifen auf diese ID zurück, das geschieht alles anhand anderer Spaltenwerte.

@Daniela: Es gibt eine höchste Zahl, die hierbei errreicht werden kann?
Wie hoch ist die denn?

Grüße

Herbert

[Daniela Koller]

Hi Herbert

@Daniela: Es gibt eine höchste Zahl, die hierbei errreicht werden kann?
Wie hoch ist die denn?

Kommt auf deinen Datentyp drauf an. Bei tinyint wären es zb. 127, bei den anderen entsprechend einiges mehr.

Gruss Daniela

[Herbert]

Kommt auf deinen Datentyp drauf an. Bei tinyint wären es zb. 127, bei den anderen entsprechend einiges mehr.

Gruss Daniela

Hi Daniela,

nagut, bis ca. 2,15 Mrd. hab ich ja noch viel Zeit zum löschen :-))

Danke

Herbert

[Bio]

Sup!

nagut, bis ca. 2,15 Mrd. hab ich ja noch viel Zeit zum löschen :-))

Nur nutzt das ungefaehr gar nichts, denn die IDs duerfen nicht wiederverwendet werden.

Gruesse,

Bio

[Lude]

Hi,

'--
Für sein Verhalten sollte man sich nur entschuldigen, wenn man vorhat, es zu ändern.'

eine Entschuldigung dient dem Zweck mindestens einer Person zu signalisieren, dass vergangenes eigenes Verhalten dieser Person(engruppe) geschadet hat. Es ist soz. ein Ritual, dass klarstellt, dass man selbst erkannt hat, dass man sich gegenueber der anderen Person unguenstig verhalten hat und dass man bereit ist, das bei Gelegenheit zu kompensieren.

Beispiele:
* Ein Fussballspieler verletzt beim Kopfball im Elfmeterraum seinen eigenen Teamkollegen. Er entschuldigt sich, hat aber im Rahmen der Folgenabwaegung absolut richtig gehandelt.
* Gerhard Schroeder entschuldigt sich beim Hamburger SPD-Kandidaten fuer den fehlenden Rueckenwind aus Berlin. - Nichtsdestotrotz hat Hr.Schroeder im Bundesinteresse richtig gehandelt.
* Harry Hirsch rempelt eine aeltere Dame an, weil er Terminprobleme hat. Es geht um ein moegliches Engagement bei der Waldshuter Hirtenzeitung, das ihm sehr attraktiv erscheint. Er entschuldigt sich "en passant".

Ich denke hinreichend klargestellt zu haben, dass die oben zitierte Aussage falsch ist. - Aber vielleicht ist die Aussage von einer hoeheren Abstraktionsebene aus betrachtet vielleicht doch war und gut?

Gruss,
Luddie

[Bio]

Sup!

Für sein Verhalten sollte man sich nur entschuldigen, wenn man vorhat, es zu ändern.'

eine Entschuldigung dient dem Zweck mindestens einer Person zu signalisieren, dass vergangenes eigenes Verhalten dieser Person(engruppe) geschadet hat. Es ist soz. ein Ritual, dass klarstellt, dass man selbst erkannt hat, dass man sich gegenueber der anderen Person unguenstig verhalten hat und dass man bereit ist, das bei Gelegenheit zu kompensieren.

Wie immer, wenn Du mit mir diskutieren willst, liegst Du voellig falsch :-)

"Ent-schuld-igen" bedeutet ja, seine Schuld gegenueber jemand anderem abtragen zu wollen, indem man ihm eine Absolution abringt.
Das Anerkenntnis von Schuld ist also implizit im Verb "Entschuldigen" enthalten.
Natuerlich wird oft von "Entschuldigung" gesprochen, wenn jemand eigentlich nur "Es tut mir leid" gesagt hat - "Es tut mir leid" bedeutet aber nicht wirklich, dass man sich entschuldigt, denn es koennen einem auch Dinge leid tun, an denen man ueberhaupt nicht beteiligt ist; es ist ein Ausdruck von Mitgefuehl mit jemandem, dem ein Leid widerfahren ist, und keine "Enschuldigung" mit implizitem Schuldeingestaendnis.
In Deinem Beispiel koennte also der Fussballspieler, der einen anderen verletzt hat, "Es tut mir leid" sagen und damit sein Mitgefuehl ausdruecken, vielleicht auch seinen Wunsch, es waere nicht dazu gekommen - entschuldigen wuerde er sich damit aber im eigentlichen Sinne nicht.

Deshalb ist mein Spruechlein natuerlich absolut zutreffend und zeugt von meinem enorm fantastischen Gespuer fuer exakte Sprachverwendung.

Gruesse,

Bio

[Sven Rautenberg]

Moin!

@Daniela: Es gibt eine höchste Zahl, die hierbei errreicht werden kann?
Wie hoch ist die denn?

Kommt auf deinen Datentyp drauf an. Bei tinyint wären es zb. 127, bei den anderen entsprechend einiges mehr.

unsigned tinyint hat immerhin 255 als maximalen Wert. :)

Es ist sowieso eine gute Idee, einen unsigned Zahlentyp zu nehmen, weil einem die negativen IDs nichts bringen. Das verdoppelt den Zahlenbereich dann gleich nochmal.

Bei BIGINT gibt es aber möglicherweise Probleme mit extrem großen Werten, weil die Zahlentypen der abfragenden Sprache unter Umständen zu klein dafür sind. Man sollte nicht ohne Not BIGINT für die IDs verwenden, auch wenn die Speichergröße einem vollkommen ausreichend erscheint und man die paar Bytes nicht sparen müßte.

- Sven Rautenberg

[AndreD]

Hallo Sven,

Man sollte nicht ohne Not BIGINT für die IDs verwenden, auch wenn die Speichergröße einem vollkommen ausreichend erscheint und man die paar Bytes nicht sparen müßte.

Kann sein das ich gerade mit meinem Deutsch auf Kriegsfuss stehe :-) Willst Du damit sagen das man für die IDs in der Regel aus Deinen angeführten Gründen lieber kein BIGINT nehmen sollte? Stattdessen dann doch lieber ein unsigned INT?

Grüsse AndreD

[Sven Rautenberg]

Moin!

Man sollte nicht ohne Not BIGINT für die IDs verwenden, auch wenn die Speichergröße einem vollkommen ausreichend erscheint und man die paar Bytes nicht sparen müßte.

Kann sein das ich gerade mit meinem Deutsch auf Kriegsfuss stehe :-) Willst Du damit sagen das man für die IDs in der Regel aus Deinen angeführten Gründen lieber kein BIGINT nehmen sollte? Stattdessen dann doch lieber ein unsigned INT?

Das will ich damit sagen. Solange man nicht erwartet, dass man BIGINT tatsächlich benötigt, weil man wirklich soviele Datensätze ablegen will - oder zumindest soviele Datensätze _durchnummeriert_, sollte man darauf verzichten. Oder man ist sich der Konsequenzen mit BIGINT-Zahlen bewußt und hat dafür einen passenden Variablentyp in seiner Programmiersprache.

Siehe beispielsweise die Warnung bei http://de2.php.net/manual/en/function.mysql-insert-id.php.

So wie ich das sehe, sollte man BIGINT-Zahlen grundsätzlich als String behandeln und im Machtbereich von MySQL belassen, keinesfalls jedoch eine Wandlung in eine PHP-Zahl versuchen.

Wenn man das einhalten kann, ist BIGINT natürlich kein Problem. Andernfalls schon.

- Sven Rautenberg

[AndreD]

Hallo,

Das will ich damit sagen. Solange man nicht erwartet, dass man BIGINT tatsächlich benötigt, weil man wirklich soviele Datensätze ablegen will - oder zumindest soviele Datensätze _durchnummeriert_, sollte man darauf verzichten. Oder man ist sich der Konsequenzen mit BIGINT-Zahlen bewußt und hat dafür einen passenden Variablentyp in seiner Programmiersprache.

Ok, in der Tat kann ich wohl bisher bei eigentlich keiner Anwendung (ausser vielleicht einer) irgendwann mit einer ID in den Sphären von BIGINT rechnen. Deshalb werde ich Deinen Rat in kommende Projekte so mit einfliessen lassen.

Siehe beispielsweise die Warnung bei http://de2.php.net/manual/en/function.mysql-insert-id.php.

Ok, so wie die das schreiben heisst das wohl das die Zahl, welche ich mit mysql_insert_id() zurückbekomme grundsätzlich falsch sein müsste? Das konnte ich aber bisher nicht feststellen. Kann es sein das der Wert erst falsch wird wenn die ID den tatsächlichen Fassungswert der Programmiersprache (hier: PHP) überschreitet. Also wenn die Grenze von INT zu BIGINT überschritten wird? Oder liegt es vielleicht daran das ich bisher meine BIGINT-Felder mit Anzeigebreite (14) limitiert habe?

So wie ich das sehe, sollte man BIGINT-Zahlen grundsätzlich als String behandeln und im Machtbereich von MySQL belassen, keinesfalls jedoch eine Wandlung in eine PHP-Zahl versuchen.

Soll heissen: Solange ich ich nicht versuche die BIGINT in PHP als Zahl zu nutzen (etwa für Rechenoperationen) oder ein typecasting hat dies kein Einfluss?

http://de2.php.net/manual/de/language.types.integer.php:

Die Größe eines Integer-Wertes ist plattformabhängig, ein Maximalwert von ungefähr zwei Milliarden ist jedoch üblich (vorzeichenbehafteter 32-Bit-Wert). PHP unterstützt keine vorzeichenlosen Integer-Werte.
<<

Das würde IMHO dem Typ INT ohne unsigned in MySQL entsprechen, oder?

Grüsse AndreD

[Christian Kruse]

Hallo AndreD,

Siehe beispielsweise die Warnung bei http://de2.php.net/manual/en/function.mysql-insert-id.php.

Ok, so wie die das schreiben heisst das wohl das die Zahl, welche
ich mit mysql_insert_id() zurückbekomme grundsätzlich falsch sein
müsste?

Nein. Eine Zahl wird intern in Form von Bitmasken im Binär-System
dargestellt. PHP benutzt hier long, was auf x86-Systemen mit 32 Bit
dargestellt wird. Mit 32 Bit lassen sich Zahlen von -2147483647 bis
[phone] darstellen (2^32 / 2, ein Bit ist für das Vorzeichen
reserviert (deshalb dividiert durch zwei) und man fängt bei 0 an zu
zählen, deshalb 2147483647 und nicht 2147483648). Eine größere Zahl
kann in PHP als Zahl nicht dargestellt werden. Auf anderen Systemen
hat long eine andere Größe. Tatsächlich kannst du nicht wissen, wie
gross long bei PHP ist. Auf gängigen Systemen ist es allerdings zum
Glück 32 Bit gross.

So wie ich das sehe, sollte man BIGINT-Zahlen grundsätzlich als
String behandeln und im Machtbereich von MySQL belassen,
keinesfalls jedoch eine Wandlung in eine PHP-Zahl versuchen.

Soll heissen: Solange ich ich nicht versuche die BIGINT in PHP als
Zahl zu nutzen (etwa für Rechenoperationen) oder ein typecasting
hat dies kein Einfluss?

Nein, PHP ist komplizierter. Du musst darauf achten, was für
Datentypen die Funktionen erwarten. Erwarten sie einen numerischen
Datentyp, kannst du die ID dort nicht verwenden. Erwarten sie einen
String, ist das Ok.

Grüße,
 CK

[AndreD]

Hallo Christian,

[...] deshalb 2147483647 und nicht 2147483648). Eine größere Zahl
kann in PHP als Zahl nicht dargestellt werden. Auf anderen Systemen
hat long eine andere Größe. Tatsächlich kannst du nicht wissen, wie
gross long bei PHP ist. Auf gängigen Systemen ist es allerdings zum
Glück 32 Bit gross.

Ja, das hab ich ja auch so im Manual gelesen.

Nein, PHP ist komplizierter. Du musst darauf achten, was für
Datentypen die Funktionen erwarten. Erwarten sie einen numerischen
Datentyp, kannst du die ID dort nicht verwenden. Erwarten sie einen
String, ist das Ok.

Ok, das hab ich wohl soweit jetzt verstanden und werde versuchen es mir auch für den Fall der Fälle zu merken. In Zukunft werde ich wohl die ID-Felder wieder als unsigned INT anlegen, > 5 Mrd. Einträge sollten dann auch erstmal ausreichen :-)

Danke & Gruß
AndreD

[Andreas Korthaus]

Hi Daniela!

Kommt auf deinen Datentyp drauf an. Bei tinyint wären es zb. 127, bei den anderen entsprechend einiges mehr.

Bei MySQL gibt es ja noch das Attribut UNSIGNED bei den Interger-Datentypen, ist das eigentlich SQL-Standard und funktioniert in anderen RDBMS?

Grüße
Andreas

[AndreD]

Hallo Herbert

Wie hoch ist die denn?

Bigint als unsigned: 18446744073709551615

Mehr Infos zu den Spaltentypen und deren Werten: http://www.mysql.com/doc/de/Column_types.html

Grüsse + Mahlzeit
AndreD

[Andreas Korthaus]

Hallo!

hat das eigendlich irgendwelche Nachteile, daß durch löschen von Datenbankeinträgen und trotzdem fortlaufenden Hochzählen der "Eintrags-ID" durch auto_increment teilweise gravierende Lücken innerhalb der IDs entstehen oder ist das völlig Wurscht?

Auch wenn Du vielleicht kein PHP verwendest, trotzdem lesenswert:

http://www.dclp-faq.de/q/q-sql-ids.html
http://www.dclp-faq.de/q/q-mysql-inkrement.html

Grüße
Andreas