MySQL: 0 min 1 = 65535 ?
smallint(5) UNSIGNED
Ik voer een mysql_query uit via PHP waarin ik het getal telkens met 1 verlaag, als volgt:
mysql_query("UPDATE getal = getal - 1 WHERE user = 'admin'");
Als het getal 20 is dan wordt het 19,
nog eens uitvoeren --> 18
en zo 17, 16, 15 ........ 5, 4, 3, 2,1, 0
Maar als ik dan nog een keertje min 1 doe, dan wordt het 65535 terwijl ik graag zou hebben dat het gewoon 0 blijft.
Kan dit opgelost worden binnen die MySQL query of via de instellingen van de database of van de tabel?
Ik zou namelijk willen vermijden dat ik extra code moet schrijven om eerst te checken of het al 0 was om al dan niet de query, die het getal 1 aftrekt, uit te voeren.
Gewijzigd op 01/01/1970 01:00:00 door Fromzon ngl
1) Probeer het eens door met STRICT-mode te werken
2) AND getal > 0 toevoegen aan de query.
Controleer wel of er iets is bijgewerkt (mysql_affected_rows() ) en ga dan pas verder met de volgende stap in de lus. Met break; kun je de lus onderbreken.
Tip: Ga PostgreSQL gebruiken, dan heb je dit soort ellende niet.
Lees en huiver...
eigenlijk een eenvoudige oplossing die:
"AND getal > 0 toevoegen aan de query"
Ik ben beschaamd dat ik daar niet zelf opgekomen ben :-$
Gewijzigd op 01/01/1970 01:00:00 door Fromzon ngl
Data in een MySQL-database kun je dus helemaal nooit vertrouwen! 1 verkeerde query en dat was het dan. En daar krijg je geen foutmelding op, ook niet als je iets onmogelijks uitvoert, MySQL verzint wel de nodige onzin voor jou. Dat je data naar de klote is, dat is jouw probleem...
Onbegrijpelijk dat er nog mensen zijn die hier intrappen.
Zoals pgFrank zegt, moet je zelf iets meer doen om te zorgen dat de query uitgevoerd wordt zoals jij wil. Dus > 0 toevoegen.
succes
ps. pgFrank, stel je niet aan man. Zo erg is MySQL nou ook weer niet!? Waarom wordt MySQL zoveel meer ondersteund dan pgsql??
en het bekt lekkerder
En dit is echt niet de meest grove fout van MySQL, maar gewoon weer eentje in de categorie 'hoe verzin je het'. Het is niet zo dat jij meer moet doen om de query zo uit te voeren zoals jij het wilt, jij moet meer doen omdat de database niet in staat is om correct te rekenen in combinatie met limieten van datatypes. SQL is een vraagtaal, nu vraag jij om van de huidige (onbekende) waarde in de database, bv. 100 af te trekken. In plaats daarvan telt MySQL er een paar duizend bij op! 25 -100 = 65460. En dit ga je niet voorkomen met de > 0 wat ik als lapmiddel heb opgegeven.
In DB2, Oracle en PostgreSQL (de andere databases die ik ken) heb je dit soort onzin dus niet. Dat is ook nergens voor nodig.
Quote:
Waarom wordt MySQL zoveel meer ondersteund dan pgsql?
Gebrek aan kennis. Niks meer en niks minder.
Maar goed, als jij wilt aanmodderen met MySQL, dat is je goed recht.
Tip: Wellicht kun je met STRICT-mode deze ellende voorkomen, probeer het eens uit.
Code (php)
1
SET sql_mode='TRADITIONAL';
En MySQL is zo erg niet als iedereen roept, het is gewoon anders net zoals andere database management systemen. Smaken verschillen :)
MySQL is wel heel anders. Het houdt zich niet aan regels, het heeft een slechtere performance, het output valse resultaten, het laat incorrecte waardes toe, etc. Het heeft niets met smaak te maken.
@Frank
Op zich is het logisch dat een unsigned integer naar 65535 gaat. Unsigned kent geen negatieve getallen en binair gezien is -1 het complement van 0, dus 65535 in dit geval. Ik weet niet of ik een error logisch vind of 65535. Het is gewoon niet slim om geen > 0 toe te voegen.
@PHPErik: Hoe leg je dit soort berekeningen uit aan een klant die net zijn data in roook heeft zien opgaan?
0 - 1 = 65535
65535 + 1 = 65535
Snap jij het nog? Ik denk het wel, maar jouw klant in elk geval niet meer.
pgSQL geeft keurig een error:
Quote:
smallint out of range
Gewijzigd op 01/01/1970 01:00:00 door Frank -
Overigens zou ik zelf ook out of range logischer vinden, maar 65535 is niet geheel ónlogisch.
Het heeft wel met smaak te maken, omdat de manier waarop MySQL standaard foute acties afhandeld en corrigeert een voorkeur is van MySQL zelf. Daardoor is het voor een groot deel ook populair. En zijn er maar genoeg stabiele applicaties draaien die op MySQL, bovendien als jij zo van de standaard bent etc waarom programmeer je dan in PHP ? Die taal is ook niet echt "netjes" hoor ;), maar is juist wat vergevelijk over dingen etc.
Even voor de duidelijkheid trouwens; ik zeg absoluut niet dat MySQL het beste is, t.o.v. andere database management systemen o.i.d. maar vind het bestempelen van MySQL als "slecht" en "smerig" e.d. onterecht.
Quote:
De naam hè van dat database systeem.... My-SQL. Het lijkt dus SQL te gebruiken. Noem het dan My-Pseudo-SQL. Maar zo heet het niet. Met andere woorden het is geen smaak, het is gewoon slecht.Het heeft wel met smaak te maken, omdat de manier waarop MySQL standaard foute acties afhandeld en corrigeert een voorkeur is van MySQL zelf. Daardoor is het voor een groot deel ook populair. En zijn er maar genoeg stabiele applicaties draaien die op MySQL, bovendien als jij zo van de standaard bent etc waarom programmeer je dan in PHP ? Die taal is ook niet echt "netjes" hoor ;), maar is juist wat vergevelijk over dingen etc.
Stabiele applicaties op MySQL bestaan omdat mensen alle controles in PHP uitvoeren, anders is het namelijk niet stabiel c.q. correct te houden.
Het feit dat veel mensen het gebruiken is omdat mensen die PHP aan het leren zijn het snel gebruiken, omdat het gratis is en overal zit ingebakken, maar het blijft nog steeds een slecht systeem. Al gebruiken 1 miljard mensen het.
PHP is inderdaad losely typed zoals dat geloof ik heet, maar PHP is niet incorrect. Bij PHP verneuk je je eigen waardes niet en PHP is voorspelbaar.
Do I need to say more?
ik denk dat we beter OF een ander topic kunnen starten OF het een keer op een meeting kunnen "uitvechten" :p
Quote:
Klopt, maar het moet natuurlijk wiskundig allemaal wel kloppen. Je moet als database engineer (of hoe je het ook in godsnaam allemaal wil noemen ;) ) rekening houden met hoe binaire berekeningen werken.
0 + 1 = 1
0 - 1 = 65535
Binair klopt dat wel, maar waar geef ik op dat ik binair wil rekenen? Helemaal nergens. Ik geef ook nergens op dat ik 'normaal' wil rekenen, maar dat is (gelukkig) wel de standaard. Wanneer je 2 methodes lukraak doorelkaar gooit, ontstaan er altijd onverwachte reseltaten. Dit hoort ook een database gewoon af te keuren. Je kunt op je klompen aanvoelen dat dit 9 van de 10x niet de bedoeling is. Bij twijfel niet inhalen, en in dit geval gewoon een foutmelding geven. Maar ja, MySQL is wat suïcidaal aangelegt...
Quote:
Dat zegt dus meer over PHP en de kwaliteit van de programmeur dan over MySQL. Wanneer MySQL niet in STRICT draait, is het nooit betrouwbaar. Je weet namelijk niet wat de input was, je weet dus ook niet of de huidige opgeslagen waarde ook de correcte waarde is. Zie de topictitel waarbij dit probleem toevallig aan het licht is gekomen. Maar wat als de ts een aantal maanden live zou zijn met zijn systeem en er staat een waarde 2365 in de database? Geen mens die met zekerheid kan aangeven of dit correct is of niet.Stabiele applicaties op MySQL bestaan omdat mensen alle controles in PHP uitvoeren, anders is het namelijk niet stabiel c.q. correct te houden.
Dit zou je alleen kunnen controleren door via een logboek uit te gaan vogelen hoe deze waarde is ontstaan. Maar of dat nu de bedoeling is bij een DBMS? Ik vind van niet. Vandaar dat ik vind dat MySQL een onbetrouwbaar klote product is.
Of is MySQL soms geen DBMS en sla ik daar de plank volkomen mis?
Quote:
:) :) no commentOf is MySQL soms geen DBMS en sla ik daar de plank volkomen mis?