[SQL] max() statement geeft lagere waarde

[ID-College]

Hallo,

Ik zit met de volgende situatie. Ik heb een MySQL database (innodb) met daarin een hoop tables.
Ik moet daar data in ingooien, maar over de structuur heb ik niets te zeggen; er is namelijk een ander programma dat lijdend is en eveneens gebruik maakt van deze database.

Het probleem is dat het ID field geen auto_increment is. Als ik dus data wil toevoegen, moet ik de maximale ID ophalen; deze id ophogen en vervolgens de data inserten. Het probleem is echter dat wanneer ik max(ID) doe, het maximum niet altijd klopt.
In de tabel staat onder de ID kolom het volgende:

code:

1
10
2
3
4
5
6
7
8
9

Hier zie je het al fout gaan, een max(ID) geeft dus als waarde 9 terug. Als ik 9 één ophoog krijg ik 10. Deze bestaat echter al en dus krijg ik een foutmelding. Hoe kan ik hier omheen werken? Ik kan niets aan de structuur veranderen aangezien het andere programma hier al mee werkt. Hoe los ik dit probleem op?

[Cartman!]

Ziet eruit alsof je ID opslaat als string ipv. een int...

Grammaticagrap: met deze opzet klinkt het zeker alsof het andere programma lijdend is

[ Voor 49% gewijzigd door Cartman! op 26-02-2012 15:42 ]

[TweakPino]

Wat voor type heeft kolom ID, int of varchar? Bij varchar verwacht je ook dat MAX(ID) 9 geeft ipv 10, omdat 9 > 1, en het tweede karakter genegeerd wordt (blijkbaar), omdat het eerste karaketer al een uitkomst geeft.
edit: met ^

[ Voor 8% gewijzigd door TweakPino op 26-02-2012 15:42 ]

[CoolGamer]

Als je de structuur niet kan veranderen zal je zelf de waarde moeten casten naar getal in de query. Dit is wel erg inefficiënt, dus dit kan performance problemen geven zodra de tabel groot wordt.

Dan krijg je iets als:

SQL:

SELECT MAX(CAST(ID AS DECIMAL)) FROM ...

[ID-College]

Het is inderdaad een varchar(60) zie ik, en dus geen int. Waarom zou je dat in godsnaam willen vraag ik mij af?
Ik een workaround doen door bijvoorbeeld in mijn code toe te voegen:

PHP:

if($this->ID%3 === 0) {
        $this->_increaseID();
}

Is dit een solide oplossing? Dan wordt het getal dus 2x opgehoogd indien hij bij de 9,99,999 etc zit..
Edit: ohnee, dat gaat niet werken nee Dan gaat ie bij 12 ook nat..

@Coolgamer: dat werkt inderdaad wel ja.. Wellicht een goede oplossing, ware het niet dat ik niet snap waarom je een varchar zou willen een geen auto_increment..?

[ Voor 35% gewijzigd door ID-College op 26-02-2012 15:50 ]

[Cartman!]

Natuurlijk niet... ik denk dat je zelf even moet gaan bedenken waarom.

[Cartman!]

ID-College schreef op zondag 26 februari 2012 @ 15:45:
@Coolgamer: dat werkt inderdaad wel ja.. Wellicht een goede oplossing, ware het niet dat ik niet snap waarom je een varchar zou willen een geen auto_increment..?

Ik snap niet dat jij werkt met (de database van) dat programma

[Voutloos]

offtopic:
OMG wat een datatype faal vd originele app.

Hoe dat het andere programma het? Ook al zou je niet bij de source kunnen: als je alle queries logt, weet je in ieder geval zeker hoe het zogenaamd moet en bovendien kan je dan beter inschatten of dat programma op zijn niet al te mooie smoeltje gaat als jij ook nog in die tabel gaat zitten schrijven.

Cartman! schreef op zondag 26 februari 2012 @ 15:51:
[...]

Ik snap niet dat jij werkt met (de database van) dat programma

Check. Moet je wel uberhaupt allebei in die tabel schrijven? Wil je niet stiekem iets vergelijkbaars opslaan, maar zou dat net zo goed in je eigen tabel kunnen?

[CoolGamer]

ID-College schreef op zondag 26 februari 2012 @ 15:45:
@Coolgamer: dat werkt inderdaad wel ja.. Wellicht een goede oplossing, ware het niet dat ik niet snap waarom je een varchar zou willen een geen auto_increment..?

Dat zal je aan de makers van de software moeten vragen. Misschien is het gedaan om makkelijk compitabel te zijn met SQL-servers van andere fabrikanten. Dit heeft nu dus wel als nadeel dat het minder efficiënt is en dat gebruik van de data in de tabel vanuit andere software lastiger is.

Het is overigens goed mogelijk om wel cross compitabliteit te krijgen terwijl je wel gewoon het juiste kolomtype kiest. Autonummering is lastiger goed werkend te krijgen tussen meerdere SQL-servers.

[ Voor 15% gewijzigd door CoolGamer op 26-02-2012 15:57 ]

[Voutloos]

Het waarom kan je vragen, maar als de inhoud nu echt enkel numeriek en oplopend is, kan je onmogelijk een goede reden als antwoord krijgen.

[ID-College]

Het is een enorm bekend en een groot programma (Jira) en inderdaad, wat CoolGamer zegt dat klopt inderdaad. Het is eenvoudig te connecten met andere databases!

@Voutloos: het gaat om een onderzoek van een Universiteit. Het is niet de vraag of je het wilt, maar of het mogelijk is. Nouja, dus wel, maar niet gewenst denk ik zo

Ik vond het oplopen van de ID's al zo vreemd. Het programma maakt elke keer nieuwe ID's aan en delete alle records en insert vervolgens weer allemaal records.. Efficiënt is het niet nee, maar snap nu meteen waarom dat zo is

[ Voor 25% gewijzigd door ID-College op 26-02-2012 15:59 ]

[CoolGamer]

Pas overigens op met het aanpassen en toevoegen van data buiten JIRA om, zolang JIRA draait. JIRA cached een hoop data, zoals het laatst uitgegeven ID, in het eigen geheugen.

[ Voor 10% gewijzigd door CoolGamer op 26-02-2012 16:00 ]

[ID-College]

Klopt Jira draait niet op het moment nee. Daar was ik achter gekomen ja

[Gomez12]

Voutloos schreef op zondag 26 februari 2012 @ 15:57:
Het waarom kan je vragen, maar als de inhoud nu echt enkel numeriek en oplopend is, kan je onmogelijk een goede reden als antwoord krijgen.

Mogelijke reden is : Custom door de klant aan te maken fields in een multi-db app.

Dat is altijd een drama (performance technisch gezien. Veel geluk met je indexen en je multi-db's op velden waar je niets vanaf weet), dan kan je x weken besteden aan het niet-goed maar wel redelijk maken van je datamodel qua custom fields. Of je kan ervanuit gaan dat mensen maar 1 of 2 van die velden gaan maken en je ervanaf maken met maar 2 uurtjes werk...

[YopY]

Is er geen API voor Jira beschikbaar om zelf bijv. issues toe te voegen (of wat je ook maar probeert te doen)? Kun je niets met de bestaande pluginarchitectuur en beschikbare API's? Tenzij je niks anders kan moet je ook nooit direct in de DB van een applicatie werken, maar via de APIs, intern of extern.

In Jira 5 is er zo te zien ook een REST api, dan hoef je niet eens een officiele plugin te schrijven of Java te programmeren om een issue aan te maken.

Mogelijke reden is : Custom door de klant aan te maken fields in een multi-db app.

Bij Jira kun je als beheerder zijnde al custom fields toevoegen aan alles.

[ID-College]

YopY schreef op zondag 26 februari 2012 @ 21:13:
Is er geen API voor Jira beschikbaar om zelf bijv. issues toe te voegen (of wat je ook maar probeert te doen)? Kun je niets met de bestaande pluginarchitectuur en beschikbare API's? Tenzij je niks anders kan moet je ook nooit direct in de DB van een applicatie werken, maar via de APIs, intern of extern.

In Jira 5 is er zo te zien ook een REST api, dan hoef je niet eens een officiele plugin te schrijven of Java te programmeren om een issue aan te maken.


[...]


Bij Jira kun je als beheerder zijnde al custom fields toevoegen aan alles.

Dat weet ik Het is echter een onderzoek om te kijken of iets haalbaar is

[NMe]

En dat kan dus absoluut niet met de beschikbare API's?

MAX() is trouwens geen statement maar een (aggregate) function, lijkt me wel handig als je je terminologie in orde hebt. veldnaam = MAX(id) is een statement.