[PHP] Aufruf einer Seite --> timestamp - sinnvoll?

Zitat von Seppo

nö nicht schlimm.. nur musst du dann eine php function benutzen die dir den sqlstamp in einen phpstamp umwandelt... function weiss ich jetzt leider nicht auswendig!

wollt dir nur sagen: sqlstamp <> phpstamp

Oder man hat die unwahrscheinliche Idee mal in der SQL-Doku nach Date/Time Functions zu suchen, welche das sowieso schon können - mySQL? http://dev.mysql.com/doc/mysql/en/d...-functions.html

Man hätte es sich übrigens leicht machen können und das Datum der letzten News als Datum der letzten Änderung nehmen können...

Zitat von grOOvekill@

Hehe, netter Versuch, aber ganz bin ich ja auch nicht auf der Nudlsuppn dahergschwommen, nänn? Es gibt ja neben den News auch noch die Möglichkeit Links, Termine, Gästebucheinträge und Fotos zu verwalten.

Code:

SELECT timestamp
  FROM Links
LEFT JOIN Termine USING(timestamp)
LEFT JOIN News USING(timestamp)
LEFT JOIN Fotos USING(timestamp)
ORDER BY timestamp DESC
LIMIT 1

Ok, performancemässig die Hölle - aber Ergebnis is das gleiche

(Wenn einer im Guestbook was schreibt is das ne Änderung der Seite? ne...)

Zitat von gue

Also DAS funktioniert nicht. Das ist ein klarer Fall für ein UNION, kein JOIN

ack. und dann kannst jeden SELECT bereits ORDERn und LIMITieren und das ganze geht wesentlich schneller.

aber das ist sowieso nur theoretisch, weils natürlich viel hübschere lösungen gibt

Zitat von gue

Also DAS funktioniert nicht. Das ist ein klarer Fall für ein UNION, kein JOIN

Wetten?

Aber stimmt, an UNION hatte ich nicht gedacht - Hey, dann gehts sogar halbwegs performant (Obwohl ein UNION sortieren imho auch nicht wirklich von performance gesegnet ist Aber zumindest der Temptable is' kleiner, und schneller als ein 4-Fach Join is es auf jeden Fall *g*)

@Groove...:
Ja, das ist natürlich klar - es hat aber imho keinen Sinn sich in Admin-Funktionen zu hacken und in jede von diesen, wenn du stattdessen durch eine sinnvolle Datenstruktur eben dieses bewirken kannst, was auch gleichzeitig viel weniger Programmier- und Wartungsaufwand bedeutet.

Zitat von grOOvekill@

Hab' auch gar keine Ambitionen, da tiefer in die Materie einzudringen, zumal ich sie ja wirklich nur für banale Websitegschichten brauche. Und da hab' ich eh schon einiges, was ich immer wieder verwende. Performancemäßig mache ich mir auch keine allzu großen Sorgen, da ich meistens nur ein paar Tabellen habe.

Wenig Tabellen heisst nicht unbedingt gute Performance - tatsächlich würde es sich bei gleichem Projektumfang u.U. genau andersrum verhalten (natürlich mit sinnvollem Design), wenn man dadurch (zB. bei myISAM) statt einer FIXED Format Table eine DYNAMIC Format hat, was vor allem bei Seeks extrem lahm wird dann.
Ähnliches bei den Indezes, welche bei mehr Tables natürlich pro Table kleiner werden.
Bei der Datenmenge, weil ich durch die feinere Selektion weniger Daten habe.

Natürlich alles bei einem sinnvollen Design... Witzig ist halt - es gibt für einen Anwendungsfall normal eigentlich nur EIN sinnvolles Design, alles andere ist dann eben nicht mehr sinnvoll, weil es langsamer ist, mehr Platz braucht oder was auch immer