---

Vores lille haveforening har lavet et medlemsarkiv i MySql.
Når vi vil sortere på have nummer, så virker det ikke som vi gerne vil.
Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
MySql: `Havenr` varchar(5) default NULL,
Havenr er fortløbende: 1, 2, 3 ... osv.
Kan vi gøre noget for at få sorteringen fortløbende?

--
Aagaard

---

Aagaard wrote:
> Vores lille haveforening har lavet et medlemsarkiv i MySql.
> Når vi vil sortere på have nummer, så virker det ikke som vi gerne vil.
> Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
> Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
> MySql: `Havenr` varchar(5) default NULL,
> Havenr er fortløbende: 1, 2, 3 ... osv.
> Kan vi gøre noget for at få sorteringen fortløbende?

Vælg korrekt data type for kolonnen.

INT fremfor VARCHAR(5)

Arne

---

Arne Vajhøj wrote:
> Aagaard wrote:
>> Vores lille haveforening har lavet et medlemsarkiv i MySql.
>> Når vi vil sortere på have nummer, så virker det ikke som vi gerne vil.
>> Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
>> Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
>> MySql: `Havenr` varchar(5) default NULL,
>> Havenr er fortløbende: 1, 2, 3 ... osv.
>> Kan vi gøre noget for at få sorteringen fortløbende?
>
> Vælg korrekt data type for kolonnen.
>
> INT fremfor VARCHAR(5)

Hvis du ikke har mulighed for at ændre tabel struturen, så
er der det grimme hack:

.... ORDER BY CAST(havenr AS INT)

Arne

---

> Hvis du ikke har mulighed for at ændre tabel struturen, så
> er der det grimme hack:
>
> ... ORDER BY CAST(havenr AS INT)
>
Det kunne jeg via PhpMyAdmin, så var det ok, men gemmer lige kommandoen,
hvis der skulle blive brug for den senere.

--
Aagaard

---

Arne Vajhøj wrote:
> Arne Vajhøj wrote:
>> Aagaard wrote:
>>> Vores lille haveforening har lavet et medlemsarkiv i MySql.
>>> Når vi vil sortere på have nummer, så virker det ikke som vi gerne vil.
>>> Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
>>> Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
>>> MySql: `Havenr` varchar(5) default NULL,
>>> Havenr er fortløbende: 1, 2, 3 ... osv.
>>> Kan vi gøre noget for at få sorteringen fortløbende?
>>
>> Vælg korrekt data type for kolonnen.
>>
>> INT fremfor VARCHAR(5)
>
> Hvis du ikke har mulighed for at ændre tabel struturen, så
> er der det grimme hack:
>
> ... ORDER BY CAST(havenr AS INT)

Man kan også

ORDER BY havenr * 1
Denne vil også virke hvis man også har bogstaver.

---

Martin wrote:
> Arne Vajhøj wrote:
>> Arne Vajhøj wrote:
>>> Aagaard wrote:
>>>> Vores lille haveforening har lavet et medlemsarkiv i MySql.
>>>> Når vi vil sortere på have nummer, så virker det ikke som vi gerne vil.
>>>> Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
>>>> Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
>>>> MySql: `Havenr` varchar(5) default NULL,
>>>> Havenr er fortløbende: 1, 2, 3 ... osv.
>>>> Kan vi gøre noget for at få sorteringen fortløbende?
>>> Vælg korrekt data type for kolonnen.
>>>
>>> INT fremfor VARCHAR(5)
>> Hvis du ikke har mulighed for at ændre tabel struturen, så
>> er der det grimme hack:
>>
>> ... ORDER BY CAST(havenr AS INT)
>
> Man kan også
>
> ORDER BY havenr * 1
> Denne vil også virke hvis man også har bogstaver.

Det virker i MySQL.

Men jeg betragter det nok mere som en bug end som en feature.

Og jeg synes absolut ikke at man skal skrive den slags kode.

Arne

---

Martin skrev:
> Man kan også
> ORDER BY havenr * 1
> Denne vil også virke hvis man også har bogstaver.

Virke? Hvis ens RDBMS virker, vil det rejse en exception - ellers vil
det virke efter GIGO-princippet og blive sorteret efter principper, som
ikke er alment accepterede.

/Lars

---

Lars Kongshøj wrote:
> Martin skrev:
>> Man kan også
>> ORDER BY havenr * 1
>> Denne vil også virke hvis man også har bogstaver.
>
> Virke? Hvis ens RDBMS virker, vil det rejse en exception - ellers vil
> det virke efter GIGO-princippet og blive sorteret efter principper, som
> ikke er alment accepterede.

Spørgsmålet angav at det er MySQL.

Og MySQL har et meget afslappet forhold til tal versus tekst.

Det giver ikke exception og jeg tvivler ikke på at det sorterer fint.

Men man bør aldrig skrive den slags obfuskeret kode. Og på
et eller andet tidspunkt indfører MySQL vel en SQL mode, hvor
det giver fejl.

Arne

---

Arne Vajhøj wrote:
> Lars Kongshøj wrote:
>> Martin skrev:
>>> Man kan også
>>> ORDER BY havenr * 1
>>> Denne vil også virke hvis man også har bogstaver.
>>
>> Virke? Hvis ens RDBMS virker, vil det rejse en exception - ellers vil
>> det virke efter GIGO-princippet og blive sorteret efter principper,
>> som ikke er alment accepterede.
>
> Spørgsmålet angav at det er MySQL.
>
> Og MySQL har et meget afslappet forhold til tal versus tekst.
>
> Det giver ikke exception og jeg tvivler ikke på at det sorterer fint.
>
> Men man bør aldrig skrive den slags obfuskeret kode. Og på
> et eller andet tidspunkt indfører MySQL vel en SQL mode, hvor
> det giver fejl.

Se f.eks. den her rædsel:

mysql> select ('4'+'abc')/'2';
+-----------------+
| ('4'+'abc')/'2' |
+-----------------+
| 2 |
+-----------------+
1 row in set (0.02 sec)

Arne

---

Arne Vajhøj skrev:
> Arne Vajhøj wrote:
>> Lars Kongshøj wrote:
>>> Martin skrev:
>>>> Man kan også
>>>> ORDER BY havenr * 1
>>>> Denne vil også virke hvis man også har bogstaver.
>>>
>>> Virke? Hvis ens RDBMS virker, vil det rejse en exception - ellers vil
>>> det virke efter GIGO-princippet og blive sorteret efter principper,
>>> som ikke er alment accepterede.
>>
>> Spørgsmålet angav at det er MySQL.
>>
>> Og MySQL har et meget afslappet forhold til tal versus tekst.
>>
>> Det giver ikke exception og jeg tvivler ikke på at det sorterer fint.
>>
>> Men man bør aldrig skrive den slags obfuskeret kode. Og på
>> et eller andet tidspunkt indfører MySQL vel en SQL mode, hvor
>> det giver fejl.
>
> Se f.eks. den her rædsel:
>
> mysql> select ('4'+'abc')/'2';
> +-----------------+
> | ('4'+'abc')/'2' |
> +-----------------+
> | 2 |
> +-----------------+
> 1 row in set (0.02 sec)

Ja, det er præcist en rædsel - undskyld mange gange at jeg kom til at
formulere mig for diplomatisk.

Hvordan kan man dog finde på at implementere en så meningsløs semantik?

/Lars

---

Lars Kongshøj wrote:
> Arne Vajhøj skrev:
>> Arne Vajhøj wrote:
>>> Lars Kongshøj wrote:
>>>> Martin skrev:
>>>>> Man kan også
>>>>> ORDER BY havenr * 1
>>>>> Denne vil også virke hvis man også har bogstaver.
>>>>
>>>> Virke? Hvis ens RDBMS virker, vil det rejse en exception - ellers
>>>> vil det virke efter GIGO-princippet og blive sorteret efter
>>>> principper, som ikke er alment accepterede.
>>>
>>> Spørgsmålet angav at det er MySQL.
>>>
>>> Og MySQL har et meget afslappet forhold til tal versus tekst.
>>>
>>> Det giver ikke exception og jeg tvivler ikke på at det sorterer fint.
>>>
>>> Men man bør aldrig skrive den slags obfuskeret kode. Og på
>>> et eller andet tidspunkt indfører MySQL vel en SQL mode, hvor
>>> det giver fejl.
>>
>> Se f.eks. den her rædsel:
>>
>> mysql> select ('4'+'abc')/'2';
>> +-----------------+
>> | ('4'+'abc')/'2' |
>> +-----------------+
>> | 2 |
>> +-----------------+
>> 1 row in set (0.02 sec)
>
> Ja, det er præcist en rædsel - undskyld mange gange at jeg kom til at
> formulere mig for diplomatisk.
>
> Hvordan kan man dog finde på at implementere en så meningsløs semantik?

For at gøre det nemt for den kategori af hobby udviklere som
ikke går op i det der med typer.

Arne

---

Arne Vajhøj skrev:
> For at gøre det nemt for den kategori af hobby udviklere som
> ikke går op i det der med typer.

Jeg har aldrig forstået at nogle programmører mener at ukorrekte inddata
skal give tilfædige uddate i stedet for en fejlmeddelelse.

/Lars

---

Lars Kongshøj wrote:
> Arne Vajhøj skrev:
>> For at gøre det nemt for den kategori af hobby udviklere som
>> ikke går op i det der med typer.
>
> Jeg har aldrig forstået at nogle programmører mener at ukorrekte inddata
> skal give tilfædige uddate i stedet for en fejlmeddelelse.

Der er ikke noget tilfældigt i det og hvis MySQL har dokumenteret det
et eller andet sted, så er det heller ikke ukorrekte inddata.

Det er meget lidt type sikkert.

Jeg kan ikke lide det.

Men der er meget populære programmerings sprog som sætter en
ære i ikke at have strenge type check.

Arne

---

Arne Vajhøj skrev:
> Lars Kongshøj wrote:
>> Jeg har aldrig forstået at nogle programmører mener at ukorrekte
>> inddata skal give tilfædige uddate i stedet for en fejlmeddelelse.
> Der er ikke noget tilfældigt i det og hvis MySQL har dokumenteret det
> et eller andet sted, så er det heller ikke ukorrekte inddata.

Man kan fx specificere at den numeriske værdi af "abc" er
('c'-'0')*100+('b'-'0')*10+('c'-'0').

Spørgsmålet er om nogen kan bruge den definition til noget, bortset fra
programmører, der designer efter "garbage in garbage out"-princippet.

I hvert fald mister man muligheden for at få en exception, ved forsøg på
at konvertere noget, der ikke efter gængse normer er et tal.

> Men der er meget populære programmerings sprog som sætter en
> ære i ikke at have strenge type check.

Ja, men C er designet som et maskinnært sprog. SQL er beregnet til at
løse databaseopgaver.

/Lars

---

Lars Kongshøj wrote:
> Arne Vajhøj skrev:
>> Lars Kongshøj wrote:
>>> Jeg har aldrig forstået at nogle programmører mener at ukorrekte
>>> inddata skal give tilfædige uddate i stedet for en fejlmeddelelse.
>> Der er ikke noget tilfældigt i det og hvis MySQL har dokumenteret det
>> et eller andet sted, så er det heller ikke ukorrekte inddata.
>
> Man kan fx specificere at den numeriske værdi af "abc" er
> ('c'-'0')*100+('b'-'0')*10+('c'-'0').
>
> Spørgsmålet er om nogen kan bruge den definition til noget, bortset fra
> programmører, der designer efter "garbage in garbage out"-princippet.

Alle programmører der sætter sig ind i hvordan det de udvikler i
fungerer kan vel bruge det.

> I hvert fald mister man muligheden for at få en exception, ved forsøg på
> at konvertere noget, der ikke efter gængse normer er et tal.

Hvilket formentligt er grunden til at selvom de kan bruge det, så
vil de ikke være vildt glade for det.

>> Men der er meget populære programmerings sprog som sætter en
>> ære i ikke at have strenge type check.
>
> Ja, men C er designet som et maskinnært sprog. SQL er beregnet til at
> løse databaseopgaver.

Det var ikke C jeg tænkte på - C har nogenlunde type check (mindre end
Ada, men langt bedre end PHP, VBS etc.).

Arne

---

Arne Vajhøj skrev:
> Arne Vajhøj wrote:
>> Aagaard wrote:
>>> Vores lille haveforening har lavet et medlemsarkiv i MySql.
>>> Når vi vil sortere på have nummer, så virker det ikke som vi gerne vil.
>>> Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
>>> Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
>>> MySql: `Havenr` varchar(5) default NULL,
>>> Havenr er fortløbende: 1, 2, 3 ... osv.
>>> Kan vi gøre noget for at få sorteringen fortløbende?
>>
>> Vælg korrekt data type for kolonnen.
>>
>> INT fremfor VARCHAR(5)
>
> Hvis du ikke har mulighed for at ændre tabel struturen, så
> er der det grimme hack:
>
> ... ORDER BY CAST(havenr AS INT)
>

Er det et grimt hack?
Er CAST ikke netop defineret til dette?
Måske ville det lyde bedre, hvis man brugte intval eller parseint.

I øvrigt, så ville jeg bruge "ORDER BY CAST(havenr AS INT), havenr"
for at få sorteret "1, 1A, 1B, 2, 11"

Leif

---

Leif Neland wrote:
> Arne Vajhøj skrev:
>> Arne Vajhøj wrote:
>>> Aagaard wrote:
>>>> Vores lille haveforening har lavet et medlemsarkiv i MySql.
>>>> Når vi vil sortere på have nummer, så virker det ikke som vi gerne vil.
>>>> Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
>>>> Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
>>>> MySql: `Havenr` varchar(5) default NULL,
>>>> Havenr er fortløbende: 1, 2, 3 ... osv.
>>>> Kan vi gøre noget for at få sorteringen fortløbende?
>>>
>>> Vælg korrekt data type for kolonnen.
>>>
>>> INT fremfor VARCHAR(5)
>>
>> Hvis du ikke har mulighed for at ændre tabel struturen, så
>> er der det grimme hack:
>>
>> ... ORDER BY CAST(havenr AS INT)
>>
>
> Er det et grimt hack?
> Er CAST ikke netop defineret til dette?

CAST er defineret til at skifte data type.

Men i dette tilfælde er CAST en workaround - den rigtige løsning
er at give feltet den data type som data reelt er.

> Måske ville det lyde bedre, hvis man brugte intval eller parseint.

Navnet er fint nok.

> I øvrigt, så ville jeg bruge "ORDER BY CAST(havenr AS INT), havenr"
> for at få sorteret "1, 1A, 1B, 2, 11"

Jeg ville kvie mig meget ved at skrive en sådan SQL sætning.

Den vil give fejl i de fleste andre databaser end lige netop
MySQL og matcher heller ikke standarden for parsning i programmerings
sprog.

Men ja - den virker.

Arne

---

Arne Vajhøj skrev:
> Leif Neland wrote:
>> Arne Vajhøj skrev:
>>> Arne Vajhøj wrote:
>>>> Aagaard wrote:
>>>>> Vores lille haveforening har lavet et medlemsarkiv i MySql.
>>>>> Når vi vil sortere på have nummer, så virker det ikke som vi gerne
>>>>> vil.
>>>>> Rækkefølgen bliver: 1, 10, 11, 12 ..19, 2, 20, 21 ... osv.
>>>>> Sql: $sql_query = "SELECT * FROM medlemmer ORDER BY Havenr";
>>>>> MySql: `Havenr` varchar(5) default NULL,
>>>>> Havenr er fortløbende: 1, 2, 3 ... osv.
>>>>> Kan vi gøre noget for at få sorteringen fortløbende?
>>>>
>>>> Vælg korrekt data type for kolonnen.
>>>>
>>>> INT fremfor VARCHAR(5)
>>>
>>> Hvis du ikke har mulighed for at ændre tabel struturen, så
>>> er der det grimme hack:
>>>
>>> ... ORDER BY CAST(havenr AS INT)
>>>
>>
>> Er det et grimt hack?
>> Er CAST ikke netop defineret til dette?
>
> CAST er defineret til at skifte data type.
>
> Men i dette tilfælde er CAST en workaround - den rigtige løsning
> er at give feltet den data type som data reelt er.

Men et husnummer er ikke et tal, det er en streng.
Det er ikke smart, hvis du ikke kan have husnummer 1A

Så må man splitte husnummeret op i taldel og bogstavdel.
Hvis det er en adresse, så er der nogen steder der er separate felter
til gade, nr, bogstav, etage og dør.

Ellers kan man Padde med mellemrum når husnummeret gemmes i db, så
taldelen altid slutter i f.ex. 4. position; det antages at der ikke er
husnumre større end 9999. Altså
" 1"
" 1A"
" 7"
" 10"
" 10B"

Men det kan jo være svært at styre, hvis man ikke har 110% styr på at
det sker i hver eneste sted, data bliver gemt fra.

>
>> Måske ville det lyde bedre, hvis man brugte intval eller parseint.
>
> Navnet er fint nok.
>
>> I øvrigt, så ville jeg bruge "ORDER BY CAST(havenr AS INT), havenr"
>> for at få sorteret "1, 1A, 1B, 2, 11"
>
> Jeg ville kvie mig meget ved at skrive en sådan SQL sætning.
>
> Den vil give fejl i de fleste andre databaser end lige netop
> MySQL og matcher heller ikke standarden for parsning i programmerings
> sprog.
>
> Men ja - den virker.

Desværre, den virker end ikke i MySql (iflg manualen).
Man mangler virkelig en intval-funktion...

Hvis man vil lave det i mysql, kan man skrive "ORDER BY 0+havenr,havenr"
for at få sorteret med bogstaver som 1, 1A, 2, 11

Leif

---

>> Er det et grimt hack?
>> Er CAST ikke netop defineret til dette?
>
> CAST er defineret til at skifte data type.
>
> Men i dette tilfælde er CAST en workaround - den rigtige løsning
> er at give feltet den data type som data reelt er.


Her har jeg brug for hjælp. Vi har en kolonne, med varenumre, som både er
tal og bogstaver. Varenumre skal sorteres 1-2-3-4...10-11 osv, og
bogstaverne a-b-c. Hvordan vil du foreslå at man gør? Vi har en SQL og ikke
en mysql.
Egentlig ville jeg helst bare sortere dem højrestillet, men kan SQL
overhovedet det?

Mvh Maria

---

Maria Frederiksen skrev:

> Her har jeg brug for hjælp. Vi har en kolonne, med varenumre, som både er
> tal og bogstaver. Varenumre skal sorteres 1-2-3-4...10-11 osv, og
> bogstaverne a-b-c. Hvordan vil du foreslå at man gør? Vi har en SQL og ikke
> en mysql.
> Egentlig ville jeg helst bare sortere dem højrestillet, men kan SQL
> overhovedet det?
>
> Mvh Maria
>
>

Hvis man installerer funktionerne til regulære udtryk (regexp) fra denne
side:

http://www.simple-talk.com/sql/t-sql-programming/tsql-regular-expression-workbench/

Kan man gøre dette:

ORDER BY CAST(dbo.RexexReplace('\D+', '', varenr, 1, 1) AS int),varenr
Dette fjerner blot alle ikke-cifre, og konverterer alle cifre til en
int. Afhængig af antal cifre i varenummer skal du måske bruge float.



Jeg har varenumre, der kan hedde "aa-1234-23-45"

ORDER BY CAST(dbo.RegexReplace('\D.*', '', dbo.RegexReplace('^\D+', '',
varenr, 1, 1), 1, 1) AS float), varenr

Her fjerner jeg først alle ikke-cifre i starten af varenr "^\D+"
Derefter alt fra og med første ikke-ciffer "\D.*"
Tilsidst konverteres til et tal for at sortere numerisk.
Jeg bruger float, fordi jeg har varenumre på 11 cifre, og det kan ikke
være i en int.
I sorteringsrækkefølgen sorterer jeg så først efter regexp'en, og
derefter efter det ubehandlede varenr, for at få "postfix'erne" sorteret
rigtigt.

Men, som ovennævnte artikel skriver, så er det ikke så effektivt, men
det virker på SQL Server 2000

/* it is no consolation for those who are stuck with SQL Server 2000,
but the CLR functions are a lot quicker for this sort of usage. */

Hvis jeg bruger det på det fulde udtræk af varelageret, ca 30000
records, får jeg timeout, men på et lille select, går det an.

Ellers ville jeg lave en ekstra kolonne til den numeriske værdi af
varenummeret. For at holde den opdateret, skal man så beregne værdien,
når man indsætter en ny vare, eller opdaterer et varenummer.

Der er så 3 muligheder.
1: Man skal sætte ekstra kode ind i applikationen hvert sted, man
opdaterer varenummeret
2: Man laver en batchkørsel, der f.ex. hver nat beregner værdien. Man må
så leve med, at sorteringen ikke er korrekt den første dag, varen er
indsat/opdateret.
3: Man laver en trigger, så databasen automatisk kalder funktionen til
at beregne sorteringsværdien, når varenummeret ændres/indsættes.

Leif

---

> Vælg korrekt data type for kolonnen.
>
> INT fremfor VARCHAR(5)
>
Tak, Arne, det virker.

--
Aagaard

---

Lars Kongshøj <lars_kongshoj@hotmail.com> writes:

> Ja, det er præcist en rædsel - undskyld mange gange at jeg kom til at
> formulere mig for diplomatisk.

> Hvordan kan man dog finde på at implementere en så meningsløs semantik?

C:\>ping 010.010.010.010

Pinging 8.8.8.8 with 32 bytes of data:

Samme meningsløshed, bare en order of magnitude værre.

--
/Wegge

---

Arne Vajhøj <arne@vajhoej.dk> writes:

> Anders Wegge Keller wrote:
>> Lars Kongshøj <lars_kongshoj@hotmail.com> writes:
>>
>>> Ja, det er præcist en rædsel - undskyld mange gange at jeg kom til at
>>> formulere mig for diplomatisk.
>>
>>> Hvordan kan man dog finde på at implementere en så meningsløs semantik?
>>
>> C:\>ping 010.010.010.010
>>
>> Pinging 8.8.8.8 with 32 bytes of data:
>>
>> Samme meningsløshed, bare en order of magnitude værre.
>
> Meningsløst for ikke-programmøren, men at tal der starter
> med 0 opfattes som oktaler er ret almindeligt programmerings
> sprog.

Det er strtol() eller atoi() der er på banen i begge tilfælde.

--
/Wegge

---

Arne Vajhøj <arne@vajhoej.dk> writes:

> De switcher ikke til oktal automatisk fordi første tal er 0. Det
> er logik højere oppe i app.

$> man 3 strtol

The string may begin with an arbitrary amount of white space (as
determined by isspace(3)) followed by a single optional '+' or '-'
sign. If base is zero or 16, the string may then include a "0x"
prefix, and the number will be read in base 16; otherwise, a zero
base is taken as 10 (decimal) unless the next character is '0', in
which case it is taken as 8 (octal).

I tilfældet ping under windows, er den hypotetiske "logik" en
manglende specifier af hvilket talsystem der er tale om.

--
/Wegge

---

Arne Vajhøj <arne@vajhoej.dk> writes:

> Ah. En lille finesse. Jeg var ikke klar over at base=0 virkede på
> den måde.

De fleste impelmentationer af atoi() er strtol(ptr, NULL, 0). Det er
derfor jeg ikke vil lægge hovedet på blokken for om det er det ene
eller det andet.

> En eller anden må have ment at support for oktal var godt og valgt
> base=0 fremfor base=10.

Det lyder som en efterrationalisering. Prøv at pinge 07.08.09.010, og
fortæl mig hvor meget omtanke der ligger bag den adfærd.

--
/Wegge