SQL - Mittelwert vs gleitender Durchschnitt [Archiv]

Mr. Lolman

2020-05-14, 14:34:47

Liebe Leute, ich steh am Schlauch.

Den gleitenden Durchschnittseinkaufspreis eines Produkts kann man ja ganz einfach wie folgt berechnen

Neuer Durchschnittseinkaufspreis = ( (alter Lagerstand * alter Durchschnittseinkaufspreis) + (Einkaufsmenge * Einkaufspreis) / (alter Lagerstand + Einkaufsmenge)

Ich würde das gerne ohne eigener Function, Stored Procedure oder einer Hilfstabelle hinbekommen. Das Problem ist das die Spalte für den Durchschnittspreis durchs Query erzeugt wird und ich nicht weiß, wie ich im Query auf den Inhalt der vorigen Zeile in der eigenen Spalte referenzieren kann.

So sollte das am Ende aussehen (Berechnung der Spalte AVG):

Lagerstand Einkaufsmenge Preis AVG

2 2 1 1.00
5 3 2 1.60
7 2 1 1.43
9 2 1 1.33
11 2 1 1.27
13 2 1 1.23

Trap

2020-05-14, 15:05:41

Bisher habe ich das konkrete Problem nicht umgesetzt, ich vermute aber, dass windows functions dabei hilfreich sein könnten:
https://www.postgresqltutorial.com/postgresql-window-function/

Matrix316

2020-05-14, 15:35:28

Hast du ein Datum zu wann die Zeile jeweils berechnet werden soll? Oder wo kommen die Werte eigentlich her?

Soll jede Zeile in der Abfrage neu berechnet werden, oder stehen die Werte schon in einer Tabelle und du willst nur die aktuelle wissen?

Wenn du ein Datum (oder eine Zeilennummer/ID) hast, könnteste ja auf den alten Durchschnittspreis einfach mit einem subselect auf die Zeile davor zugreifen, where top 1 Datum < aktuellem datum order by datum desc oder so.

Mr. Lolman

2020-05-14, 15:42:46

Ja, ich hab schon eine Möglichkeit direkt die Zeilen über ID oder Datum zu referenzieren. Die Werte sollten nach Möglichkeit live berechnet werden, da der Beobachtungszeitraum für den Durchschnittswert variabel ist. Ich hab dazu mittlerweile auch schon folgendes gefunden (und eigentlich ists ein Wahnsinn, wenn man bedenkt, wie die zugrundeliegende Formel zur Berechnung aussieht):

https://stackoverflow.com/questions/51593603/sql-calculate-cumulative-average-cost-price-for-a-product

Matrix316

2020-05-14, 15:57:38

In Excel geht das glaube ich einfacher. :D Für manche Sachen ist SQL auch nicht immer das ideale... Vielleicht helfen dann doch Funktionen die du aufrufst statt das komplette select in einem Aufwisch zu machen.

konkretor

2020-05-14, 19:31:58

https://www.techonthenet.com/oracle/functions/avg.php

https://riptutorial.com/de/sql-server/example/11017/zentrierter-gleitender-durchschnitt

Hilft dir das ?

Trap

2020-05-14, 19:48:31

Window functions sind nützlich:
https://www.db-fiddle.com/f/sEcHBujzhjpfC5qCmov1WK/0

Mr. Lolman

2020-05-15, 09:09:05

Window functions sind nützlich:
https://www.db-fiddle.com/f/sEcHBujzhjpfC5qCmov1WK/0

Vielen Dank, das hilft schon mal für den Anfang. Das Problem an meinem Beispiel war, dass keine Abgänge berücksichtigt werden.
Wenn beispielsweise in der vorletzten Zeile der Lagerstand nur mehr 1 Stück beträgt, ändert sich der Durchschnittspreis der letzten Zeile auf 1.09

(1*1,27) + (2*1) / (1+2)

Lagerstand Einkaufsmenge Preis AVG

2 2 1 1.00
5 3 2 1.60
7 2 1 1.43
9 2 1 1.33
1 2 1 1.27
3 2 1 1.09

Asaraki

2020-05-15, 10:17:22

Ich steh auf dem Schlauch, helfe aber gerne weiter (ist ja mein Lieblingsthema)

Wo ist der alte Einkaufspreis? oO

Ach ich Depp.. das ist pro "Artikel" quasi schon? Ich Depp dachte wir reden von einem Realbeispiel, dann würde die Tabelle ja bestimmt nicht so aussehen :D

Dein Problem würde ich persönlich mit einer rekursiven Funktion lösen, so hast du das Problem mit dem "previous row" nicht mehr. Schlussendlich brauchst du ja nur ein Resultat aus den ganzen Daten, oder?

Mr. Lolman

2020-05-15, 12:05:01

Hm, das muss doch auch irgendwie ohne rekursiven Aufruf und weniger komplex als im Beispiel von Stackoverflow funktionieren.:redface:

Asaraki

2020-05-15, 12:09:46

Hm, das muss doch auch irgendwie ohne rekursiven Aufruf und weniger komplex als im Beispiel von Stackoverflow funktionieren.:redface:

Nope ^ ^ Deine Aufgabe ist Komplex, also auch die Lösung. Du willst ja eine Lösung, die alle möglichen Konstellationen korrekt abhandelt. Wenn du nur 98% richtig brauchst wird's deutlich einfacher :D

Wir haben grad ordentlich zu tun @work aber ich helf dir gern dabei, das rekursiv zu schreiben. Einmal verstanden ist das gar nicht so komplex, aber beim ersten Mal musste es mir mein Kollege auch mehrmals erklären :D

Mr. Lolman

2020-05-15, 12:47:51

Ja bitte, das Angebot nehm ich gerne an. Ich würds wohl auch irgendwie selbst hinbekommen, aber wozu das Rad immer wieder neu erfinden ;)

Asaraki

2020-05-15, 13:43:09

Ja bitte, das Angebot nehm ich gerne an. Ich würds wohl auch irgendwie selbst hinbekommen, aber wozu das Rad immer wieder neu erfinden ;)

Gerne :) Wir haben grad Weekend-Work verordnet, bin also bisschen knapp an Zeit manchmal :D

Damit wir das schnell haben, ich brauch von dir zwei Dinge :
a) den "menschlichen" Denkweg - also wie würdest du das Problem ohne Zuhilfenahme technischer Mittel lösen / rechnen

b) Wenn easy : Die Daten und die erwarteten Ergebnisse, dann kann ich das quick&dirty schnell gegenlaufen lassen :) Ich mach da gerne Fehler, weil ich ein enorm chaotischer Mensch bin - wäre also super wenn ich von dir die "richtigen" Resultate hätte xD Asa ist ein sehr dummer intelligenter Mensch musst du wissen...

Zur Erklärung :
Ich kann's natürlich auch ohne, aber du wirst mehr lernen wenn du mir a) auch lieferst, dann kann ich dir kurz erklären wie du von a) zum SQL kommst :) Mach(t)e ich immer mit den Entwicklern, die kein tiefes SQL Verständnis haben. Wenn sie das Problem nicht in "einfacher Sprache" erklären können, dann hab ich das nochmal zurück geschickt, denn die Chance, dass ich was anderes mache, als sie meinten, ist zu gross - und eben der Lerneffekt ist grösser. Ich will denen das ja nur einmal erklären ^^

P.S: Falls du des Englischen mächtig bist, hier wird der tricky part gut erklärt
http://www.silota.com/docs/recipes/sql-recursive-cte-exponential-moving-average.html

1. Rekursives SQL besteht aus einem rekursiven und einem nicht-rekursiven Part (der sorgt dafür, dass das nicht endlos läuft)) - hilft enorm wenn du glaubst das verstanden zu haben ^^
2. Wir brauchen die Rownumber, damit wir wissen womit wir arbeiten

Row_num gibt es afaik in allen DBMS. Ich bin ja in DB/2 zuhause, aber bisher liess sich alles mehr oder weniger übertragen.
Ist generell eine Funktion die viele Leute nicht kennen (und es dir erlauben würde, das Problem auch ohne Rekursion, aber mit viel mehr SQL, zu lösen) und enorm wichtig für fast alle komplexeren Queries, gerade im Bereich der Data Analysis (welche ich zwar nicht mache, aber meine Schwägerin ^^)

Sobald mir die Arbeit zum Hals raushängt lös ich das schnell für dich.... mein Zückerli heute ^^

Edit : link vergessen...

P.S: Einfach weil's ein SQL Thread ist und weiter oben von "window functions" geredet wird.
DBMR-übergreifend nennet man diese "Common Table Expression", in DB2 gerne "WITH-clause"... aber sind alles am Ende des Tages CTEs.
Daher immer von CTE reden, dann versteht das jeder DBA jedes DB-Systems.

Nur für die, die es interessiert.

Mr. Lolman

2020-05-15, 14:46:27

ad a) Der menschliche Weg ist folgende Rechnung:

( (alter Lagerstand * alter Durchschnittseinkaufspreis) + (Einkaufsmenge * Einkaufspreis) / (alter Lagerstand + Einkaufsmenge)

ad b) Für das Beispiel 1 ist das für die letzte Zeile folgende Rechnung: (1*1,27) + (2*1) / (1+2) = 1.09:

Beispiel 1

Lagerstand Einkaufsmenge Preis AVG

2 2 1 1.00
5 3 2 1.60
7 2 1 1.43
9 2 1 1.33
1 2 1 1.27
3 2 1 1.09

Das erwartete Ergebnis wär der im Beispiel pro Zeile (im Excel ;-)) berechnete AVG Wert.

Die Echtdaten sind noch ein bisschen komplexer weils unterschiedliche Buchungstypen gibt, d.h. zwischen den Eingangsbuchungen auch Ausgangs und Korrekturbuchungen zu finden sind und der damalige Lagerstand nicht hinterlegt ist*:

Rownum Ein/Ausgang Menge Preis AVG

1 E 2 1 1.00
2 E 3 2 1.60
3 E 2 1 1.43
4 E 2 1 1.33
5 E 2 1 1.27
6 A 10 1.5 1.27**
7 E 2 1 1.09

*die aber fürs Beispiel insgesamt egal sind, da sich der gleitende Durchschnittswert ja nur bei Wareneingängen aktualisiert werden muss. Bloß der beim Eingang aktuelle Lagerstand ist wichtig, aber der ist ja eh schon im Beispiel 1 hinterelgt.
** Beispiel 2 entspricht somit Beispiel 1 nur dass in Rownum 6 eine Buchungszeile mit dem Ausgang zu finden sind (mit 1.5 als Verkaufspreis), die für Berechnung des AVG irrelevant ist sondern nur den insgesamten Lagerstand von 11 auf 1 reduziert. Der vom letzten Einkauf berechnete AVG Wert wird einfach für alle darauffolgenden Verkäufe übernommen. (Das ist aber für mich SQL-technisch kein Problem, da ich mir schon mit Decode(Ein/Ausgang, 1, 0) und SUM-over-Funktionen Gruppierungen erzeugt hab)

PS: Es handelt sich um eine Oracle DB. X-D
PPS: Thx, auch für den Link.

EDIT: Ich hab, falls es hilft, nun auch schon etwas aufbereitete Testdaten aus unserer DB hochgeladen. Der Durchschnittswert ganz rechts wurde für jeden Eingang (E) im Excel berechnet und für die Darauffolgenden Zeilen kopiert. Wie man sieht, kann es auch negative Lagerstände geben - was natürlich den Durchschnittswert beinflusst. Ich hatte -3 auf Lager kauf 15 Stück um 11,85 ein und hab dann für meine 12 Stück im Schnitt 14,81€ bezahlt X-D. Aber das (und diverse andere Sonderfälle auch), würd ich schon selbst abfangen ... bei Oracle gibts dafür ja zB GREATEST(Lagerstand, 0))

Asaraki

2020-05-15, 16:02:58

Hooooi

Also, bin noch nicht durch, aber hab dir hier etwas, das man eh können sollte (Ist ein Teilschritt)

https://www.db-fiddle.com/f/sEcHBujzhjpfC5qCmov1WK/2
(ohne Row1 zur besseren Verständlichkeit)
Das verknüpft über einen simplen Join jede Row mit ihrem Vorgänger. So hast du nun auf jeder Row auch die Daten, die du zum rechnen brauchst. Kannst also jetzt mit sehr simplen Mitteln damit arbeiten. Das ist der Hauptteil der Basisdaten für das noch folgende rekursive Query.
Du siehst, du kannst mit diesen Resultaten jetzt deinen menschlichen Weg gehen.

Du hast übrigens genau den gewohnten kleinen "Fehler" gemacht :
Die Rechnung stimmt zwar, aber die ist ja nur auf eine Zeile anwendbar. Was fehlt ist quasi das, was du als Mensch ganz automatisch machst, nämlich das verbinden der Zeilen.
Du würdest ja vermutlich von Hand :
Zeile 1 Rechnen, gewisse Werte mit 1/0/statischem Wert nehmen
Zeile 2 rechnen mit dem Resultat von 1
Zeile 3 rechnen mit dem Resultat von 2
Zeile 4 rechnen ....

Und genau DAS ist ja der Teil, bei dem du Mühe hattest mit dem SQL :-) Hoffe das ist verständlich, bin bisschen im Schuss ^^

https://www.db-fiddle.com/f/mHqRWjX71Zby6yYmghaquQ/1

Das ist jetzt schon rekursiv, aber da fehlt noch die Berechnung selbst. Muss jetzt aber kurz was arbeiten, vielleicht schaffst du den letzten Schritt sogar selbst, sonst liefere ich noch, kein Ding :-)

https://www.db-fiddle.com/f/mHqRWjX71Zby6yYmghaquQ/5

äh... ich glaub das passt, nur rundet es die werte auf ganze stellen :D fuck ich raff grad nicht wieso oO aber so rein theoretisch könnte es stimmen.
kann sein, dass ich in der rechnung den aktuellen und vorgänger row vertauscht habe evt.

ord lager kauf preis preisavg
1 2 2 1 1
2 5 3 2 2
3 7 2 1 1
4 9 2 1 1
5 11 2 1 1

disclaimer, die werte für lager werden nicht gerechnet, müssten aber theoretisch ja auch einfach row-1.lager + row-1.kauf sein, ne?
jetzt stimmen die werte natürlich nicht, aber das liegt an den grunddaten ^^

ah fuck ich hab nicht mehr gespeichert... der link führt noch zu einer falschen version =/ aber jetzt muss ich mal pause machen, sorry

littlejam

2020-05-17, 21:14:27

Asaraki

2020-05-19, 12:13:09

Mal blöd gefragt...
warum speicherst du denn nicht das moving average pro Zeile und bei einem neuen Eintrag brauchst du nur die letzte Zeile ziehen und das in die Neue einarbeiten bzw. meinetwegen auch nachträglich berechnen.
Wenns mal durcheinander geht kannst du ja immer noch einen kompletten Run laufen lassen und alle avgs aktualisieren.
Rekursiv bei jedem Abruf das berechnen geht bei 100 Einträgen, bei 1M oder mehr dauerts ja ewig.

Edit:
Ist eigentlich eine DWH/Controlling Geschichte und eher nicht in der "echten" DB.

Grüße

Aloha allerseits, sorry war im Stress... respektive bin's immer noch =/ corona hat uns ganz schön gefickt @ work ^^

Aber zur Frage oben : Ne, also ganz ehrlich würd ich das nie auf die Tabelle packen, wenn überhaut in eine MQT (materialized query table, quasi eine "refreshable dynamic table based on an sql) oder sowas. D.h. so kannst du verhindern, dass das query ausgeführt wird obwohl sich die daten nicht geändert haben :-)

Ein kleines rekursives SQL mit simplem arithmetischen Operationen kann locker ein paar 100k Rows in nicht-spürbarer-Zeit verarbeiten btw, das ist überhaupt kein Problem. Ein richtiges DBMS lacht sich tot unterhalb von ~10-20m rows, vorausgesetzt das physische, logische design und der zugriff wurde nich von laien gemacht :)

aus reinem interesse, inwiefern arbeitest du mit DBs?

Mr. Lolman

2020-05-19, 13:32:03

Ein kleines rekursives SQL mit simplem arithmetischen Operationen kann locker ein paar 100k Rows in nicht-spürbarer-Zeit verarbeiten btw, das ist überhaupt kein Problem. Ein richtiges DBMS lacht sich tot unterhalb von ~10-20m rows, vorausgesetzt das physische, logische design und der zugriff wurde nich von laien gemacht :)

Das denk ich mir nämlich auch... :wink:

littlejam

2020-05-19, 20:22:03

Aber zur Frage oben : Ne, also ganz ehrlich würd ich das nie auf die Tabelle packen, wenn überhaut in eine MQT (materialized query table, quasi eine "refreshable dynamic table based on an sql) oder sowas. D.h. so kannst du verhindern, dass das query ausgeführt wird obwohl sich die daten nicht geändert haben :-)

Letzteres entspricht ja dem was ich meinte. Die Daten einmal berechnen und drauf zugreifen.
Mein einfacher Geist hätte das an die Tabelle gepappt oder meinetwegen daneben wenns Teil vom Businessprozess ist.
Wenns Teil vom Controlling ist dann inkrementell alle X Zeit nachladen und evtl. noch einen Vollimport dazubauen.

Rekursiv bei jedem Aufruf durch alle Zeilen gehen um einen Wert zu bekommen ist ein totales Antipattern.

Ein kleines rekursives SQL mit simplem arithmetischen Operationen kann locker ein paar 100k Rows in nicht-spürbarer-Zeit verarbeiten btw, das ist überhaupt kein Problem. Ein richtiges DBMS lacht sich tot unterhalb von ~10-20m rows, vorausgesetzt das physische, logische design und der zugriff wurde nich von laien gemacht :)
Das denk ich mir nämlich auch... :wink:
20m rows - am schlimmsten exponentiell vervielfacht - zu lesen um einen einzigen Wert zu berechnen findet ihr nicht bescheuert?
Dass das das Caching und das Working Set der DB kaputt macht stört auch nicht?
So eine Query ist üblicherweise nicht isoliert zu betrachten ;(

aus reinem interesse, inwiefern arbeitest du mit DBs?
Beruflich, vor ein paar Jahren mit Größeren, aktuell eher kleiner mit ein paar Mio Daten - MySQL... oder verschiedene noSQL-DB.
Ach... und ein Buch zum Thema hab ich auch gelesen.

Grüße

Asaraki

2020-05-19, 20:47:15

Letzteres entspricht ja dem was ich meinte. Die Daten einmal berechnen und drauf zugreifen.
Mein einfacher Geist hätte das an die Tabelle gepappt oder meinetwegen daneben wenns Teil vom Businessprozess ist.
Wenns Teil vom Controlling ist dann inkrementell alle X Zeit nachladen und evtl. noch einen Vollimport dazubauen.

Rekursiv bei jedem Aufruf durch alle Zeilen gehen um einen Wert zu bekommen ist ein totales Antipattern.

20m rows - am schlimmsten exponentiell vervielfacht - zu lesen um einen einzigen Wert zu berechnen findet ihr nicht bescheuert?
Dass das das Caching und das Working Set der DB kaputt macht stört auch nicht?
So eine Query ist üblicherweise nicht isoliert zu betrachten ;(

Beruflich, vor ein paar Jahren mit Größeren, aktuell eher kleiner mit ein paar Mio Daten - MySQL... oder verschiedene noSQL-DB.
Ach... und ein Buch zum Thema hab ich auch gelesen.

Grüße

Ah du machst das viel zu kompliziert. Erst mal geht es darum, wie man das berechnet. Ob du das als das jetzt semi-permanent oder ad-hoc machst kommt dann später. Man darf nicht vergessen, es gibt einen wichtigen Unterschied zwischen Enterprise und Business. Bei einer normal grossen Firma läuft da irgendwo ein Rechner, der sowieso Zeit hat. Da wird nichts teurer oder langsamer nur weil einer "sinnlos" Ressourcen verbraucht, solange wir da von paar CPU Sekunden oder Minuten im Monat reden... oder bei vielen Systemen sogar in der Stunde ^^

Und bei Tabellen mit <10k Rows pro Produkt (mal vorstellen, 10'000 Bestellungen eines einzelnen Artikels innerhalb der Housekeeping Zeit) sind wir hier in Regionen wo das alles keine Rolle spielt. Solange das Design passt lüppt das auch.

Ja ich find high performance auch geil und ich liebe Tabellen mit >1k Partitionen und 1000 concurrent threads drauf.... aber das allerallerallerallerwichtigste im DB Leben ist immer das Verhältnis nie zu verlieren, sonst wirst einer von denen, die dann allen erzählen was man noch alles tun könnte, dabei hast du während des Erklärens schon mehr gekostet als deine Optimierung je bringt ^^

Matrix316

2020-05-20, 11:32:39

Asaraki

2020-05-20, 12:15:49

Ich denke es kommt auch drauf an, wer das Ergebnis braucht. Solche komplizierten Abfragen in SQL zu bauen ist IMO irgendwie zu umständlich - gerade wenn später eventuell jemand das eh in Excel lädt. Dann soll er die Basis Laden und sich die Funktion selbst bauen um die Werte rekursiv zu berechnen. Was in SQL eine komplizierte Abfrage ist, ist in Excel nur ein "klick ins andere Feld wo die Formel schon steht" und alles wird automatisch eingetragen.

Boink - dass Excel im Hintergrund basically eine DB ist, ist dir schon klar, oder? Du willst jetzt nicht ernsthaft jemandem verklickern, dass eine vordefinierte Funktion weniger Arbeit ist, als die Funktion zu schreiben?

Dann kann ich ja bei jeder zukünftigen SQL Frage einfach auf das passende SAP Modul verweisen :D

Matrix316

2020-05-20, 13:41:35

Boink - dass Excel im Hintergrund basically eine DB ist, ist dir schon klar, oder? Du willst jetzt nicht ernsthaft jemandem verklickern, dass eine vordefinierte Funktion weniger Arbeit ist, als die Funktion zu schreiben?

Dann kann ich ja bei jeder zukünftigen SQL Frage einfach auf das passende SAP Modul verweisen :D

Jedes Werkzeug für seinen Zweck. ;)

Manches geht in Excel einfach einfacher als in SQL. Zum Beispiel Pivot oder Funktionen zu referenzieren die eine Zeile oben drüber stehen und so. Dafür kann ich in SQL einen "S Verweis" viel einfacher machen als in Excel. ;)

Asaraki

2020-05-20, 13:57:43

Jedes Werkzeug für seinen Zweck. ;)

Manches geht in Excel einfach einfacher als in SQL. Zum Beispiel Pivot oder Funktionen zu referenzieren die eine Zeile oben drüber stehen und so. Dafür kann ich in SQL einen "S Verweis" viel einfacher machen als in Excel. ;)

SQL ist eine Sprache, Excel ein Programm. Äpfel und Birnen much?

Das ist wie "Nimm nicht den Hammer, stell einen Hilfsarbeiter an" zu raten... und dann kann der Typ später immer noch nicht mit einem Hammer umgehen.

Er hat eine SQL Frage gestellt und du kommst mit "Nimm doch Excel" :D Nicht "falsch", aber auch nicht "richtig".

Ich bin halt lieber der, der zu fischen lernt, statt sich bei jedem Hüngerchen einen Fisch zu kaufen.

Mr. Lolman

2020-05-20, 15:52:53

So ist es. Es geht mir mal auch primär um den Proof of Concept. Wahrscheinlich wirds später ohnehin übers DBMS implementiert (oder evtl. als materialized view?)

Matrix316

2020-05-20, 16:02:59

SQL ist eine Sprache, Excel ein Programm. Äpfel und Birnen much?

Das ist wie "Nimm nicht den Hammer, stell einen Hilfsarbeiter an" zu raten... und dann kann der Typ später immer noch nicht mit einem Hammer umgehen.

Er hat eine SQL Frage gestellt und du kommst mit "Nimm doch Excel" :D Nicht "falsch", aber auch nicht "richtig".

Ich bin halt lieber der, der zu fischen lernt, statt sich bei jedem Hüngerchen einen Fisch zu kaufen.

Kein Mensch würde heute fischen lernen, wenn er im Supermarkt Fisch kaufen kann. =) Man muss sich ja das Leben nicht schwerer machen als es ist. ;)

Klar, kann man das in SQL alles machen, aber manchmal ist Excel einfach praktischer. Tabellen sind am Ende beides quasi. Oder Datenbanken.;)

Kommt halt auch drauf an, was man am Ende mit machen will. Will ich die Daten auf einer Webseite anzeigen lassen, wäre Excel etwas unpraktisch. Wenn irgendein Manager einen Report haben will, dann würde es mehr Sinn machen.

Rockhount

2020-05-23, 10:33:06

Asaraki

2020-05-23, 11:10:55

Kein Mensch würde heute fischen lernen, wenn er im Supermarkt Fisch kaufen kann. =) Man muss sich ja das Leben nicht schwerer machen als es ist. ;)

Klar, kann man das in SQL alles machen, aber manchmal ist Excel einfach praktischer. Tabellen sind am Ende beides quasi. Oder Datenbanken.;)

Kommt halt auch drauf an, was man am Ende mit machen will. Will ich die Daten auf einer Webseite anzeigen lassen, wäre Excel etwas unpraktisch. Wenn irgendein Manager einen Report haben will, dann würde es mehr Sinn machen.

Da sind wir wohl einfach verschieden. Ich mache alles schwerer als nötig, sofern das lernen oder üben einen bleibenden Effekt hat. Nicht nur in der Arbeit, auch privat gehe ich gerne den schweren und harten Weg, wenn am Ende eine Belohnung winkt (=etwas neu gelernt)

Und bisher hat sich das m.M.n. sehr gelohnt. Ich weiss ist OT, aber ich seh das so "Das Leben ist ein Game ohne Retry und ich hab kein Bock nicht das höchste für mich machbare Level zu erreichen in Sachen "Skills" :) Wenn du mir sagst, man könnte das auch einfacher machen (aber nicht ganz so gut), dann mach ich es erst recht einmal auf die schwierige Art :D

Ps : meine Freunde haben die letzten Sommer Fischen gelernt. ;-)

Matrix316

2020-05-24, 11:54:35

Wer Excel mit SQL vergleich und sagt, die Tabellen sind gleichwertig, hat irgendwas wohl nicht verstanden, oder ich bin auf dem Holzweg.

Es gibt für SQL klare Anwendungsgebiete, die Excel zwar abdecken könnte in Teilen, aber Excel sollte NIE Mittel der Wahl sein. Jedenfalls nicht, wenn man eine Datenbank zur Hand hat.
Am Ende steht das Ergebnis wieder nur in einem Excel Sheet zur Verfügung, müsste mittels Export dann in die DB gepusht werden und dieses Setup ist scheisse

Wie gesagt, kommt drauf an, wie man die Daten darstellen will.

Wenn ich ein Dashboard auf einer Webseite haben will, machts keinen Sinn die Daten in Excel aufzubereiten und dann wieder einzuspielen.

Will man eh nur immer in Excel präsentieren, dann braucht man die Enddaten nicht unbedingt im SQL Server speichern, sondern da reichen die Basics.

Da aber auch der Threadstarter am Anfang geschrieben hat

Ich würde das gerne ohne eigener Function, Stored Procedure oder einer Hilfstabelle hinbekommen

Ist das in SQL nicht ganz so trivial, denn für sowas bieten sich Funktionen oder Stored Procedures ja genau an. =)

Excel bietet halt den Vorteil in die Zellen Formeln zu hinterlegen.

Matrix316

2020-05-24, 11:57:44

Da sind wir wohl einfach verschieden. Ich mache alles schwerer als nötig, sofern das lernen oder üben einen bleibenden Effekt hat. Nicht nur in der Arbeit, auch privat gehe ich gerne den schweren und harten Weg, wenn am Ende eine Belohnung winkt (=etwas neu gelernt)

Und bisher hat sich das m.M.n. sehr gelohnt. Ich weiss ist OT, aber ich seh das so "Das Leben ist ein Game ohne Retry und ich hab kein Bock nicht das höchste für mich machbare Level zu erreichen in Sachen "Skills" :) Wenn du mir sagst, man könnte das auch einfacher machen (aber nicht ganz so gut), dann mach ich es erst recht einmal auf die schwierige Art :D

Ps : meine Freunde haben die letzten Sommer Fischen gelernt. ;-)

Wenn ich Lust auf Fisch habe, dann will ich den auch möglichst bald haben und nicht auf den Sommer warten um fischen zu lernen. :D

Im echten Leben steht halt der Chef hinten und ruft: Wir brauchen das bis morgen. Da kann man dann nicht drei Wochen Lang den komplizierten weg gehen, da muss man halt manchmal pragmatisch sein.

Rockhount

2020-05-24, 12:32:27

Wie gesagt, kommt drauf an, wie man die Daten darstellen will.

Wenn ich ein Dashboard auf einer Webseite haben will, machts keinen Sinn die Daten in Excel aufzubereiten und dann wieder einzuspielen.

Will man eh nur immer in Excel präsentieren, dann braucht man die Enddaten nicht unbedingt im SQL Server speichern, sondern da reichen die Basics.

Da aber auch der Threadstarter am Anfang geschrieben hat

Ist das in SQL nicht ganz so trivial, denn für sowas bieten sich Funktionen oder Stored Procedures ja genau an. =)

Excel bietet halt den Vorteil in die Zellen Formeln zu hinterlegen.

Das mag ja richtig sein, das Excel das anbietet.
Aber das rechtfertigt imo Excel nicht als Lösung.

Ich arbeite seit fast 10 Jahren im BI Analytics Bereich und habe LANGJÄHRIG genau den Mist mit Excel hinter mir, den Du hier als Lösung anpreist.
Und nein, es gab, gibt und wird imo auch nie einen tatsächlichen Sachverhalt geben, wo Excel die alleinige Lösung ist.

Alleine der Umstand, dass die Daten im Anschluss erstmal NUR in Excel bereitstehen, mit allen Fallstricken und Problemen (Verfügbarkeit, Validität, Sicherheit, etc pp), lässt Excel einfach ausfallen.

Es ist in nahezu ALLEN Fällen ratsamer, die entsprechenden Informationen (und hier ist der gleitende Durchschnitt imo schon eine Kerninformation, die nicht mal eben punktuell berechnet werden kann, im Einzelfall) in Datenbanken als Basis anzubieten. Darauf kann "jeder" zugreifen, es gibt einen single point of truth und Du kannst die Daten beliebig abfragen und weiterverarbeiten.

Und auch wenn der TE am liebsten ohne SP, functions temp tables etc auskommen will, so kann es manchmal eben sein, dass es nicht ohne geht.
Vielleicht hat er ja einen SQL Server? Da lässt sich das Ganze wunderbar einfach als Prozess im Scheduler abbilden mittels TSQL oder SSIS Packages...

Nur weil Excel "bequemer" ist, ist es nicht besser, es gibt eben wesentliche Nachteile. Daher sollte die Empfehlung eher lauten, in den sauren Apfel zu beissen als die minderwertigste Lösung zu wählen

Mr. Lolman

2020-05-25, 10:56:07

littlejam

2020-05-25, 17:00:53

Um das Thema ein bisschen voranzubringen:

Wir brauchen doch eigentlich nur einen Bezug zur vorigen Zeile. In Oracle kann man das mW ja mit CONNECT BY PRIOR machen: https://docs.oracle.com/cd/B19306_01/server.102/b14200/queries003.htm

Das sollte doch eigentlich reichen, oder?
Ist denn in der vorigen Zeile bereits der gleitende Durchschnitt bis dahin vorhanden und soll hier fortgeführt werden?
Das ist doch der Knackpunkt an der Sache.
Falls ja wäre das in MySQL so mittelelegant mit einem Subselect wahrscheinlich machbar, falls nein, musst du doch rekursiv bis zum Tabellenanfang, weil du für die Berechnung eben jenen Wert für alle Zeilen berechnen musst.

Grüße

Matrix316

2020-05-25, 18:31:09

Asaraki

2020-05-25, 18:57:03

Das mit dem Connect by Prior hätte ich gerne im MSSQL Server. ;)

Aber man könnte ein Select machen und das ähnliche Select für den einen Wert den man braucht in einer Skalarwertfunktion wo man den die aktuelle ID übergibt um die Zeile davor zu bekommen oder so. Quasi rekursiv. ;)

Auch hier : Wenn du verstehst, was Connect by Prior im Hintergrund macht, dann wüsstest du, dass es nur ein Self Join per Rownum-1 ist :) Solange man keine berechneten Ergebnisse fortführen muss geht das ohne Rekursion, sobald aus den Rows dynamische Werte generiert werden wird es zwangsläufig rekursiv.

Edit : stimmt vielleicht nicht wirklich, hab das connect by prior nur überflogen :-/ aber in sich stimmts ja, deshalb lass ich es mal stehen, aber bin vorsichtig ob das wirklich connect by prior ersetzt

MSSQL Connect by Prior via self join in prosa (verfügbar machen der rownumber => benutzen der rownumber für selfjoin auf den prevoius row)

with blub as(
select Personli,Managerli,Schuhgrössli,ROW_NUMBER() as elDiablo
from thoseDatas
)

select blibbel und blubbel
from blub blub_current
join blub blub_prev
on blub_prev.elDiablo = blub_current.elDiablo-1

--> where blub_current.Personli = blub_prev.Manager

was hier fehlt ist die union auf den ersten row, wenn nötig. und sonst halt keinen inner join benutzen. normalerweise sind diese rows aber uninteressant bei solchen operationen

soviel eben zum fischen und zum fisch aus dem supermarkt :D scnr :)

Ist denn in der vorigen Zeile bereits der gleitende Durchschnitt bis dahin vorhanden und soll hier fortgeführt werden?
Das ist doch der Knackpunkt an der Sache.
Falls ja wäre das in MySQL so mittelelegant mit einem Subselect wahrscheinlich machbar, falls nein, musst du doch rekursiv bis zum Tabellenanfang, weil du für die Berechnung eben jenen Wert für alle Zeilen berechnen musst.

Grüße

Ist eben nicht vorhanden, in diesem Beispiel.
Deshalb : Rekusion ist immer nötig (ob versteckt oder nicht ^^) um dynamische Werte zu erzeugen und innerhalb des gleichen Queries auch zu verwenden.

lumines

2020-05-25, 19:08:07

Klar, kann man das in SQL alles machen, aber manchmal ist Excel einfach praktischer. Tabellen sind am Ende beides quasi. Oder Datenbanken.;)

Kommt halt auch drauf an, was man am Ende mit machen will. Will ich die Daten auf einer Webseite anzeigen lassen, wäre Excel etwas unpraktisch. Wenn irgendein Manager einen Report haben will, dann würde es mehr Sinn machen.

Wenn es wirklich schnell gehen muss, hämmere ich kurz ein paar Tabs zwischen ein paar Daten und pipe es in eine Textdatei. Awk erledigt den Rest. Damit habe ich einen Report erstellt, bevor Excel überhaupt gestartet ist.

Ansonsten gibt es auch noch dataset: https://dataset.readthedocs.io/en/latest/

Reports lassen sich übrigens auch sehr einfach aus SQLite heraus generieren. Ehrlich gesagt finde ich SQLite auch insgesamt sehr viel angenehmer als Excel. Mit irgendeiner dynamisch typisierten Programmiersprache sollte es auch nicht weniger produktiv sein.

Ansonsten gibt es auch noch haufenweise Key-Value-Stores, wenn die Daten nicht zu komplex sind.

littlejam

2020-05-25, 20:02:44

Ist eben nicht vorhanden, in diesem Beispiel.
Deshalb : Rekusion ist immer nötig (ob versteckt oder nicht ^^) um dynamische Werte zu erzeugen und innerhalb des gleichen Queries auch zu verwenden.
Kann man so oder so lesen.
Lolmans Startposting sagt nur, dass er Schwierigkeiten hat auf die Vorgängerzeile zuzugreifen, nicht dass "Avg" als Spalte nicht vorhanden ist.
Ebenso in seinem letzten von mir zitierten Post.
Hier mal ein Fiddle mit avg als Spalte.
https://www.db-fiddle.com/f/gq1z2R8SXeEjZcptQrC5zj/3
Wie angedroht nicht wirklich hübsch, aber funktional und stabil auch bei 1mio Rows.

Dabei ist mir aufgefallen, dass der Bestand ab 9 auf 1 geht.
Nicht Sicher ob Schreibfehler oder Absicht.
Müsste man bei Absicht halt noch einbasteln :biggrin:

Wenn es wirklich schnell gehen muss, hämmere ich kurz ein paar Tabs zwischen ein paar Daten und pipe es in eine Textdatei. Awk erledigt den Rest. Damit habe ich einen Report erstellt, bevor Excel überhaupt gestartet ist.
Awk plättet sowieso alles!
:D

Grüße

Matrix316

2020-05-25, 21:08:10

Wenn es wirklich schnell gehen muss, hämmere ich kurz ein paar Tabs zwischen ein paar Daten und pipe es in eine Textdatei. Awk erledigt den Rest. Damit habe ich einen Report erstellt, bevor Excel überhaupt gestartet ist.

Ansonsten gibt es auch noch dataset: https://dataset.readthedocs.io/en/latest/

Reports lassen sich übrigens auch sehr einfach aus SQLite heraus generieren. Ehrlich gesagt finde ich SQLite auch insgesamt sehr viel angenehmer als Excel. Mit irgendeiner dynamisch typisierten Programmiersprache sollte es auch nicht weniger produktiv sein.

Ansonsten gibt es auch noch haufenweise Key-Value-Stores, wenn die Daten nicht zu komplex sind.

Wie in deinem Link schon steht: programmers are lazy

:D

Deswegen lass doch die Manager die Arbeit in Excel machen und konzentrier dich auf die Bereitstellung der Basis über SQL. ;D

Dass es Möglichkeiten des Reportings über den SQL Server mit SSIS Paketen etc. PP gibt, muss man mir nicht erklären. ;) Aber auch bei uns gab es schon Anforderungen Reports die man im SQL Server einfach nicht machen konnte. z.B. Bunte Exceltapeten mit verschachtelten Überschriften etc. pp.. =)

lumines

2020-05-26, 08:02:34

Deswegen lass doch die Manager die Arbeit in Excel machen und konzentrier dich auf die Bereitstellung der Basis über SQL. ;D

Ich habe auch nie behauptet, dass es ein entweder-oder ist. Ich würde nur niemals Excel als Pseudo-Datenformat verwenden.

Ich betrachte einfach Daten in Excel als flüchtig und nicht wohldefiniert, was sie ja auch praktisch sind. Daraus ergibt sich dann der Rest.

Dass es Möglichkeiten des Reportings über den SQL Server mit SSIS Paketen etc. PP gibt, muss man mir nicht erklären. ;)

Na ja, wenn die Reports selbst relativ simpel sind, exportiere ich einfach zu CSV. Wenn es wirklich ein Report im Sinne eines Textdokuments sein soll, dann kann man ja noch immer eine der vielen Template-Engines mit LaTeX kombinieren und an die Datenbank koppeln.

Aber auch bei uns gab es schon Anforderungen Reports die man im SQL Server einfach nicht machen konnte. z.B. Bunte Exceltapeten mit verschachtelten Überschriften etc. pp.. =)

Ein Vorteil von SQLite: Wenn solche "Anforderungen" zu viel werden, Rage Quitte ich einfach und sende die Datenbank per Mail.

Matrix316

2020-05-26, 11:16:08

Eine 8 GB Datenbank per Mail schicken, ist bei uns etwas umständlich. ;)

lumines

2020-05-26, 11:40:16

Eine 8 GB Datenbank per Mail schicken, ist bei uns etwas umständlich. ;)

Das dürfte genau so für eine 8-GB-Excel-Datei gelten.

Matrix316

2020-05-26, 13:11:34

Das stimmt, wobei der Excel Report etwas weniger groß war, als die gesamte Datenbank. Aber 10 MB war die Datei schon glaub ich. Die Daten kamen aber auch mehreren Tabellen oder so.

Klar ist Excel flüchtig, aber wenn dein SQL Server abraucht, dann ist der auch weg, wenns kein Backup gibt. Genauso wie bei Excel. ;)

Asaraki

2020-05-26, 13:50:28

Was laberst du da :D

Matrix316

2020-05-26, 14:25:22

War nur eine Anspielung hier drauf:

[...]
Ich betrachte einfach Daten in Excel als flüchtig und nicht wohldefiniert, was sie ja auch praktisch sind. Daraus ergibt sich dann der Rest.
[...]

Alle Computerdateien sind flüchtig. Ist der Strom weg, sind die Dateien weg (zumindest bis der Strom wieder da ist). ;)

Asaraki

2020-05-26, 14:28:15

War nur eine Anspielung hier drauf:

Alle Computerdateien sind flüchtig. Ist der Strom weg, sind die Dateien weg (zumindest bis der Strom wieder da ist). ;)

Du hast nicht verstanden, was er mit flüchtig meint.... aber is ok ^^ Ist eh ne sinnlose Diskussion Excel mit einem DBMS vergleichen zu wollen ^^

Matrix316

2020-05-26, 15:04:14

Du hast nicht verstanden, was er mit flüchtig meint.... aber is ok ^^ Ist eh ne sinnlose Diskussion Excel mit einem DBMS vergleichen zu wollen ^^
Ich kenne flüchtig nur in Verbindung mit RAM/Speicher und nicht mit Dateien.

Naja, Excel ist quasi wie ein DataSet. Es gibt Tabellen und Zeilen. Nur erweitert mit Formeln und Skripten. Aber eine Tabelle ist eine Tabelle, ob jetzt in einem SQL Server oder in einer Excel Datei oder in einem DataSet im Programm. Der Zugriff erfolgt halt anders jeweils etwas

Asaraki

2020-05-26, 15:21:05

Ich kenne flüchtig nur in Verbindung mit RAM/Speicher und nicht mit Dateien.

Naja, Excel ist quasi wie ein DataSet. Es gibt Tabellen und Zeilen. Nur erweitert mit Formeln und Skripten. Aber eine Tabelle ist eine Tabelle, ob jetzt in einem SQL Server oder in einer Excel Datei oder in einem DataSet im Programm. Der Zugriff erfolgt halt anders jeweils etwas

Excel ist ein Programm. In diesem Sinne ist dein Excel bei mir der "Client + MW + LB + RDBMS + SMS". Einzig das OS ist für beide fast Blackbox.

Ich wette mit dir, ich mach dir innert Sekunden jedes Excel beyond recovery kaputt, aber wenn du bei mir absichtlich auch nur einen einzigen Pagefault hinkriegst, dann schenk ich dir ne Flasche guten Wein. Das ist mühsamer als man meint, wenn man zur Vorbereitung des DR Tests explizit "hard page failures" erzeugen muss, ohne mit dem Schraubenzieher an die SSD zu gehen.. die SSDs...

Matrix316

2020-05-26, 15:40:22

Excel ist ein Programm. In diesem Sinne ist dein Excel bei mir der "Client + MW + LB + RDBMS + SMS". Einzig das OS ist für beide fast Blackbox.

Ich wette mit dir, ich mach dir innert Sekunden jedes Excel beyond recovery kaputt, aber wenn du bei mir absichtlich auch nur einen einzigen Pagefault hinkriegst, dann schenk ich dir ne Flasche guten Wein. Das ist mühsamer als man meint, wenn man zur Vorbereitung des DR Tests explizit "hard page failures" erzeugen muss, ohne mit dem Schraubenzieher an die SSD zu gehen.. die SSDs...
Alles was am PC läuft ist ein Programm (auch wenns als Dienst läuft).

Und kaputt kriegen tut man alle Programme irgendwie.

Die Gefahr bei Excel ist halt größer, weil der User selbst mit der Datei arbeitet. Aber die Manager können halt schlecht ihre bunten Kuchendiagramme in einem sql select direkt abbilden. Da braucht man halt ein Programm daneben, was einem aus den Zahlen die bunten Bildchen macht. ;)

Asaraki

2020-05-26, 15:41:42

Alles was am PC läuft ist ein Programm (auch wenns als Dienst läuft).

Und kaputt kriegen tut man alle Programme irgendwie.

Die Gefahr bei Excel ist halt größer, weil der User selbst mit der Datei arbeitet. Aber die Manager können halt schlecht ihre bunten Kuchendiagramme in einem sql select direkt abbilden. Da braucht man halt ein Programm daneben, was einem aus den Zahlen die bunten Bildchen macht. ;)

Oh boi... ja ich geb dann mal auf ^^ you win...

lumines

2020-05-26, 16:57:10

Die Gefahr bei Excel ist halt größer, weil der User selbst mit der Datei arbeitet.

Das ist überhaupt nicht das Problem. Das große Problem ist eigentlich eher, dass Excel keine atomaren Transaktionen unterstützt und die Daten nicht nach einem Schema validieren kann.

Hast du schon einmal gesehen, wie einige Leute Excel-Dateien als Datenformat nutzen und per VBA dann weiter verarbeiten? Es geht auf Dauer immer schief. Ich kenne wortwörtlich keinen einzigen Fall, in dem das nicht zu (wohlgemerkt komplett vermeidbarem) Datenverlust geführt hätte.

Als Ausgabeformat für bestimmte Anwendungsfälle ist es wahrscheinlich in Ordnung. Ich kann ja verstehen, dass man die Daten irgendwie vielleicht für Präsentationen grafisch aufpeppen will und das nicht unbedingt die Person macht, welche sonst mit den Daten arbeitet. Als Datenformat sollte man es aber nie benutzen.

Und wie gesagt, am Ende gibt es auch noch SQLite. Es ist im Grunde in MS Access in seriös und mir ist nicht so ganz klar, warum man es nicht überall als direkten Ersatz benutzt.

Matrix316

2020-05-26, 17:27:28

Das ist überhaupt nicht das Problem. Das große Problem ist eigentlich eher, dass Excel keine atomaren Transaktionen unterstützt und die Daten nicht nach einem Schema validieren kann.

Hast du schon einmal gesehen, wie einige Leute Excel-Dateien als Datenformat nutzen und per VBA dann weiter verarbeiten? Es geht auf Dauer immer schief. Ich kenne wortwörtlich keinen einzigen Fall, in dem das nicht zu (wohlgemerkt komplett vermeidbarem) Datenverlust geführt hätte.

Als Ausgabeformat für bestimmte Anwendungsfälle ist es wahrscheinlich in Ordnung. Ich kann ja verstehen, dass man die Daten irgendwie vielleicht für Präsentationen grafisch aufpeppen will und das nicht unbedingt die Person macht, welche sonst mit den Daten arbeitet. Als Datenformat sollte man es aber nie benutzen.

Und wie gesagt, am Ende gibt es auch noch SQLite. Es ist im Grunde in MS Access in seriös und mir ist nicht so ganz klar, warum man es nicht überall als direkten Ersatz benutzt.

Sagen wir mal so: Ich arbeite seit ca. 14 Jahren mit Datenbanken und von SQLite habe ich bislang noch nie was gehört.

Außerdem arbeiten mit Excel und Access soweit ich das beobachte meistens Leute die a) von Datenbanken und b) von Programmieren keine Ahnung haben. ;) Und wenn ich mir die Seite von SQLite so ansehe, weiß ich warum solche Leute auch nicht damit arbeiten würden/könnten. ;)

Wobei als "Datenspeicher" sehe ich Excel auch nicht unbedingt. Die Daten sollen schon in der Datenbank liegen.

Aber die Auswertungen und Durchschnittsberechnungen und zusammenfassungen und Präsentationen und das sehe ich nicht unbedingt als Aufgabe eines SQL Servers an, sondern dafür gibt es ja die Ebene darüber quasi die "Business Logic", die den "Presentation Layer" füttert - um mal mit IT Angebersprache zu kommen. ;)

PS.: Bei Datenbanken bin ich zugegebenerweise aber auch ein Quereinsteiger.

Rooter

2020-05-26, 18:56:51

Als Datenformat sollte man es aber nie benutzen.Ui, dann würdest du bei uns aber im Strahl kotzen! Wir nutzen Excel für die komplette Bedarfsermittlung. Die Lagermengen, Absatzzahlen und existierenden Bestellungen kommen dabei aus SAP, mit einem eigenen Excel-Add-in als Schnittstelle. Darüber kann man auch Bestellungen in SAP generieren, verschieben usw.
Es geht und ist auch recht komfortabel, dennoch habe ich oft Angst, dass uns das alles um die Ohren fliegt... X-D

MfG
Rooter

lumines

2020-05-27, 19:52:56

Sagen wir mal so: Ich arbeite seit ca. 14 Jahren mit Datenbanken und von SQLite habe ich bislang noch nie was gehört.

SQLite arbeitet auch nicht nach einem Client-Server-Modell, was es für viele Anwendungsfälle in Unternehmen uninteressant macht, aber es ist eben die am meisten verwendete Datenbank überhaupt.

Wenn man alle Vorteile einer Datenbank will, aber ohne den Administrationsaufwand und Overhead eines Client-Server-Modells, gibt es eigentlich nicht viele Alternativen. Die Einstiegshürde ist enorm niedrig. Das CLI lässt sich einfach per sqlite3 <dateiname> "<query>" verwenden.

Außerdem arbeiten mit Excel und Access soweit ich das beobachte meistens Leute die a) von Datenbanken und b) von Programmieren keine Ahnung haben. ;) Und wenn ich mir die Seite von SQLite so ansehe, weiß ich warum solche Leute auch nicht damit arbeiten würden/könnten. ;)

Eigentlich haben relativ viele Business-Leute wenigstens rudimentäre SQL-Kenntnisse. Bei SQL denken nur die meisten Leute an dicke Serverinstanzen und halten das für zu viel Aufwand alles zu managen, aber das ist ja eigentlich Quatsch, weil das gar nicht zwingend notwendig ist. SQL selbst ist ja keine komplexe Sprache. Die meisten Leute scheuen nur die Administration einer Datenbank und nicht SQL selbst.

Wobei als "Datenspeicher" sehe ich Excel auch nicht unbedingt. Die Daten sollen schon in der Datenbank liegen.

Aber die Auswertungen und Durchschnittsberechnungen und zusammenfassungen und Präsentationen und das sehe ich nicht unbedingt als Aufgabe eines SQL Servers an, sondern dafür gibt es ja die Ebene darüber quasi die "Business Logic", die den "Presentation Layer" füttert - um mal mit IT Angebersprache zu kommen. ;)

Sollte so sein, aber am Ende werden dann doch immer noch Daten manuell eingefügt und separate Datenbestände in anderen Excel-Dateien gepflegt, die dann am Ende wieder gemerget werden.

Ui, dann würdest du bei uns aber im Strahl kotzen! Wir nutzen Excel für die komplette Bedarfsermittlung. Die Lagermengen, Absatzzahlen und existierenden Bestellungen kommen dabei aus SAP, mit einem eigenen Excel-Add-in als Schnittstelle.

Ich stecke da nicht so ganz drin und eventuell ist das sogar in Ordnung, wenn das alles extrem eingeschränkt passiert, weil man Excel vielleicht nur als eine Art Frontend für die Datenbank benutzt. Wobei ich mich dann frage, warum man aufwendig ein Excel-Add-In bereitstellt, wenn das am Ende alles (hoffentlich) nur CRUD-Operationen gegen die Datenbank sind. Für Copy & Paste braucht man ja eigentlich keine Excel-Integration und ob das die ganze Sache einfacher zu bedienen macht, würde ich auch eher anzweifeln.