• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

Mediumint 8 = 16777215 Werte

Splitt3r

New member
Hallo,

Ich nutze in meiner Datenbank für die id werte in der Tabelle die einstellungen

Mediumint

Länge: 8
.

Ich habe gelesen dass diese einstellung 16777215 id´s ermöglicht.

Was passiert wenn eine Tabelle in der Datenbank diesen Wert erreichen würde.

Was machen die richtig Großen communitys die mit solchen Zahlen Arbeiten?

Viele Grüße
 
Hängt immer von der verwendeten Datenbank ab. Entweder gibts schon nen Fehler weil du einen überlauf hast, oder du fängst von vorne an und bekommst dann den Fehler das du die selbe ID zweimal hast.

Nimm nen größeren Datentyp, wenn du glaubst das du mehr als 16 millionen User haben wirst.
 
Ich werde wohl kaum über 16 millionen User haben *g* aber id werte nutze ich fast überall unter anderem auf bei Privaten Nachrichten. und eine id wird niemals 2 mal vergeben, so sammelt sich schon einiges an.

da ich mich leider nur schwach auskenne würde ich mich freuen wenn du mir sagen könntest was für einen Datentyp ich denn wählen kann.

Also was ich in MYSQL auswählen soll.

Viele Grüße
 
unsigned int kann 0 - 4.294.967.295
wenn du meinst das reicht noch nich (unwahrscheinlich) kannste auch unsigned bigint nehmen, das geht dann von 0 - 18.446.744.073.709.551.615 = 2^64-1
 
Unsigned int sollte reichen, damit könntest du die nächsten 10 Jahre 429.496.720 Nachrichten pro Jahr verschicken. Das wären 1.176.700 pro Tag, 49.020 pro Sunde, 810 pro Minute und immer noch 13 pro Sekunde. :d
 
Unsigned int sollte reichen, damit könntest du die nächsten 10 Jahre 429.496.720 Nachrichten pro Jahr verschicken. Das wären 1.176.700 pro Tag, 49.020 pro Sunde, 810 pro Minute und immer noch 13 pro Sekunde. :d

:d

unsigned int kann 0 - 4.294.967.295 reicht vollkommen aus.


Nur worin liegt der vorteil von Mediumint länge 8 wenn es auch unsigned int gibt?
 
Ich werde wohl kaum über 16 millionen User haben *g* aber id werte nutze ich fast überall unter anderem auf bei Privaten Nachrichten. und eine id wird niemals 2 mal vergeben, so sammelt sich schon einiges an.

Bei den privaten Nachrichten könntest du z. B. auch selbst eine UniqueID generieren, und nicht einfach die DB schreiben lassen.
Denn ich denke mal, dass die Nachrichten auch aus deiner DB wieder gelöscht werden nach einer bestimmten Zeit oder aber durch den User (ansonsten würdest du irgendwann ein Haufen nutzloser Daten abspeichern).

Die Generierung könnte z. B. so aussehen, dass du den Unix-Timestamp mit einer ID kombinierst, wobei du die ID jede Stunde wieder bei 0 beginnen lässt.
 
Unsigned int sollte reichen, damit könntest du die nächsten 10 Jahre 429.496.720 Nachrichten pro Jahr verschicken. Das wären 1.176.700 pro Tag, 49.020 pro Sunde, 810 pro Minute und immer noch 13 pro Sekunde. :d

Weißt du ob er nicht einen neuen Spamrekord brechen möchte und diesen in seiner Datenbank dokumentieren :D
 
Bei den privaten Nachrichten könntest du z. B. auch selbst eine UniqueID generieren, und nicht einfach die DB schreiben lassen.
Denn ich denke mal, dass die Nachrichten auch aus deiner DB wieder gelöscht werden nach einer bestimmten Zeit oder aber durch den User (ansonsten würdest du irgendwann ein Haufen nutzloser Daten abspeichern).

Die Generierung könnte z. B. so aussehen, dass du den Unix-Timestamp mit einer ID kombinierst, wobei du die ID jede Stunde wieder bei 0 beginnen lässt.

Warum wenns auch einfacher geht? Ids würde ich auch nicht zweimal vergeben, auch wenn ich Nachrichten lösche und dadurch wieder welche frei werden würden. Dazu müßte ich mir ja nen eigenen IDGenerator schreiben und kann nicht einfach das autoincrement der DB verwenden.
Keep it small and simple :)
 
Ids würde ich auch nicht zweimal vergeben, auch wenn ich Nachrichten lösche und dadurch wieder welche frei werden würden.
Bleiben aufgrund der kombinierten Angaben unique.

Dazu müßte ich mir ja nen eigenen IDGenerator schreiben und kann nicht einfach das autoincrement der DB verwenden.
Keep it small and simple :)

Im Grunde richtig, aber die Möglichkeiten wären ein vielfaches größer und die ID lässt sich ggf. noch für andere Zwecke (z. B. Ermitteln der Versandzeit) gebrauchen. Je nachdem wie man es plant, kann man damit ggf. an anderer Stelle Einsparungen erreichen.
 
Im Grunde richtig, aber die Möglichkeiten wären ein vielfaches größer und die ID lässt sich ggf. noch für andere Zwecke (z. B. Ermitteln der Versandzeit) gebrauchen. Je nachdem wie man es plant, kann man damit ggf. an anderer Stelle Einsparungen erreichen.
Also die Versandzeit wird man sowieso brauchen, aber dafür extra eine Stringoperation durchzuführen, weil man z.B. alle Nachrichten aus einem Zeitraum ermitteln möchte, ist suboptimal.
 
Mag durchaus sein. Es war nur ein Beispiel für eine selbsterstelle Unique ID ;-)
 
Zurück
Oben