Moin,

ich habe auf dem MySql-Server eine Function erstellt, um bestimmte Zeichen in einem String durch andere Zeichen zu ersetzen.
Ich frage ich mich, ob man da noch irgendwie etwas mehr Geschwindigkeit rausholen könnte? Es geht mir dabei um die Ersetzung von Polnischen Akzenten um den Buchstaben ohne Akzent.

So sieht die Function momentan aus:

markieren

Code:

CREATE DEFINER=`root`@`localhost` FUNCTION `normalize_str`(AStr VarChar(2000)) RETURNS varchar(2000) CHARSET utf8
BEGIN

  declare _withAccents   VarChar(200) default 'ąĆćꣳńÓ󌜏źŻż';
  declare _withoutAccents VarChar(200) default 'aCceLlnOoSsZzZz';
 
  declare _length integer default length(_withAccents);
  declare _i integer default 1;
 
  while (_i <= _length) do
    set AStr = Replace(AStr, substring(_withaccents, _i, 1), substring(_withoutaccents, _i, 1));
    set _i = _i + 1;
  end while;
 

  RETURN AStr;
END

Es wird ja für jedes Sonderzeichen ein Replace ausgelöst. Könnte man das evtl. eleganter lösen?

Danke!

Edit: Das Forum stellt die Sonderzeichen in meinem Quelltext nicht richtig dar. In meiner Function stehen natürlich nicht die &#-Sachen, sondern wirklich das entsprechende Sonderzeichen.

klingt so als wenn Du  translate() gebrauchen könntest, aber das scheint es in MySQL nicht zu geben u.U. könntest Du mit Convert etwas machen aber da ich mich in MySQL nicht soo auskenne halte ich mich da besser zurück.

Gruß
K-H

Wenn ich z.B.

Zitat:

select convert('ąĆćꣳńÓ󌜏źŻż' using latin1)

erhalte ich leider ???????Óó??????
Das hilft mich so nicht wirklich weiter.

Translate sähe wohl wirklich hilfreich aus, allerdings scheint MySql das wirklich nicht zu kennen.

Wieso machst Du das in SQL und nicht in Delphi (über DisplayText bzw. GetText) oder eine berechnete Spalte?

Wenn es schnell gehen soll, hilft vielleicht diese UDF
https://github.com/hholzgra/mysql-udf-regexp

Zitat von Dejan Vu:

Wieso machst Du das in SQL und nicht in Delphi (über DisplayText bzw. GetText) oder eine berechnete Spalte?

Das hier ist der Grund dafür: http://www.delphipraxis.net/184160-d...ml#post1299552
Eine berechnete Spalte könnte ich auch machen. Müsste ich mal probieren, ob das noch spürbar war bringt.

Moin, ich hab den anderen Thread schon gelesen. Daher die Frage.
In Delphi hast Du performancetechnisch kein Problem mehr, wobei ich nicht sagen würde, dass das in SQL grottenlahm ist. Aber den Ansatz in SQL finde ich persönlich hier unsauber, weil hier eine Funktionalität (filtern) in einer der Darstellung dienenden View hinterlegt wird.
Andererseits hat man in SQL natürlich die Flexibilität, das Charactermapping noch anzupassen, ohne die Anwendung neu kompilieren zu müssen.

Hat immer alles zwei Seiten

Da muss man natürlich die Rahmenbedingungen kennen.

Ich fülle das Grid ja nicht mit allen Daten aus der Datenbank, sondern es findet eine Vorfilterung per SQL statt, die die Ergebnismenge schon enorm einschränkt. Nun hab ich das Grid von DevExpress, mit dem die Benutzer nach jeder Spalte hoch- und runter filtern können, wie es ihnen grade beliebt. Das kommt gut an. Und durch die Vorfilterung per SQL ist die Performance auch gut.

Mit den Akzentzeichen ist es nun so, dass diese die Anwender der Software eigentlich gar nicht interessieren, sie aber nunmal in der Datenbank stehen. Mit der Funktion auf Datenbankebene kann ich das Akzentzeichen so früh wie möglich für die Anzeige im Grid rausfiltern. Daher finde ich die Lösung gar nicht soo schlecht.
Ich habe auch schon kurzzeitig überlegt, eine weitere Spalte einzufügen, wohin die Daten ohne Akzentzeichen per Trigger kopiert werden. Aber dazu konnte ich mich noch nicht durchringen, da ich damit ja die Datenbank denormalisieren würde. Davon bekomm ich immer Sodbrennen.

Die Performance der Funktion ist auch in Ordnung, aber etwas schneller wäre halt doch schön.

Zitat von Nersgatt:

Ich habe auch schon kurzzeitig überlegt, eine weitere Spalte einzufügen, wohin die Daten ohne Akzentzeichen per Trigger kopiert werden. Aber dazu konnte ich mich noch nicht durchringen, da ich damit ja die Datenbank denormalisieren würde. Davon bekomm ich immer Sodbrennen.

Na und? Normalisierung wird überbewertet.
Spaß bei Seite.

Alles, was du auf die vorhandenen Daten anwendest, wird dich Performance kosten. Es ist eigentlich nur zu prüfen, wie stark sich das auswirkt. Sind die Auswirkungen in allen Fällen zu groß, muss man auch mal mit den Regeln brechen.
Bei der Erfassung und Änderung der Daten einen Trigger auszulösen, ist für den Anwender in diesem Fall nicht spürbar. Dafür wird es bei den Abfragen keine ernsthaften Geschwindigkeitsnachteile geben. Ein Feld mehr abzufragen ist vielleicht messbar, aber wohl kaum wahrnehmbar.

Hierzu vielleicht ein passendes Zitat:

Zitat:

Jack Sparrow: Well, then, I confess, it is my intention to commandeer one of these .... And thirdly, the code is more what you'd call "guidelines" than actual rules.

Mittlerweile würde ich das auch in der DB oder in einer Zwischenschicht lösen.