Sortierung nach alphanumerischen Werten?
Sortierung nach alphanumerischen Werten?
am 04.11.2007 23:16:36 von Sebastian Suchanek
Hallo NG!
Ich hätte da noch ein zweites Sortierproblem: Ich habe ein
VARCHAR-Feld, das alphanumerische Typenbezeichnungen enthält,
beispielsweise "D5M LGP", "D9N", "D10", "D11R CD" und "D350D".
Lasse ich das durch MySQL sortieren, erhalte ich -
logischerweise - die Reihenfolge "D10", "D11R CD", "D350D",
"D5M LGP", "D9N". (Kollation des Feldes ist dabei
latin1_german2_ci.)
Was ich aber lieber hätte, ist die für Menschen vermutlich
näherliegende Reihenfolge, wie ich sie zuerst aufgezählt habe.
Welche Möglichkeiten seht Ihr, das zu erreichen? Gibt's evtl.
besondere Kollationen für sowas?
Als eine Lösung fiele mir ein weiteres, "internes" Datenfeld
ein, das ich ausschließlich zum Sortieren verwende und dort
"D005M LGP", "D009N" etc. händisch eintragen - das sehe ich aber
eher als letzten Ausweg.
Die Inhalte des "richtigen" Datenfeldes so abzuändern kommt
jedenfalls nicht in Frage.
TIA,
Sebastian
--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 07:30:18 von Andreas Kretschmer
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 08:13:23 von Peter Schleif
Andreas Kretschmer schrieb:
>
> regexp_replace
Ein solche Funktion hab ich mir auch schon lange gewünscht. Aber IMHO
existiert sie in MySQL nicht (5.0.18).
Ich habe ein ähnliches Sortierproblem wie Sebastians' so gelöst:
ORDER BY CONVERT( MID(s,2,99), UNSIGNED )
Nicht sehr elegant, weil es natürlich nur funktioniert, wenn die
signifikanten Zahlen ab der zweiten Position im String vorkommen. Aber
bei meiner damaligen Aufgabenstellung war das so.
Peter
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 08:26:25 von Sebastian Suchanek
Peter Schleif schrieb:
> Andreas Kretschmer schrieb:
>> regexp_replace
>
> Ein solche Funktion hab ich mir auch schon lange gewünscht.
ACK.
> [...]
> Ich habe ein ähnliches Sortierproblem wie Sebastians' so gelöst:
>
> ORDER BY CONVERT( MID(s,2,99), UNSIGNED )
>
> Nicht sehr elegant, weil es natürlich nur funktioniert, wenn die
> signifikanten Zahlen ab der zweiten Position im String vorkommen.
Daran scheitert's bei mir schon wieder. Derzeit habe ich Felder,
in denen die Zahlen ab der zweiten (siehe OP) oder ab der dritten
Stelle kommen (z.B. "WA470-3" vs. "WA75-3").
Tschüs,
Sebastian
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 08:35:55 von Andreas Kretschmer
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 08:53:41 von Peter Schleif
Sebastian Suchanek schrieb:
>
> Daran scheitert's bei mir schon wieder. Derzeit habe ich Felder,
> in denen die Zahlen ab der zweiten (siehe OP) oder ab der dritten
> Stelle kommen (z.B. "WA470-3" vs. "WA75-3").
Dann wird's wohl noch uneleganter, weil Du erst eine
Fallunterscheidung einbauen mußt, ob das zweite Zeichen eine Zahl ist.
Dann enstprechend MID(s,2,99) oder eben MID(s,3,99) wählen.
Mit etwas Aufwand kann man es natürlich auch allgemeiner formulieren
und z.B. die Position des ersten Vorkommens von 0..9 im String
ermitteln. Und diesen Wert dann in der MID(s, pos, 99) verwenden.
Aber meistens gehorchen solche Modellbezeichnungen(?) ja doch einem
gewissen Schema, welches i.d.R. bekannt ist.
Peter
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 09:25:41 von Sebastian Suchanek
Andreas Kretschmer schrieb:
> begin Sebastian Suchanek schrieb:
>
>>> Nicht sehr elegant, weil es natürlich nur funktioniert, wenn die
>>> signifikanten Zahlen ab der zweiten Position im String vorkommen.
>> Daran scheitert's bei mir schon wieder. Derzeit habe ich Felder,
>> in denen die Zahlen ab der zweiten (siehe OP) oder ab der dritten
>> Stelle kommen (z.B. "WA470-3" vs. "WA75-3").
>
> Du wirst doch sicher es schaffen, alle Nicht-Ziffern durch '' zu
> ersetzen,
Ja, mit REGEXP_REPLACE wäre das sehr einfach. Nur hat das halt
MySQL (5.0) nicht.
> notfalls halt Zeichen für Zeichen durchgehen durch den String.
-v, please.
Tschüs,
Sebastian
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 10:12:49 von Andreas Kretschmer
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 11:30:10 von Harald Fuchs
In article ,
Sebastian Suchanek writes:
> Andreas Kretschmer schrieb:
>> begin Sebastian Suchanek schrieb:
>>
>>>> Nicht sehr elegant, weil es natürlich nur funktioniert, wenn die
>>>> signifikanten Zahlen ab der zweiten Position im String vorkommen.
>>> Daran scheitert's bei mir schon wieder. Derzeit habe ich Felder, in
>>> denen die Zahlen ab der zweiten (siehe OP) oder ab der dritten
>>> Stelle kommen (z.B. "WA470-3" vs. "WA75-3").
>>
>> Du wirst doch sicher es schaffen, alle Nicht-Ziffern durch '' zu
>> ersetzen,
> Ja, mit REGEXP_REPLACE wäre das sehr einfach. Nur hat das halt MySQL
> (5.0) nicht.
Schon mal
http://www.php-groupies.de/blogs/archives/17-Regular-Express ion-Functions-for-MySQL.html
angeschaut?
Re: Sortierung nach alphanumerischen Werten?
am 05.11.2007 13:39:30 von Sebastian Suchanek
Harald Fuchs schrieb:
> In article ,
> Sebastian Suchanek writes:
>
>> Andreas Kretschmer schrieb:
>>> begin Sebastian Suchanek schrieb:
>>>
>>>>> Nicht sehr elegant, weil es natürlich nur funktioniert, wenn die
>>>>> signifikanten Zahlen ab der zweiten Position im String vorkommen.
>>>> Daran scheitert's bei mir schon wieder. Derzeit habe ich Felder, in
>>>> denen die Zahlen ab der zweiten (siehe OP) oder ab der dritten
>>>> Stelle kommen (z.B. "WA470-3" vs. "WA75-3").
>>> Du wirst doch sicher es schaffen, alle Nicht-Ziffern durch '' zu
>>> ersetzen,
>
>> Ja, mit REGEXP_REPLACE wäre das sehr einfach. Nur hat das halt MySQL
>> (5.0) nicht.
>
> Schon mal
>
> http://www.php-groupies.de/blogs/archives/17-Regular-Express ion-Functions-for-MySQL.html
>
> angeschaut?
Nein, noch nicht. Aber auf den ersten Blick sieht das
vielversprechend aus, da werde ich mich mal durchbeißen - danke!
Tschüs,
Sebastian
Installation von UDF unter Debian (was: Sortierung nach alphanumerischen Werten?)
am 06.11.2007 22:58:44 von Sebastian Suchanek
Thus spoke Harald Fuchs:
> [...]
> Schon mal
>
> http://www.php-groupies.de/blogs/archives/17-Regular-Express ion-Functions-for-MySQL.html
>
> angeschaut?
Ich wollte das gerade auf meinem Debian-Etch-System
ausprobieren und bin dabei leider in einer Sackgasse
gelandet.
Das Source-Paket von MySQL ist installiert, der
configure-Lauf des o.g. Sourcecodes bricht aber mit der
Zeile
| checking for mysql source directory... configure: error: not configured yet
ab. Ich deute die Meldung so, daß ich erst mit den
MySQL-Sourcen einen eigenen configure-Lauf machen muß,
damit's mit dem UDF-Paket klappt.
Jetzt gehe ich weiters davon aus, daß ich für das
MySQL-configure möglichst die selben Parameter wie die
Debian-Maintainer verwenden sollte, damit die UDFs hinterher
funktionieren.
Das bringt mich nun zu der Frage, wie ich herausfinde, wie
eben diese Original-Paramter sind bzw. waren.
Kann mir da - bzw. generell mit der Installation der UDFs -
jemand weiterhelfen?
TIA,
Sebastian
--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de
Re: Installation von UDF unter Debian (was: Sortierung nachalphanumerischen Werten?)
am 07.11.2007 00:03:07 von Norbert Tretkowski
Am Tue, 06 Nov 2007 22:58:44 +0100 schrieb Sebastian Suchanek:
> Das bringt mich nun zu der Frage, wie ich herausfinde, wie eben diese
> Original-Paramter sind bzw. waren.
Lade dir das diff.gz der entsprechenden Version herunter und sieh dir
die darin enthaltende Datei debian/rules an.
Norbert
Re: Installation von UDF unter Debian
am 07.11.2007 21:24:14 von Sebastian Suchanek
Thus spoke Norbert Tretkowski:
> Am Tue, 06 Nov 2007 22:58:44 +0100 schrieb Sebastian
> Suchanek:
>
>> Das bringt mich nun zu der Frage, wie ich herausfinde, wie
>> eben diese Original-Paramter sind bzw. waren.
>
> Lade dir das diff.gz der entsprechenden Version herunter
> und sieh dir die darin enthaltende Datei debian/rules an.
Danke, den configure-Lauf für MySQL selbst habe ich
inzwischen hinbekommen. (Ein paar Librarys nachinstalliert &
das Doc-Verzeichnis aus den Original-Sourcen nachgeholt und
verwendet.)
Das configure für die UDFs hat auch funktioniert, nur leider
das make nicht. Hier die Ausgaben (leider etwas länger):
************************************************************ ****
# make
make all-am
make[1]: Entering directory `/home/sebastian/mysql-regex/UDF-regexp-1.0'
if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/src/mysql-dfsg-5.0-5.0.32//include -I/usr/src/mysql-dfsg-5.0-5.0.32/ -I/usr/src/mysql-dfsg-5.0-5.0.32//sql -g -O2 -MT regexp_la-regexp.lo -MD -MP -MF ".deps/regexp_la-regexp.Tpo" -c -o regexp_la-regexp.lo `test -f 'regexp.c' || echo './'`regexp.c; \
then mv -f ".deps/regexp_la-regexp.Tpo" ".deps/regexp_la-regexp.Plo"; else rm -f ".deps/regexp_la-regexp.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/src/mysql-dfsg-5.0-5.0.32//include -I/usr/src/mysql-dfsg-5.0-5.0.32/ -I/usr/src/mysql-dfsg-5.0-5.0.32//sql -g -O2 -MT regexp_la-regexp.lo -MD -MP -MF .deps/regexp_la-regexp.Tpo -c regexp.c -fPIC -DPIC -o .libs/regexp_la-regexp.o
In file included from /usr/include/asm/bitops.h:8,
from /usr/include/linux/bitops.h:9,
from /usr/include/asm-i486/cpufeature.h:10,
from /usr/include/asm/cpufeature.h:8,
from /usr/include/asm-i486/processor.h:16,
from /usr/include/asm/processor.h:8,
from /usr/include/asm-i486/atomic.h:5,
from /usr/include/asm/atomic.h:8,
from /usr/src/mysql-dfsg-5.0-5.0.32//include/my_global.h:318,
from regexp.c:56:
/usr/include/asm-i486/bitops.h:244: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'int'
In file included from /usr/include/asm/system.h:8,
from /usr/include/asm-i486/processor.h:18,
from /usr/include/asm/processor.h:8,
from /usr/include/asm-i486/atomic.h:5,
from /usr/include/asm/atomic.h:8,
from /usr/src/mysql-dfsg-5.0-5.0.32//include/my_global.h:318,
from regexp.c:56:
/usr/include/asm-i486/system.h:306: error: expected declaration specifiers or '...' before 'u8'
/usr/include/asm-i486/system.h:306: error: expected declaration specifiers or '...' before 'u8'
/usr/include/asm-i486/system.h:307: error: expected declaration specifiers or '...' before 'u16'
/usr/include/asm-i486/system.h:307: error: expected declaration specifiers or '...' before 'u16'
/usr/include/asm-i486/system.h:308: error: expected declaration specifiers or '...' before 'u32'
/usr/include/asm-i486/system.h:308: error: expected declaration specifiers or '...' before 'u32'
/usr/include/asm-i486/system.h: In function 'cmpxchg_386':
/usr/include/asm-i486/system.h:315: error: too many arguments to function 'cmpxchg_386_u8'
/usr/include/asm-i486/system.h:317: error: too many arguments to function 'cmpxchg_386_u16'
/usr/include/asm-i486/system.h:319: error: too many arguments to function 'cmpxchg_386_u32'
In file included from /usr/include/linux/cpumask.h:86,
from /usr/include/asm-i486/processor.h:22,
from /usr/include/asm/processor.h:8,
from /usr/include/asm-i486/atomic.h:5,
from /usr/include/asm/atomic.h:8,
from /usr/src/mysql-dfsg-5.0-5.0.32//include/my_global.h:318,
from regexp.c:56:
/usr/include/linux/bitmap.h: In function 'bitmap_zero':
/usr/include/linux/bitmap.h:131: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h:131: error: (Each undeclared identifier is reported only once
/usr/include/linux/bitmap.h:131: error: for each function it appears in.)
/usr/include/linux/bitmap.h: In function 'bitmap_fill':
/usr/include/linux/bitmap.h:146: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_copy':
/usr/include/linux/bitmap.h:152: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_and':
/usr/include/linux/bitmap.h:163: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_or':
/usr/include/linux/bitmap.h:172: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_xor':
/usr/include/linux/bitmap.h:181: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_andnot':
/usr/include/linux/bitmap.h:190: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_complement':
/usr/include/linux/bitmap.h:199: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_equal':
/usr/include/linux/bitmap.h:208: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_intersects':
/usr/include/linux/bitmap.h:217: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_subset':
/usr/include/linux/bitmap.h:226: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_empty':
/usr/include/linux/bitmap.h:234: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_full':
/usr/include/linux/bitmap.h:242: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_weight':
/usr/include/linux/bitmap.h:250: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_shift_right':
/usr/include/linux/bitmap.h:258: error: 'BITS_PER_LONG' undeclared (first use in this function)
/usr/include/linux/bitmap.h: In function 'bitmap_shift_left':
/usr/include/linux/bitmap.h:267: error: 'BITS_PER_LONG' undeclared (first use in this function)
In file included from /usr/include/asm-i486/processor.h:22,
from /usr/include/asm/processor.h:8,
from /usr/include/asm-i486/atomic.h:5,
from /usr/include/asm/atomic.h:8,
from /usr/src/mysql-dfsg-5.0-5.0.32//include/my_global.h:318,
from regexp.c:56:
/usr/include/linux/cpumask.h: At top level:
/usr/include/linux/cpumask.h:88: error: expected specifier-qualifier-list before 'DECLARE_BITMAP'
/usr/include/linux/cpumask.h: In function '__cpu_set':
/usr/include/linux/cpumask.h:94: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpu_clear':
/usr/include/linux/cpumask.h:100: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_setall':
/usr/include/linux/cpumask.h:106: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_clear':
/usr/include/linux/cpumask.h:112: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpu_test_and_set':
/usr/include/linux/cpumask.h:121: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_and':
/usr/include/linux/cpumask.h:128: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:128: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:128: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_or':
/usr/include/linux/cpumask.h:135: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:135: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:135: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_xor':
/usr/include/linux/cpumask.h:142: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:142: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:142: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_andnot':
/usr/include/linux/cpumask.h:150: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:150: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:150: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_complement':
/usr/include/linux/cpumask.h:157: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:157: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_equal':
/usr/include/linux/cpumask.h:164: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:164: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_intersects':
/usr/include/linux/cpumask.h:171: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:171: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_subset':
/usr/include/linux/cpumask.h:178: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:178: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_empty':
/usr/include/linux/cpumask.h:184: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_full':
/usr/include/linux/cpumask.h:190: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_weight':
/usr/include/linux/cpumask.h:196: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_shift_right':
/usr/include/linux/cpumask.h:204: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:204: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_shift_left':
/usr/include/linux/cpumask.h:212: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:212: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpumask_scnprintf':
/usr/include/linux/cpumask.h:273: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpumask_parse':
/usr/include/linux/cpumask.h:281: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpulist_scnprintf':
/usr/include/linux/cpumask.h:289: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpulist_parse':
/usr/include/linux/cpumask.h:295: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpu_remap':
/usr/include/linux/cpumask.h:303: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:303: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h: In function '__cpus_remap':
/usr/include/linux/cpumask.h:311: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:311: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:311: error: 'cpumask_t' has no member named 'bits'
/usr/include/linux/cpumask.h:311: error: 'cpumask_t' has no member named 'bits'
In file included from /usr/include/asm/processor.h:8,
from /usr/include/asm-i486/atomic.h:5,
from /usr/include/asm/atomic.h:8,
from /usr/src/mysql-dfsg-5.0-5.0.32//include/my_global.h:318,
from regexp.c:56:
/usr/include/asm-i486/processor.h: At top level:
/usr/include/asm-i486/processor.h:80: error: 'CONFIG_X86_L1_CACHE_SHIFT' undeclared here (not in a function)
/usr/include/asm-i486/processor.h:80: error: requested alignment is not a constant
make[1]: *** [regexp_la-regexp.lo] Error 1
make[1]: Leaving directory `/home/sebastian/mysql-regex/UDF-regexp-1.0'
make: *** [all] Error 2
#
************************************************************ ****
Kann sich jemand einen Reim auf diese Ausgaben machen? Kann
evtl. jemand mal selbst versuchen, die UDFs zu kompilieren?
TIA,
Sebastian
--
http://www.baumaschinen-modelle.net
http://www.schwerlast-rhein-main.de
Leistungsfähigkeit von stored procedtures (was: Sortierung nach alphanumerischen Werten?)
am 09.11.2007 23:10:27 von Sebastian Suchanek
Andreas Kretschmer schrieb:
> begin Sebastian Suchanek schrieb:
>>> notfalls halt Zeichen für Zeichen durchgehen durch den String.
>> -v, please.
>
> Stringlänger ermitteln, von Zeichen 1 bis zum Ende in Schleife
> durchlaufen, neuen String frickeln der nur die numerischen Zeichen
> enthält.
Da es auf der "UDF-Baustelle" momentan nicht so recht vorwärts geht,
habe ich mich mal um den stored-procedures-Ansatz gekümmert.
Herausgekommen ist dies:
CREATE FUNCTION letters (input CHAR(50)) RETURNS CHAR(50) NO SQL
BEGIN
DECLARE max, x INT DEFAULT 1;
DECLARE output CHAR(50) DEFAULT '';
SET max = LENGTH(input);
WHILE ((SUBSTR(input, x, 1) NOT REGEXP '[0-9]') AND (x <= max)) DO
SET output = CONCAT(output, SUBSTR(input, x, 1));
SET x=x+1;
END WHILE;
SET output = TRIM(output);
RETURN output;
END;
CREATE FUNCTION numbers (input CHAR(50)) RETURNS INT NO SQL
BEGIN
DECLARE max, x INT DEFAULT 1;
DECLARE output CHAR(50) DEFAULT '';
SET max = LENGTH(input);
WHILE ((SUBSTR(input, x, 1) NOT REGEXP '[0-9]') AND (x <= max)) DO
SET x=x+1;
END WHILE;
WHILE ((SUBSTR(input, x, 1) REGEXP '[0-9]') AND (x <= max)) DO
SET output = CONCAT(output, SUBSTR(input, x, 1));
SET x=x+1;
END WHILE;
RETURN output;
END;
Diese beiden Funktionen verwende ich dann dergestalt, daß ich mir im
SELECT zwei zusätzliche Spalten erstellen mit jeweils der Ausgabe von
"letters" und "numbers" erstellen lasse. (Jeweils eingebettet in ein
IF-Konstrukt, um leere Strings zu NULL-Werten zu wandeln.) Sortiert wird
dann so:
....ORDER BY Hersteller,COALESCE(letters-Spalte,typ),numbers-Spalte,typ
Prinzipiell funktioniert die Lösung in dem Sinn, daß ich die von mir
gewünschte Sortierung erhalte. Allerdings schnellt die Ausführungszeit
des SELECTs von 0,10..0,15s auf 0,45..0,50s hoch[1], also auf knapp die
fünffache Zeit. Dummerweise ist der (Web-)server, auf dem das
schlußendlich laufen soll, ohnehin etwas schwachbrüstig... :-(
Lange Rede, kurzer Sinn: Seht Ihr da noch Optimierungspotential im
Allgemeinen und in den stored procedures im Besonderen?
TIA,
Sebastian
_____
Anmerkungen:
[1] Getestet habe ich die stored-procedures-Lösung gegen eine "manuelle"
Lösung, in der ich die Haupttabelle um zwei weitere Spalten ergänzt
habe und diese - allerdings nur bei "Problemfall-Datensätzen" -
manuell und "dauerhaft" mit den Rückgabewerten der o.g. Funktionen
gefüllt habe. Bei dieser Lösung bzw. kompletten Weglassen der
verbesserten Sortierung erhalte ich die o.g. deutlich kürzeren
Zeiten.
Re: Leistungsfähigkeitvon stored procedtures
am 12.11.2007 10:54:21 von Andreas Kretschmer
Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de
Re: Leistungsfähigkeit von stored procedtures
am 18.11.2007 12:55:44 von Sebastian Suchanek
Andreas Kretschmer schrieb:
> begin Sebastian Suchanek schrieb:
>
>> Prinzipiell funktioniert die Lösung in dem Sinn, daß ich die von mir
>> gewünschte Sortierung erhalte. Allerdings schnellt die Ausführungszeit
>> des SELECTs von 0,10..0,15s auf 0,45..0,50s hoch[1], also auf knapp die
>> fünffache Zeit. Dummerweise ist der (Web-)server, auf dem das
>
> IIRC kann MySQL keine funktionalen Indexe, weswegen sich da der Aufwand
> für das System erhöht. Funktionale Indexe, als Indexe auf das Resultat
> einer Funktion, hier: der Sortierfunktion, würden helfen.
Nach einem kleinen Test gerade eben bin ich mir in meinem speziellen
Fall da nicht so sicher.
Vom Grundsatz her ein und dieselbe Abfrage, mit leichten Modifikationen:
1. Zwei händisch angelegte, indizierte Hilfsspalten mit Buchstaben und
Ziffern, nach denen auch sortiert wird
=> 0,14s
2. Aufruf der beiden Stored Procedures in der Abfrage, Sortierung aber
weiterhin anhand der o.g. Hilfsspalten
=> 0,34s
3. Aufruf der beiden Stored Procedures und auch Sortierung danach, der
Vergleichbarkeit wegen zusätzlich mit den Hilfsspalten in der
Ergebnistabelle
=> 0,40s
Meine Schlußfolgerung daraus: Den Großteil der zusätzlichen Abfragezeit
macht nicht der fehlende Index auf die Ergebnisse der Stored Procedures
aus, sondern die Ausführung derselben.
Tschüs,
Sebastian
Re: Leistungsfähigkeit von stored procedtures
am 18.11.2007 13:58:17 von Stefan Braumeister
Sebastian Suchanek schrieb:
> Andreas Kretschmer schrieb:
>> begin Sebastian Suchanek schrieb:
>>>> notfalls halt Zeichen für Zeichen durchgehen durch den String.
>>> -v, please.
>> Stringlänger ermitteln, von Zeichen 1 bis zum Ende in Schleife
>> durchlaufen, neuen String frickeln der nur die numerischen Zeichen
>> enthält.
>
> Da es auf der "UDF-Baustelle" momentan nicht so recht vorwärts geht,
> habe ich mich mal um den stored-procedures-Ansatz gekümmert.
> Herausgekommen ist dies:
>
> CREATE FUNCTION letters (input CHAR(50)) RETURNS CHAR(50) NO SQL
> BEGIN
> DECLARE max, x INT DEFAULT 1;
> DECLARE output CHAR(50) DEFAULT '';
> SET max = LENGTH(input);
> WHILE ((SUBSTR(input, x, 1) NOT REGEXP '[0-9]') AND (x <= max)) DO
> SET output = CONCAT(output, SUBSTR(input, x, 1));
> SET x=x+1;
Komplizierter gings nicht?
Wieso durchläufst du nicht einfach das input array prüfst ob der ASCII
code < 48 bzw > 57 ist oder wenn du nur a-z willst, dann eben dessen
ascii codes. Substring regexp ist doch komplett überflüssig hier.
> END WHILE;
> SET output = TRIM(output);
> RETURN output;
> END;
>
> CREATE FUNCTION numbers (input CHAR(50)) RETURNS INT NO SQL
> BEGIN
> DECLARE max, x INT DEFAULT 1;
> DECLARE output CHAR(50) DEFAULT '';
> SET max = LENGTH(input);
> WHILE ((SUBSTR(input, x, 1) NOT REGEXP '[0-9]') AND (x <= max)) DO
> SET x=x+1;
> END WHILE;
> WHILE ((SUBSTR(input, x, 1) REGEXP '[0-9]') AND (x <= max)) DO
> SET output = CONCAT(output, SUBSTR(input, x, 1));
> SET x=x+1;
> END WHILE;
> RETURN output;
> END;
>
> Diese beiden Funktionen verwende ich dann dergestalt, daß ich mir im
> SELECT zwei zusätzliche Spalten erstellen mit jeweils der Ausgabe von
> "letters" und "numbers" erstellen lasse. (Jeweils eingebettet in ein
> IF-Konstrukt, um leere Strings zu NULL-Werten zu wandeln.) Sortiert wird
> dann so:
>
> ...ORDER BY Hersteller,COALESCE(letters-Spalte,typ),numbers-Spalte,typ
>
> Prinzipiell funktioniert die Lösung in dem Sinn, daß ich die von mir
> gewünschte Sortierung erhalte. Allerdings schnellt die Ausführungszeit
> des SELECTs von 0,10..0,15s auf 0,45..0,50s hoch[1], also auf knapp die
> fünffache Zeit. Dummerweise ist der (Web-)server, auf dem das
> schlußendlich laufen soll, ohnehin etwas schwachbrüstig... :-(
>
> Lange Rede, kurzer Sinn: Seht Ihr da noch Optimierungspotential im
> Allgemeinen und in den stored procedures im Besonderen?
>
>
> TIA,
>
> Sebastian
> _____
> Anmerkungen:
> [1] Getestet habe ich die stored-procedures-Lösung gegen eine "manuelle"
> Lösung, in der ich die Haupttabelle um zwei weitere Spalten ergänzt
> habe und diese - allerdings nur bei "Problemfall-Datensätzen" -
> manuell und "dauerhaft" mit den Rückgabewerten der o.g. Funktionen
> gefüllt habe. Bei dieser Lösung bzw. kompletten Weglassen der
> verbesserten Sortierung erhalte ich die o.g. deutlich kürzeren
> Zeiten.
Re: Leistungsfähigkeit von stored procedtures
am 18.11.2007 14:28:17 von Sebastian Suchanek
Stefan Braumeister schrieb:
> Sebastian Suchanek schrieb:
>> [...]
>> CREATE FUNCTION letters (input CHAR(50)) RETURNS CHAR(50) NO SQL
>> BEGIN
>> DECLARE max, x INT DEFAULT 1;
>> DECLARE output CHAR(50) DEFAULT '';
>> SET max = LENGTH(input);
>> WHILE ((SUBSTR(input, x, 1) NOT REGEXP '[0-9]') AND (x <= max)) DO
>> SET output = CONCAT(output, SUBSTR(input, x, 1));
>> SET x=x+1;
>
> Komplizierter gings nicht?
>
> Wieso durchläufst du nicht einfach das input array prüfst ob der ASCII
^^^^^^^^^^^^^^^
> code < 48 bzw > 57 ist
> [...]
Wenn Du mir einen Tip gibst, wie das funktioniert...
Tschüs,
Sebastian