Formatierung im View

[Perlsau]

Moin SQL-Spezialisten,

um ein sehr umfangreiches View in einer Firebird-DB etwas übersichtlicher zu gestalten, habe ich mehrere Spalten mit Concat zusammengefaßt:

Code:

...
AS
SELECT
...
A1.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G1,3,'0') ||' = '|| lpad(ZIEHUNGEN.Q1,11,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A2.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G2,4,'0') ||' = '|| lpad(ZIEHUNGEN.Q2,10,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A3.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G3,5,'0') ||' = '|| lpad(ZIEHUNGEN.Q3,09,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A4.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G4,6,'0') ||' = '|| lpad(ZIEHUNGEN.Q4, 7,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A5.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G5,6,'0') ||' = '|| lpad(ZIEHUNGEN.Q5, 6,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A6.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G6,6,'0') ||' = '|| lpad(ZIEHUNGEN.Q6, 5,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A7.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G7,7,'0') ||' = '|| lpad(ZIEHUNGEN.Q7, 5,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A8.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G8,7,'0') ||' = '|| lpad(ZIEHUNGEN.Q8, 5,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',
A9.QUOTENTEXT ||': '|| lpad(ZIEHUNGEN.G9,7,'0') ||' = '|| lpad(ZIEHUNGEN.Q9, 4,'0') ||' '|| WAEHRUNG.WAEHRUNG || ' ',

...

Hat mich zwar einiges an Schweiß und Herumprobieren gekostet, aber es funktioniert jetzt. Dabei ergibt sich jedoch ein Darstellungsproblem: Bei ZIEHUNGEN.Q1 - Q9 handelt es sich um Geldbeträge, also Numeric (15,2). Da diese Beträge teilweise in die Millionen gehen, vermisse ich das Tausender-Trennzeichen (wie heißt der Fachbegriff nochmal?).

Gibt es eine Möglichkeit, einen Numeric-Wert so in einen String zu casten, daß der String das Tausender-Trennzeichen enthält?

[Bernhard Geyer]

Zitat von Perlsau:

Da diese Beträge teilweise in die Millionen gehen, vermisse ich das Tausender-Trennzeichen (wie heißt der Fachbegriff nochmal?)

Sowas ist aufgabe der Darstellungsebene (Bei Delphi TDBGrid und Co.) und nicht Aufgabe des Views sowas schon zu haben. Auf View-Ebene liegt eine Zahl und dies hat als Zahl nunmal kein Tausender-Trennzeichen. Das kommt erst auf Ebene der Präsentationslogik dazu.

[sx2008]

Warum verwendest du kein Calculated Field um die Daten aus mehreren Feldern zusammenzuziehen.
Damit hat man wesentlich mehr Kontrolle über den Feldinhalt da Delphi hier einfach mächtiger ist als SQL.

Dann kannst du deine mühsam zusammengestellte SQL-Formatierung natürlich wieder wegwerfen aber besser ist das.
Das Leerzeichen hinter WAEHRUNG erscheint mir auch überflüssig.

[Perlsau]

Zitat von Bernhard Geyer:

Sowas ist aufgabe der Darstellungsebene (Bei Delphi TDBGrid und Co.) und nicht Aufgabe des Views sowas schon zu haben. Auf View-Ebene liegt eine Zahl und dies hat als Zahl nunmal kein Tausender-Trennzeichen. Das kommt erst auf Ebene der Präsentationslogik dazu.

Das leuchtet vollkommen ein Hab Dank

Zitat von sx2008:

Warum verwendest du kein Calculated Field um die Daten aus mehreren Feldern zusammenzuziehen.
Damit hat man wesentlich mehr Kontrolle über den Feldinhalt da Delphi hier einfach mächtiger ist als SQL.

Auch das leuchtet ein

Zitat von sx2008:

Dann kannst du deine mühsam zusammengestellte SQL-Formatierung natürlich wieder wegwerfen aber besser ist das.

Macht nix, ich hab ja was dabei gelernt!

War aber doch irgendwie eine blöde Idee, ich hatte gerade stundenlang die Firebird-Dokumentation durchstöbert, um meine SQL-Kenntnisse zu erweitern, und kam dabei drauf, daß ich das ja nun mal probieren könne ... Außerdem soll der Anwender ja – was mir erst später aufgefallen ist – auch die Spalten nach den Beträgen sortieren können. So geht das auf jeden Fall mal nicht.

Zitat von sx2008:

Das Leerzeichen hinter WAEHRUNG erscheint mir auch überflüssig.

Das hab ich auch nur wegen der Darstellung drin, damit das Währungs-Zeichen nicht so dicht an der Spalten-Linie hängt.

Ich danke euch beiden für das offenbar dringend notwendige Zurechtrücken meins Blickwinkels

[jobo]

Auch wenn Du bereits Asche auf Dein Haupt gestreut hast:

Ich bin mir nicht sicher, dass das pauschal in den Client gehört. Am ehesten noch, wenn es sich um eine Anwendung mit lokaler/embedded DB handelt.
Und natürlich, wenn die DB keine Formatierungsfunktion mit Thousand Separator bietet.

Eine zentrale DB, die formatierte Reporting Views liefert, finde ich vollkommen ok.

Auf die Schnelle habe ich sowas gefunden:
http://www.firebirdfaq.org/faq362/
und das hier, kann es aber nicht richtig einsortieren, hab grad keine FB am Start.
http://ibexpert.net/ibe/index.php?n=Doc.IbecFormatFloat

Sortierung ist natürlich noch mal ein gesondertes Problem, kann man aber auch in einer unkonvertierten Spalte durchführen.

[Sir Rufo]

Es ist eine philosophische Frage, ob die View formatierte Daten oder rohe Daten liefern soll.

Allerdings ist die Hauptaufgabe einer DB Daten zu speichern und wieder hervorzukramen, und ein Formular, Report, etc. hat als Hauptaufgabe Daten anzuzeigen (oder auch entgegenzunehmen).

Vor diesem Hintergrund gibt es ja auch noch die unterschiedliche Schreibweise von Währungsbeträgen (Währung vor oder nach dem Betrag)

$1000,00 vs. 1000,00€

Wieviele Views oder spezielle Funktionen will man denn schreiben?

Das Betriebssystem weiß (sollte wissen) wie man die Währung darstellt, der DB/Tabelle/View kann es egal sein, und relevant wird es eh erst bei der Ausgabe an den User.

[Perlsau]

Zitat von jobo:

Auch wenn Du bereits Asche auf Dein Haupt gestreut hast: Ich bin mir nicht sicher, dass das pauschal in den Client gehört. Am ehesten noch, wenn es sich um eine Anwendung mit lokaler/embedded DB handelt. Und natürlich, wenn die DB keine Formatierungsfunktion mit Thousand Separator bietet. Eine zentrale DB, die formatierte Reporting Views liefert, finde ich vollkommen ok.

Soweit mir bekannt stellt Firebird diese Funktionalität nicht bereit. Da bräuchte es schon MSSQL oder was ähnlich "Großes" ...

Zitat von jobo:

Auf die Schnelle habe ich sowas gefunden: http://www.firebirdfaq.org/faq362/

Auszug:

It uses default formatting: dot as decimal point, no thousand separator, dates in ISO-8601 format. Just make sure that size of VARCHAR field is large enough to hold the longest string representation of the datatype you are converting.

Zitat von jobo:

und das hier, kann es aber nicht richtig einsortieren, hab grad keine FB am Start. http://ibexpert.net/ibe/index.php?n=Doc.IbecFormatFloat

Da geht's offenbar um irgend eine von IbExpert angebotene Erweiterung, die ich nicht besitze.

Zitat von jobo:

Sortierung ist natürlich noch mal ein gesondertes Problem, kann man aber auch in einer unkonvertierten Spalte durchführen.

Die Sortierung soll ja erst im Client passieren, je nach Lust und Laune des Anwenders.

Ich hab's aber jetzt soweit begriffen, daß ich mein View wieder herstelle, wie's am Anfang war: ohne Zusammenziehen von Spalten. Das scheint mir am sinnvollsten.

[Perlsau]

Zitat von Sir Rufo:

Es ist eine philosophische Frage, ob die View formatierte Daten oder rohe Daten liefern soll.

Ein(e) View ist doch auch nur ein Select, und das (die?) kann natürlich schon irgendwie vorformatiert sein. So benutze ich z.B. in vielen Views den Concat-Befehl, um aus Anrede, Titel, Vor- und Nachname eine Zeile à la "Sehr geehrter Herr Professor Thomas Wichtigheimer," für einen Report vorzubereiten.

Zitat von Sir Rufo:

Allerdings ist die Hauptaufgabe einer DB Daten zu speichern und wieder hervorzukramen, und ein Formular, Report, etc. hat als Hauptaufgabe Daten anzuzeigen (oder auch entgegenzunehmen).

Ich seh das nicht immer so eng: Bei mir darf jeder alles, wenn er's kann

Zitat von Sir Rufo:

Vor diesem Hintergrund gibt es ja auch noch die unterschiedliche Schreibweise von Währungsbeträgen (Währung vor oder nach dem Betrag)
$1000,00 vs. 1000,00€
Wieviele Views oder spezielle Funktionen will man denn schreiben?

Das ist nicht das Problem, denn diese spezielle Anwendung benötigt außer EURO und DM keine andere Währung.

Zitat von Sir Rufo:

Das Betriebssystem weiß (sollte wissen) wie man die Währung darstellt, der DB/Tabelle/View kann es egal sein, und relevant wird es eh erst bei der Ausgabe an den User.

Die Währung im View ist notwendig, weil Beträge mit einem Datum vor der Euro-Einführung in DM angegeben sind. Würde ich dagegen dem Betriebssystem die Darstellung der Währung überlassen, würde immer nur Euro angezeigt.

[sx2008]

Zitat von Sir Rufo:

Es ist eine philosophische Frage, ob die View formatierte Daten oder rohe Daten liefern soll

Ich würde die Frage so beantworten, dass eine View die Felder immer atomar liefern sollte; also z.B. Währung und Betrag getrennt.
Als Ausnahme würde ich z.B. gelten lassen dass eine Filial- und eine Kundennummer zu einem Feld zusammengezogen werden weil diese Kombination im Geschäftsprozess überall verwendet wird.
Andererseits kann und soll eine View ruhig auch die Daten vorverarbeiten insbesondere meine ich damit die Aggregatfunktionen SUM, COUNT, AVG, MIN und MAX.

[Sir Rufo]

Um welche Währung es sich handelt gehört ja auch zu den Daten (sonst köntte es sich ja auch um Hasenköttel handeln).

Diese Information speichere ich als ISO-Code in der DB, aber die Formatierung für die Ausgabe ist nicht die Aufgabe der View/DB