Zwischendrin Truncate table ?

[WernerK]

Hallo,

eine Anwendung schreibt in MySQL Tabelle mehrmals am Tag Daten. Es wird kein Update der einzelnen Datensätze gemacht, sondern ein Delete und dann ein Insert.
Die Tabelle hat eine ID als Primärschlüssel mit "Auto_increment". (int(10)
Jetzt würde mit der Zeit die Id anwachsen und anwachsen.

Könnte man zwischendurch einen Truncate table machen, anstatt Delete ?
Ist so etwas "erlaubt" bzw. eine gute Praxis oder sollte man dies eher vermeiden?

Oder sollte man auf die Spalte ID mit Auto_increment ganz verzichten. Die Anwendung bräuchte sie nicht unbedingt. Allerding hätte man dann auch keinen Primärschlüssel mehr.

Gruss
Werner

[1UnitedPower]

Meine Herren!

Könnte man zwischendurch einen Truncate table machen, anstatt Delete ?
Ist so etwas "erlaubt" bzw. eine gute Praxis oder sollte man dies eher vermeiden?

Das sollte man vermeiden. Eine ID hat einzig und allein den Auftrag Datensatz zu identifizieren, man stellt keine Schönheitsansprüche an sie. Auch ein Überlauf ist recht unwahrscheinlich, der Wertebereich für ein unsigned INT reicht bis 4294967295 für ein unsigned BIGINT sogar bis 18446744073709551615. Das sollte dir also nicht in die Quere kommen. Neben der AUTO_INCREMENT-ID kann man auch mit UUID() ein Identifizierungsmerkmal mit String-Typ erzeugen. Kollisionen sind dabei zwar theretisch möglich, aber angesichts des verwendeten 128-Bit Wertebereichs (3.4028237e+38 mögliche Werte), spielt dieses theoretische Szenario keine große Rolle.

[WernerK]

Hallo,

das mit der UUID bzw. beim SQL Server die GUID habe ich auch schon gelesen. Aber hier gehen die Meinungen ja sehr auseinander ob sinnvoll oder nicht. Man bräuchte ja mindestens einen Char() Spalte mit 32 Länge. Und dann wäre es auch nur sinnvoll wenn diese ID inkrementell fortlaufend ist oder?

Aber nochmals zurück zum Thema Auto_increment bzw. BIGINT.
Ich kenne z.b. eine Anwendung aus einem Rechenzentrum die jede 2-3 Sekunden mehrere Inserts macht. Ich glaube ich hatte da mal was von 150000 Zeilen am Tag gesehen.
Irgend wann wäre doch auch der BIGINT nicht mehr ausreichend. (OK, vielleicht bin ich da vorher in Rente :-) )
Ich hatte das schon mal in einem anderen Thread gefragt.
Wie machen das die großen der Branche, wie Amazon, ebay oder sonstige? Wenn eine Tabelle voll läuft (ich rede jetzt nur rein vom ID Wert) dann kann man ja kein Insert mehr machen.

Und nochmals: Angenommen die Anwendung bräuchte die Auto_increment Spalte bzw. die ID gar nicht. Könnte man dann nicht sie Spalte ganz weglassen? Oder ist eine Tabelle ohne Primärschlüssel und nur mit einem Index nicht so gut?

Gruss
Werner

[Tabellenkalk]

Hallo,

Aber nochmals zurück zum Thema Auto_increment bzw. BIGINT.

unsigned BIGINT sogar bis 18446744073709551615

Ich kenne z.b. eine Anwendung aus einem Rechenzentrum die jede 2-3 Sekunden mehrere Inserts macht. Ich glaube ich hatte da mal was von 150000 Zeilen am Tag gesehen.

Na dann nimm doch mal 150000 * 365 * 65 Jahre = 3558750000

Irgend wann wäre doch auch der BIGINT nicht mehr ausreichend. (OK, vielleicht bin ich da vorher in Rente :-) )
Ich hatte das schon mal in einem anderen Thread gefragt.
Wie machen das die großen der Branche, wie Amazon, ebay oder sonstige? Wenn eine Tabelle voll läuft (ich rede jetzt nur rein vom ID Wert) dann kann man ja kein Insert mehr machen.

Also vielleicht das 1000000fache?
3558750000000000 <<< 18446744073709551615

Ich glaube, die können ein paar Generationen so weiter machen...

Gruß
Kalk

[1UnitedPower]

Meine Herren!

das mit der UUID bzw. beim SQL Server die GUID habe ich auch schon gelesen. Aber hier gehen die Meinungen ja sehr auseinander ob sinnvoll oder nicht. Man bräuchte ja mindestens einen Char() Spalte mit 32 Länge.

Speicher ist inzwischen so günstig, dass man sich keine Gedanken mehr um den Speicherbefarf einer ID machen muss, wenn man nicht gerade im Mikrocontroller-Bereich arbeitet. Natürlich haben beide Varianten ihre Vor- und Nachteile. In den meisten Fällen sind autoinkrementelle IDs allein wegen ihrer Lesbarkeit die bessere Wahl.

Und dann wäre es auch nur sinnvoll wenn diese ID inkrementell fortlaufend ist oder?

Nein. Es gibt auch andere Wege Eindeutigkeit zu »garantieren«. Jede Garantie wird dabei durch ihren natürlichen Wertebereich beschränkt. Zur Veranschaulichung: Die Zeit, wenn man die Genauigkeit nur hoch genug wählt, taugt (fast) auch als ID.

Irgend wann wäre doch auch der BIGINT nicht mehr ausreichend. (OK, vielleicht bin ich da vorher in Rente :-) )

Ja, und bevor das passiert ist die Menschheit übrigens auch ausgestorben und es gibt keinen Strom mehr und der Server ist sowieso schon lange ausgefallen.

Bei 150.000 Zeile pro Tag, kann das Programm noch mehr als 74 Erdalter laufen.
(18446744073709551615 / ( 150000 * 365 * 4550000000  )

Ich hatte das schon mal in einem anderen Thread gefragt.
Wie machen das die großen der Branche, wie Amazon, ebay oder sonstige? Wenn eine Tabelle voll läuft (ich rede jetzt nur rein vom ID Wert) dann kann man ja kein Insert mehr machen.

Dann wählt man eben einen größeren Wertebereich. Aber wie gesagt, können die gängigen Bereiche schon einiges leisten.

Und nochmals: Angenommen die Anwendung bräuchte die Auto_increment Spalte bzw. die ID gar nicht. Könnte man dann nicht sie Spalte ganz weglassen? Oder ist eine Tabelle ohne Primärschlüssel und nur mit einem Index nicht so gut?

Klar kannst du Spalte dann auch gleich weglassen.

[hotti]

hi,

Könnte man zwischendurch einen Truncate table machen, anstatt Delete ?

Beim truncate sind etwaige woanders hin getriggerte IDs nicht mehr zuzuordnen, weil's wieder bei 0 beginnt. Alternative ist ein purge oder vacuum, guck mal in die Doku wg. Syntax.

Horst