Formatierung im View

[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 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.

[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

[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]

Zitat von 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.

Das sind dann ja auch immer noch rohe Daten, die für die Ausgabe noch formatiert werden müssen
(Währungssymbol, Tausender-Trennzeichen, Dezimal-Trennzeichen, fett, farbig, etc.)

[Perlsau]

Zitat von Sir Rufo:

Zitat von 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.

Das sind dann ja auch immer noch rohe Daten, die für die Ausgabe noch formatiert werden müssen
(Währungssymbol, Tausender-Trennzeichen, Dezimal-Trennzeichen, fett, farbig, etc.)

Du hast ja recht: Das Ausführen von Aggregatfunktionen stellt ist streng genommen keine Formatierung, das Auffüllen eines Wertes z.B. mit Nullen dagegen in gewisser Weise schon. Daher lautet die philosophische Frage wohl, was Formatierung ist und was nicht. Handelt es sich um Formatierung, wenn ich aus verschiedenen Spalten – teilweise mit Foreign Key – eine Spalte für die Überschrift eines Serienbriefes generiere, wie z.B. "Sehr geehrter Herr Professor Thomas Wichtigheimer,"? oder für die Adresse

Code:

Adr.Vorname|| ' ' ||Adr.Nachname||ASCII_CHAR(13)||ASCII_CHAR(10)||Adr.Strasse|| ' ' ||Adr.HausNr

?

[Sir Rufo]

Antwort: Ja

Schon alleine deswegen, weil alleine der Zeilenumbruch #10#13 typisch für Windows ist

@p80286