Strings schnell ersetzen

[Nersgatt]

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.

[Jasocul]

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.

[Dejan Vu]

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

[p80286]

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 Du wärst jedenfalls nicht der erste, der so etwas anwendet. Da Benutzer im allgemeinen nicht in der Lage sind Tennzeichen, führende Nullen ,Prüfziffern und sonstigen Firlefanz richtig einzugeben gibt es ein Feld "eingedampfter Wert" mit dem Inhalt 12345 da kann man nach 12-345, 123-45, 1-234.5 suchen und wird immer fündig, bzw. es kommt immer ein Vorschlag was es wohl sein könnte. Gut streng genommen handelt es sich um ein Datum was nicht zu meinen Daten gehört, auf der anderen Seite erleichtert es die Suche.

Gruß
K-H

[OlafSt]

Ich habe mal gelernt: Jede Operation sollte nur einmal gemacht werden. Und dieses Ersetzen von Sonderzeichen ist genau so ein Fall. Man kann natürlich dem SQL-Server jedesmal aufs neue die Arbeit aufbürden, in allen selektierten Zeichenketten die Sonderzeichen zu ersetzen, bei jeder Abfrage neu, 250.000x am Tag.

Man kann es aber auch nur einmal machen und die umgewandelte Zeichenkette mitspeichern. Redundanz ist nicht immer ein No-Go, und dieser Fall hier ist ein Paradebeispiel dafür, das ein wenig Redundanz gar nicht so verkehrt ist.