Voorbeeld tabel:

+-----+--------+------------+-----------------+
| id  | userid | date       | number          |
+-----+--------+------------+-----------------+
|  78 |      1 | 2017-07-02 | 26.455471462    |
|  84 |      1 | 2017-07-01 | 28.66009408405  |
|  94 |      1 | 2017-06-30 | 41.88782981515  |
| 110 |      1 | 2017-06-29 | 39.6832071933   |
| 111 |      1 | 2017-06-26 | 44.092452437    |
| 112 |      1 | 2017-05-31 | 220.462262185   |
| 113 |      1 | 2017-05-05 | 222.66688480685 |
| 114 |      1 | 2017-05-04 | 224.8715074287  |
| 115 |      1 | 2017-03-02 | 110.2311310925  |
+-----+--------+------------+-----------------+
9 rows in set (0.00 sec)


SELECT id, userid, number FROM pr WHERE userid = '1' ORDER BY number DESC LIMIT 1;

Als ik deze query uitvoer dan krijg ik de rij met id "111" naar voren terwijl ik de hoogste verwacht en dat is rij 114.


+-----+--------+---------------+
| id  | userid | number        |
+-----+--------+---------------+
| 111 |      1 | 44.092452437  |
+-----+--------+---------------+
1 row in set (0.00 sec)


Iemand een idee hoe ik wel rij 114 krijg?
Welk datatype is het number-veld?
gezien de uitlijning naar links, lijkt de inhoud van de kolom "number" een string type (varchar)

Maak daar eens een numeriek type als DECIMAL of FLOAT van

[size=xsmall]Toevoeging op 03/07/2017 02:46:35:[/size]

en als string beschouwd: 4 is het hoogste begin-karakter.

dus "alfabetisch" gezien komen 44.xxx en 41.xxx achteraan.
en "44" weer na "41", net zoals "44" ook na "422" zou komen.

DD komt ook na DA en DBB zou daar tussen vallen.
Het is inderdaad een datatype varchar. En dat het als een string wordt gezien en dat 4 dan inderdaad het hoogst is klinkt ook wel erg logisch.

Ik was wel begonnen met een ander datatype namelijk int en decimal maar dit werkte niet voor mij omdat de een de punt weg haalde en de ander de 0 op het einde. Maar nu blijkt dat varchar er dus ook niet voor geschikt is.

Welk datatype kan ik kiezen dat het als een getal ziet maar het cijfer wel zo laat als het is inclusief punt? Het getal is namelijk in ponden (lbs) niet afgerond en dit moet zo blijven omdat ik van kg naar lbs reken en weer terug.
Nullen op het einde zijn presentatielogica, en dit moet je dus bij de presentatie oplossen. De betekenis van het getal verandert immers niet.
Adoptive Solution op 03/07/2017 22:07:00

In dit geval zou decimal 15,11 een oplossing zijn.


Thanks heb het geprobeerd en het werkt inderdaad.
Wel vind ik het nog gek dat het in php niet uit maakt als er een 0 helemaal op het einde staat maar met de windows calculator wel.

Maar tot nu toe werkt het goed :)
Zoals in je vorige topic beschreven is had dit meer te maken met hoe de calculator gebruikt wordt dan wat anders. Wanneer de calculator op programmeren staat of je gebruikt een . ipv een , zal de calculator niet met deelgetallen kunnen werken. Bij deelgetallen maken nullen op het einde niet uit, bij gehele getallen (of voor de komma) wel.

Reageren