Letzten Eintrag eines Users anzeigen

[hpvw]

1) Die Diskussion kannst du ja wohl kaum als Argument für die Vorteile von Datetime verwenden - denn sie kam zu keinem Ergebnis!

War auch nicht so gedacht. Aber man kann den Usern doch auch Lesestoff geben, um eine Entscheidung zu treffen.

2) Das Umformatieren wie du es beschriebe hast, is ja wohl ein wenig umständlich und in PHP wesentlich einfacher zu realisieren.

Da ich mir nicht sicher bin, welches umformatieren Du meinst, antworte ich mal zu allen drei Dingen, die ich geschrieben habe:

Mein erster Code dient dazu, bei der vorhandenen Datenstruktur im Query den entsprechenden Eintrag zu finden, den Moondancer haben will, da sehe ich keine (sinnvolle) Lösung mit PHP.

Der Weg, den ich zum Tabelle umstellen beschrieben habe, lässt sich im Prinzip auch verwenden, um das Feld in ein INT, welches einen Unix-Timestamp speichert, zu verwandeln. Es ist halt noch eine weitere (oder evtl. einfach eine andere) Funktion nötig. Wenn bereits Daten drin stehen, führt kein Weg, um so eine "Umformatierung" herum, wenn man die Tabelle in eine sinnvollere Struktur bringen will.

Ob man den dritten Code auf ein INT- oder auf ein DATETIME-Feld anwendet (bei INT natürlich in abgewandelter Form) oder die Formatierung des INT anschließend in PHP macht, kann man selbst anhand der angeführten Diskussion entscheiden.

Aber da ich hier anscheinend immer wieder auf SQL-Puristen ...

Ich nehme das mal als Kompliment

... treffe, erwarte ich gar keine "freundliche" Antwort

Vielleicht keine freundliche und keine, die Dir zustimmt, aber ich hoffe doch, Du siehst meine Antwort wenigstens als sachlich an.

Gerade, wenn es ums Sortieren und "Filtern" geht, halte ich es für sinnvoll, dieses im SQL-Query und nicht in PHP zu machen. Dazu ist das Datum, wie es derzeit gespeichert ist, nur bedingt geeignet. Eine Umstellung auf einen (Unix-)Timestamp oder ein DATETIME-Feld (IMHO besser geeignet ) halte ich daher für sinnvoll.

Gruß hpvw

 

[moondancer]

wow, danke für die vielen Antworten. Also die Variante mit DATETIME kommt mir schon sehr entgegen. Denn ich möchte letztendlich die Kalenderwoche mit auslesen und das geht ja wohl bei DATETIME, wenn ich richtig verstanden hab. Somit spare ich mir die Implementierung in PHP - macht sich bei derzeit 15.000 Einträgen sicher bemerkbar. Ein ID-Feld gibt es übrigens wirklich nicht..

Vielleicht sollte ich mal genauer spezifizieren, welche Operationen geplant sind - evtl. gibt es ja eine Lösung komplett in SQL...
Also die genaue Struktur der Tabelle sieht so aus:
Datum | Region_ID | User_ID | Preis1 | Preis2 | Preis3
Für jeden Tag und jede Region gibt es genau einen Eintrag. An Wochenenden keine Einträge.

Was ist geplant? Es soll für jede Kalenderwoche die Durchschnittspreise je Region ermittelt werden und in einer extra Tabelle abgelegt werden.
Es gibt ja die AVG-Funktion in SQL... Was meint Ihr, kann man das in einer SQL-Query unterbringen oder doch lieber PHP?

Viele Grüße
Christian

 

[hpvw]

Ich würde für Durchschnittspreise keine eigene Tabelle anlegen. Das entspräche einer redundanten Datenhaltung, welche in normalisierten Datenbanken nicht gewünscht ist.
Als Faustregel kann man sagen, dass Daten, die aus bestehenden Daten berechnet werden können nicht in der Datenbank gespeichert werden sollten.

Ich habe die Tabelle mal Preise genannt und angenommen, dass es eine Tabelle Region mit einem Attribut Name gibt. Datum müsste in diesem Fall vom Typ DATE oder DATETIME sein.

SELECT 
YEARWEEK(Preise.Datum,1) AS woche, 
Region.Name as Region, 
CONCAT(
  'Region ',
  Region.Name,
  ' (',
  Preise.Region_ID,
  ') in der Woche' ,
  YEARWEEK(Preise.Datum,1)
) as Gruppenbildung,
AVG(Preis1) as Durchschnittspreis1,
AVG(Preis2) as Durchschnittspreis2,
AVG(Preis3) as Durchschnittspreis3
FROM
Preise JOIN Region ON (Region.ID=Preise.Region_ID)
GROUP BY Gruppenbildung
ORDER BY Region, woche DESC
(Alternativ: ORDER BY woche DESC, Region)

Mit der User_ID weiss ich jetzt nicht viel anzufangen, aber ich denke, dass sie bei einer Durchschnittsbestimmung nicht relevant ist. Da ich mir gerade nicht sicher bin, ob man nach 2 Feldern gruppieren kann, habe ich das künstliche Feld Gruppenbildung eingeführt und es so formatiert, dass man es auch ausgeben könnte. Mit einem passenden Trennzeichen ließe sich das sicher performanter gestalten.
Außerdem soll das nur als Anregung dienen, da ich mir keine solche Datenbank aufsetze, um es zu testen. Es können also Fehler drin sein. Ggf. müsstest Du eine konkrete Fehlermeldung posten, damit ich mir das nochmal anschauen kann.

Gruß hpvw

 

[shutdown]

Das müsste grundsätzlich auch mit purem SQL möglich sein

Mit PHP ist es halt einfacher einen Workaround zu schreiben, wenn deine Befehle nicht so ganz tun was sie sollen ;-)

Die Kalenderwoche kannst du dir mit der date()-Funktion von PHP aus einem Timestamp problemlos erstellen lassen.


Was planst du denn überhaupt später mit den ermittelten Daten zu machen

Wenn du sie sowieso über ne Homepage ausgeben willst, dann würde ich empfehlen, gleich alles in PHP zu machen

Ich würde zum Beispiel in Abhängigkeit von der zu bearbeitenden Kalenderwoche (wird über das Skript festgelegt) ein Select erstellen (in PHP) und mit diesem die zugehörigen Daten ermitteln.

Die Durchschnittswerte kannst du entweder gleich in das SQL -Statement einbauen, oder du nutzt PHP (Werte durch mysql_affected_rows() sollte den Durchschnitt ergeben)

Was dann rauskommt kannst du dann gleich über ein Insert in deine Durchschnittstabelle schreiben.

cu shutdown

 

[moondancer]

vielen Dank das sieht sehr gut aus - werde es morgen mal testen und dann das Ergebnis posten.
Es ist so, dass die Preisdaten für die letzten 3 Tage in einer Tabelle auf der Homepage ausgegeben werden. Danach sind nur noch die Wochendurchschnitte relevant. Aus diesen sollen Diagramme erstellt werden. Die Tagespreise der Vergangenheit werden dann gelöscht - deshalb die zweite Tabelle...

Viele Grüße
Christian