Berechnungen schon bei select durchführen?

[Markus]

Hallo,
bin ein Anfänger mit MySQL und habe folgendes Problem.
Habe eine Datenbank mit mehreren Tabellen (Überraschung...)
In Tabelle1 habe ich Kollegen gespeichert mit Kol_ID als primary key, in Tabelle2 habe ich die verschiedenen Umsätze/Verkäufe gespeichert (UM_ID primary key, Kol_ID als secondary key - sag ich jetzt mal, auch wenn MySQL dies nicht wirklich unterstützt....).
Ich möchte jetzt eine Abfrage starten, die mir den jeweiligen Kollegen wiedergibt mit der GESAMTSUMME seiner Umsätze.
Frage ist - kann ich diese Berechnung der Gesamtsumme schon in der Abfrage durchführen (wenn ja WIE ?????), oder muß ich erst abfragen und dann die einzelnen Werte addieren lassen?
Das ganze soll als Ranking geführt werden, sprich die Ausgabe dann sortiert nach der höhe der Gesamtsumme.
Kol_Standort
Kol_Vorname Kol_Nachname
Gesamt: (Summe UM_Betrag)

So sollte das dann aussehen.
Wäre dankbar wenn mir jemand helfen könnte, oder mich zumindest auf den Richtigen Pfad lenkt.

Grüße,
Markus

[Björn Höhrmann]

Habe eine Datenbank mit mehreren Tabellen (Überraschung...)
In Tabelle1 habe ich Kollegen gespeichert mit Kol_ID als primary key, in Tabelle2 habe ich die verschiedenen Umsätze/Verkäufe gespeichert (UM_ID primary key, Kol_ID als secondary key - sag ich jetzt mal, auch wenn MySQL dies nicht wirklich unterstützt....).
Ich möchte jetzt eine Abfrage starten, die mir den jeweiligen Kollegen wiedergibt mit der GESAMTSUMME seiner Umsätze.

SELECT Kollege, sum(Umsatz) as GESAMTSUMME FROM ... GROUP BY Kollege

Frage ist - kann ich diese Berechnung der Gesamtsumme schon in der Abfrage durchführen (wenn ja WIE ?????), oder muß ich erst abfragen und dann die einzelnen Werte addieren lassen?

s.o.

Das ganze soll als Ranking geführt werden, sprich die Ausgabe dann sortiert nach der höhe der Gesamtsumme.
Kol_Standort
Kol_Vorname Kol_Nachname
Gesamt: (Summe UM_Betrag)

ORDER BY ...

Ich schlage ein gutes Buch oder das Handbuch von Mqysql vor, dort wird SQL behandelt.

[Markus]

Dir natürlich auch ein rechtherzliches Danke Schön für die schnelle Antwort- echt klasse wie schnell Ihr Anfängern helfen könnt.

Ich schlage ein gutes Buch oder das Handbuch von Mqysql vor, dort wird SQL behandelt.

Bin für Vorschläge offen - wenn Du ein Buch kennst, daß "Normalsterblichen" auf verstädnliche Weise weiterhilft wäre ich dankbar für den Tip - ich bin zu MySql gekommen wie die Jungfrau zum Kinde - und muß mich da jetzt durcharbeiten.

Grüße,
Markus

[Björn Höhrmann]

Ich schlage ein gutes Buch oder das Handbuch von Mqysql vor, dort wird SQL behandelt.

Bin für Vorschläge offen - wenn Du ein Buch kennst, daß "Normalsterblichen" auf verstädnliche Weise weiterhilft wäre ich dankbar für den Tip - ich bin zu MySql gekommen wie die Jungfrau zum Kinde - und muß mich da jetzt durcharbeiten.

http://mysql-faq.sourceforge.net/

[Michael Schröpl]

Hi,

Kol_ID als secondary key - sag ich jetzt mal, auch
wenn MySQL dies nicht wirklich unterstützt....).

was meinst Du damit?

Deine Tabelle in mySQL kann beliebig viele Indexe haben

• Du mußt sie nur explizit anlegen (während der
  Primärschlüsselindex implizit erzeugt wird).

Und daß ein Primärschlüssel auch über mehrere Spalten
gehen kann (auch in mySQL), weißt Du natürlich?

Viele Grüße
      Michael

[Markus]

Hi,

Kol_ID als secondary key - sag ich jetzt mal, auch
wenn MySQL dies nicht wirklich unterstützt....).

was meinst Du damit?

Deine Tabelle in mySQL kann beliebig viele Indexe haben

• Du mußt sie nur explizit anlegen (während der
  Primärschlüsselindex implizit erzeugt wird).

Oops, war wohl ein Tipfehler, meinte nicht secondary key sondern foreign key -
Natürlich kann meine Tabelle beliebig viele "Indexe" haben, die ich auch als foreign key definieren kann, nur wird die Integrität nicht sichergestellt - und von MySql auch bisher nicht als foreign key akzeptiert. Aber das soll sich ja angeblich bald ändern.

Grüße,
Markus

Und daß ein Primärschlüssel auch über mehrere Spalten
gehen kann (auch in mySQL), weißt Du natürlich?

Viele Grüße
      Michael

[Frank]

Hi,

zu deinem Problem.

Das Geheimnis lautet Aggregatfunktion, davon gibt es mehrere wie z.b. GROUP, Count, Sum, Min, Max etc

Du brauchst an dieser Stelle Sum(table.field)

der Vollständigkeit hier mal ein beispiel SQL:
SELECT
       Arbeiter_Umsaetze.ArbeiterID, *
       Sum(Arbeiter_Umsaetze.Umsatz) as made_sales,
       Arbeiter.Name
FROM
       Arbeiter_Umsaetze,
       Arbeiter
WHERE
       Arbeiter_Umsaetze.ArbeiterID=Arbeiter.ID
GROUP By
       Arbeiter_Umsaetze.ArbeiterID, *
       Arbeiter.Name
ORDER BY
       Arbeiter_Umsaetze.ArbeiterID

du fragst zwei Tabellen mit einmal ab und baust anhand der Felder ID und ArbeiterID eine Gemeinsamkeit auf  (das ganze geht auch mit einem Join-Statement siehe SQL-Dokumentation)
einen Ausgabewert (made_sales) definierst du als Summe von Feldern der entsprechenden Tabelle
wichtig ist noch, verwendest du für einen Ausgabewert eine Aggregatfunktion, mußt du auch für alle anderen eine Aggregatfunktion (im standardfall im Group by) einsetzen, sonst bekommst du einen Fehler.
die mit hash markierten Zeilen können (beide zugleich) auch weggelassen werden, das hängt davon ab, ob du diesen Ausgabewert (ArbeiterID) brauchst.

Wenn du das beispiel auf deine Vorgaben übertragen erfolgreich kannst, weißt du etwas mehr.

HTH, Frank

[Markus]

Danke für die ausführliche Antwort!
Hat mir wirklich extrem weitergeholfen - auch im Verständnis wie eine Abfrage aufgebaut wird (habe vorher hauptsächlich mit select all gearbeitet - was natürlich nicht der Sinn der Sache ist).

Grüße,
Markus

[Frank]

Danke für die ausführliche Antwort!
Hat mir wirklich extrem weitergeholfen - auch im Verständnis wie eine Abfrage aufgebaut wird (habe vorher hauptsächlich mit select all gearbeitet - was natürlich nicht der Sinn der Sache ist).

Grüße,
Markus

Hi,

ja, schön.

Suche mal nach dem Stichwort "Data Shaping" unter msdn.microsoft.com

damit bietet sich noch eine ganz neue Welt an Möglichkeiten Recordsets zu erzeugen, gleichzeitig Berechnungen zu vollführen und trotzdem mit denen R/W arbeiten zu können.

Nur mal so als Anregung.

Tschau, Frank