Suche Datenbank "Paten-Onkel"

Werbung:
Raeven schrieb:
So manch geantwortete Syntax hat mir erstmal Kringel in den Augen beschert, aber das ließ sich dann dank der Manuals (zumindest teilweise) aufdröseln und hat sehr weiter geholfen,
Zum Vergrößern anklicken....

Möcht dazu anmerken, daß PG halt sehr viel mehr kann als stupides Select/Insert/Update. Es ist eben deutlich mehr als eine 'dumme Blackbox', wenn man mal die Features gesehen hat merkt man das mit der Zeit. Die Doku ist zwar erstklassig, aber eher als Nachschlagewerk. Insofern versteh ich das auch, was Du sagst: das sind oft Dinge, die man ganz und gar nicht erwartet - so mit den vielen Datentypen, Constraints, Indexen und so. Mit der Zeit bekommt man aber einen Überblick. Ich kann nur empfehlen, die Doku ab und an mal querzulesen, und vielleicht das, was man grad 'neu gelernt' hat da im Detail zu lesen. Das lohnt sich!

PG ist halt schon etwas länger mein Hobby - so seit ca. 15 Jahren. Da hat man sogar Bugs gefunden - und diese reportet und gesehen, daß diese teilweise innerhalb 1-2 Stunden bestätigt und gefixt waren. Auch das zeichnet PG aus: eine super, einmalig gute Community.

Ich sehe mein wirken hier auch als Dank an die Community.
 
Grumpf..... ich will doch nur eine Zusammenfassung der Nährwerte pro Tag, bzw. über einen bestimmten Zeitraum.
Alles anzeigen geht ganz gut mittels:

Code: 
CREATE VIEW fv_buy_tag AS
    SELECT date, name, f_buy.qty, f_buy.unit,
    (f_nut.kcal*f_buy.qty/100)::numeric(4) AS cal,
    (f_nut.prot*f_buy.qty/100)::numeric(8,1) AS prot,
    (f_nut.carb*f_buy.qty/100)::numeric(8,1) AS carb,
    (f_nut.fat*f_buy.qty/100)::numeric(8,1) AS fat
    FROM f_buy INNER JOIN f_nut ON (f_buy.item = f_nut.name)
    --GROUP BY f_buy.date
    ORDER BY f_buy.date, f_buy.item;

Wenn ich nun anfange und zB das ausommentierte GROUP BY verwenden will, dann legt der sich mit allem möglichen auf die Nase, bis ich letztlich überall appregat funktionen drin habe. Dann mault er ncht mehr, aber ich habe überall nur noch sum/count ergebnisse von "1" zusätzlich drin.
Wo liegt da mein prinzipieller Fehler ?
BTW, "f" steht für food, "nut" für nutrition, "buy" für den getätigten Einkauf.
 
Ja, logisch aber auch, oder?

Wenn Du nach f_buy.date gruppierst, dann kann pro Gruppem hier also diesem Feld, nur ein Wert angezeigt werden. Was ist, wenn es mehrere gab? MySQL würde diesen logischen Fehler übersehen und Dir irgend einen Wert anzeigen, PG merkt den Fehler und nörgelt.

Also, alle Spalten des Resultates müssen ENTWEDER gruppiert (group by) ODER aggregiert (min(), max(), avg(), ... ) werden. Entwas in dieser Art steht auch in der Fehlermeldung, stimmts?
 
akretschmer schrieb:
Also, alle Spalten des Resultates müssen ENTWEDER gruppiert (group by) ODER aggregiert (min(), max(), avg(), ... ) werden. Entwas in dieser Art steht auch in der Fehlermeldung, stimmts?
Zum Vergrößern anklicken....

Und welchen Weg muss ich da gehen, wenn ich quasi als Report die Tage gelistet haben will?
Also unter jedem Tag - oder hier erstmal abschliessend - will ich ja die Nährtstoff aggregiert sehen.
 
Binmir nicht ganz sicher, Dich richtig verstanden zu haben, aber angenommen, Du hast:

Code: 
test=*# select * from verkauf;
 user_id |  datum  | menge
---------+------------+-------
  1 | 2015-01-01 |  10
  1 | 2015-01-01 |  12
  1 | 2015-01-05 |  13
  2 | 2015-01-03 |  22
(4 rows)

Und willst für die Tage 1. - 9.1 je user_id die Summe aus Menge haben:

Code: 
test=*# with tage as (select '2015-01-01'::date + s * '1day'::interval as datum from generate_Series(0,9) s) select tage.datum, verkauf.user_id, sum(verkauf.menge) from tage left join verkauf using (datum) group by datum, user_id;
  datum  | user_id | sum
---------------------+---------+-----
 2015-01-01 00:00:00 |  1 |  22
 2015-01-08 00:00:00 |  |
 2015-01-03 00:00:00 |  2 |  22
 2015-01-06 00:00:00 |  |
 2015-01-02 00:00:00 |  |
 2015-01-10 00:00:00 |  |
 2015-01-07 00:00:00 |  |
 2015-01-04 00:00:00 |  |
 2015-01-09 00:00:00 |  |
 2015-01-05 00:00:00 |  1 |  13
(10 rows)
 
Ne da geht's um die Nährstoffe, um die Tagesrationen im Endeffekt dann über die 6 Wochen des Projektes hinweg pro Nase zu ermitteln. Hier soll nun erstmal der Einkauf erfasst werden.
Bisher führt das mit obigem zu so einer Ausgabe wie unten gezeigt.
Ziel ist die Nährstoffe gemäß Einkauf pro Tag zu erfassen, bzw. jetzt erstmal Bericht-artig zu zeigen.


Code: 
    date    |          name          | qty  | unit | cal  |  prot  | carb  |  fat
------------+------------------------+------+------+------+--------+-------+-------
2015-07-27 | Champignons braun      |  400 | gr   |  252 |   10.8 |   2.0 |   0.8
2015-07-27 | Frühlingszwiebeln      |  630 | gr   |  265 |    5.7 |  53.6 |   1.9
2015-07-27 | Haselnüsse mit Schale  | 1600 | gr   | 5312 |  131.2 |  48.0 | 507.2
2015-07-27 | Knoblauch              |  198 | gr   |    0 |    0.0 |   0.0 |   0.0
2015-07-27 | Pastinaken             |  200 | gr   |  128 |    2.6 |  24.2 |   0.8
2015-07-27 | Petersilienwurzel      |  500 | gr   |  195 |   14.0 |  30.5 |   2.5
2015-07-27 | Pfifferlinge           |  400 | gr   |   44 |    6.4 |   0.8 |   2.0
2015-07-27 | Rehbock                | 8000 | gr   | 8400 | 1816.0 |   0.0 | 168.0
2015-07-27 | Scharlotten            |  500 | gr   |  210 |    4.5 |  42.5 |   1.5
2015-07-28 | Rehbock                | 8000 | gr   | 8400 | 1816.0 |   0.0 | 168.0
2015-07-29 | Äpfel                  | 3000 | gr   | 1620 |    9.0 | 342.0 |   3.0
2015-07-29 | Blaubeeren             | 1100 | gr   |  462 |    6.6 |  83.6 |   6.6
2015-07-29 | Brombeeren             |  375 | gr   |  161 |    4.5 |  23.3 |   3.8
2015-07-29 | Champignons braun      | 1000 | gr   |  630 |   27.0 |   5.0 |   2.0
2015-07-29 | Eier                   | 1320 | gr   | 1808 |  157.1 |  19.8 | 122.8
2015-07-29 | Haselnüsse ohne Schale |  800 | gr   | 5312 |  130.4 |  48.0 | 506.4
2015-07-29 | Himbeeren              |  250 | gr   |  108 |    3.3 |  12.0 |   0.8
2015-07-29 | Johannisbeeren         |  500 | gr   |  165 |    5.5 |  24.0 |   1.0
(18 rows)
 
Übrigens steck da oben schon ein bißchen (laienhafter) Hirnschmalz dahinter.
In der Einkaufsliste stehen nämlich auch Mengen wie "Bund", "Stück" oder ähnliches und die werden per Funktion aus einer Tabelle in Gewichte umgerechnet. Ähnlich werden die Nährstoffe ergänzt, die ich in einer Tabelle fußend auf 100gr Mengen gelistet habe.

Würde es denn Sinn machen, wenn ich das in eine ggf. temporäre Tabelle überführe?
Würde PG das ganze dann hardcoded in der Tabelle speichern, oder würden dort dann die Links - gemäß Abfrage - gespeichert ?
 
Raeven schrieb:
Ziel ist die Nährstoffe gemäß Einkauf pro Tag zu erfassen,
Zum Vergrößern anklicken....

select date, sum(...) from ... group by date

Wenn Du die Summe der cal pro Tag haben willst, z.B. für den 27, dann muß Du ja 252 + 265 + ... + 210 rechnen. In der Summe ist nicht mehr erkennbar, welchen Anteil da die Pilze, Zwiebeln, ... und so weiter haben. Es ist eine Summer über alles. Also dann die unwichtigen Spalten einfach weglassen.
 
COOL! :)
Fehler von mir: ich hatte geglaubt, weil ich für die joins auf gelistete felder zurück gegriffen hatte, müsse ich die auch beim select mit angeben. Ich doof!

Jetzt muss ich nur noch die Gesamtsumme drunter zaubern....

Code: 
    date    |  cal  |  prot  | carb  |  fat 
------------+-------+--------+-------+-------
2015-07-27 | 14806 | 1991.2 | 201.6 | 684.7
2015-07-28 |  8400 | 1816.0 |   0.0 | 168.0
2015-07-29 | 10266 |  343.4 | 557.7 | 646.4
 
Freu-Freu..... jetzt fragt mir eine Funktion einzelne Tage ab, also quasi Zeilen aus dem Listing oben, und liefert diese als RETURNS TABLE zurück --- macht diese Vorgehensweise Sinn?

Da ich da Funktions-intern eine Unterscheidung machen, so dass man sowohl ein Einzeldatum abrufen kann, wie auch eine range? Oder bin ich da gezwungen eine zweite Funktion für range zu erzeugen, die dann ggf mehrfach die Funktion mit einzelnen Termin aufruft?
 
Werbung:
Zurück
Oben