nicht angemeldet
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