mehrere Spalten in Ergebnismenge

[Furtbichler]

Nun ja, es nützt etwas, wenn der Kunde oder wer auch immer die View anpassen kann, ohne die EXE ändern zu müssen, weil aus Sicht der EXE die View ja immer noch die gleichen Daten (von der Struktur her) liefert. Aber wenn Du natürlich mit deiner One Man Show keinen Bedarf an solchen Konzepten hast, dann bringt Dir das natürlich nichts. Ebensowenig scheinst Du Interesse an klaren Strukturen und Paradigmentrennung zu haben, was nicht weiter schlimm ist, da Du ja alleine arbeitest.

Und stell Dir mal vor, Du bietest deinen Kunden irgendwann doch mal einen Reportgenerator an und kannst dann -boah ey- auf eben diese View zurückgreifen, weil, verflixt, die etwas komplexere Query gerade nicht zur Hand ist. Und auch würde dann gelten: Wenn sich die Struktur der Datenbank ändert (bei Dir natürlich nicht, aber bei Amateuren kommt so etwas schon mal vor), dann kann man die Sicht auf die Daten (daher könnte der Name 'View' kommen) ändern, ohne -wie gesagt- die EXE'n, Report-Templates, EXCEL-Dateien, Web-Anwendungen usw. anfassen zu müssen. Das alles hast Du natürlich nicht: Du hast nur diese eine EXE und den Compiler immer dabei.

Aber das sind ja nur hypothetische Überlegungen, die für Profis deines Kalibers eh alle nicht zutreffen.

:stupid:

[Bummi]

Ich schließe mich meinem Vorredner inhaltlich an (ohne den persönlichen Aspekt).
Die Sicht kannst Du möglicherweise nicht ändern (ich weiß nicht ob Deine DB Functiontables kennt), aber Du kannst Sie so formulieren dass sie auch in Jahren noch gültig ist, indem Du das Jahr in die Ausgabe mit aufnimmst und bei der Summierung entsprechend berücksichtigst, wobei eine entsprechende Mitaufnahme von ID_ART in Deinem Fall auch Sinn machen sollte.

[mkinzler]

Zitat:

Inwiefern Summe ? Ich will ja die Monate einzeln.

Hast du ja in den Spalten. Aber du hast 12 DS.

Zitat:

Was nützt es mich, die EXE nicht ändern zu müssen, dafür aber die View bzw. die DB ? Oder andersrum gefragt : wie kann ich die View parametrisieren ?

Dann nimm statt einem View eine selectable SP

Zitat:

Ich kann ja wohl schlecht am 1.1.2013 eine neue View anlegen, weil es dann auch Daten für 2013 gibt.

Der View liefert dir einen DS Pro Jahr unt Artikel. Also entweder datumsabhängiger Zeitraum in den View einbauen und zu SP ( mit Parameter) umbauen.

Zitat:

Zitat von Furtbichler

btw. geht nicht auch

SQL-Code:

select sum(iif(monat = 1, umsatz, 9 )) as Januar,
 ...

?
Warum 9

[dunningkruger]

Zitat:

Zitat von mkinzler (Beitrag 1194284)

Nennt man Pivot

[OT]
Diese "Pivot-Tabellen" (von Excel?) habe ich noch NIE kapiert :oops::evil:

Echt dumm und naiv gefragt:

Ist das, was Hansa in #1 als Code: gepostet hat, tatsächlich ein Beispiel für das Ergebnis einer Pivot-Tabelle?
[/OT]

Danke für's Mitlesen!

[DeddyH]

Hier ist ein ganz netter Artikel zu Pivot (mit T-SQL, aber egal): http://www.itrain.de/knowhow/sql/tsql/pivot/pivot.asp
Nicht vergessen, ganz bis unten zu lesen und den weiterführenden Link anzuklicken ;)

[Furtbichler]

Zitat:

Zitat von mkinzler (Beitrag 1194337)

Zitat:

Zitat von Furtbichler

btw. geht nicht auch

SQL-Code:

select sum(iif(monat = 1, umsatz, 9 )) as Januar,
 ...

?
Warum 9

Weiss ich auch nicht (sollte eine 0 sein). Ich meinte, man könnte das subselect wegkürzen. Hab kein FB zum testen, aber es sollte doch einfacher gehen, oder?

Zitat:

Zitat von Bummi (Beitrag 1194332)

Ich schließe mich meinem Vorredner inhaltlich an (ohne den persönlichen Aspekt).

Sehr schön ausgedrückt das ich mir das hätte sparen können. Hast ja Recht.:oops:

[Hansa]

Zitat:

Zitat von Furtbichler (Beitrag 1194330)

Aber das sind ja nur hypothetische Überlegungen, die für Profis deines Kalibers eh alle nicht zutreffen.

:stupid:

Stimmt, ja. So was kann allerdings nur ein Dummschwätzer sagen, der am grünen Tisch sitzt und sich theoretische Überlegungen Jenseits der Praxis ausdenkt :mrgreen:

Allgemein gültig muss es jedoch sein. Werde den View wohl in SP umbauen. Und @furtbichler: ich könnte auch die betreffende Tabellen umbauen. :stupid:

[mkinzler]

Zitat:

Weiss ich auch nicht (sollte eine 0 sein). Ich meinte, man könnte das subselect wegkürzen. Hab kein FB zum testen, aber es sollte doch einfacher gehen, oder?

Er hat die Aggegatsfunktion hier nicht wollen, deshalb habe ich es mit der Derived Table implementiert.

[Furtbichler]

Moin,
das lese ich zwar nicht heraus, aber offensichtlich würde es auch einfacher gehen (dein Beispiel ist dafür aber sehr verständlich).

[Hansa]

Zitat:

Zitat von Furtbichler (Beitrag 1194330)

Aber das sind ja nur hypothetische Überlegungen, die für Profis deines Kalibers eh alle nicht zutreffen.

Haha, Nach der Überheblichkeit kommt meist der tiefe Fall oder zumindest die Erleuchtung. :shock: :mrgreen: Siehe hier :

Zitat:

Zitat von Furtbichler (Beitrag 1194345)

Weiss ich auch nicht (sollte eine 0 sein). Ich meinte, man könnte das subselect wegkürzen. Hab kein FB zum testen, aber es sollte doch einfacher gehen, oder?

Wenn ich das so im nachhinein lese :

Es geht mit einem Wort mehr in meinem SQl in Beitrag #5. Das wars. Kein Subselect, kein View, kein IIF (obwohl bei mir das CASE wohl die selbe Wirkung hat). Jedenfalls reichen 15 Zeilen als normales SQL Statement grundsätzlich aus. Habe da dann noch ein paar Parameter eingebaut und die where-Bedingung verfeinert und fertig. Ist auch bereits in Delphi teilweise eingebaut bzw. umgesetzt.

Ausdrücklicher Dank geht an mkinzler und DeddyH. :thumb: