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

Seite 2 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/php_aufruf_einer_seite_gt_timestamp_sinnvoll_146541/page_2 - zur Vollversion wechseln!

Seppo schrieb am 27.07.2005 um 12:52

Zitat von grOOvekill@
Genauso mach' ich das!
Sehr schlimm?

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

watchout schrieb am 27.07.2005 um 13:21

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...

grOOvekill@ schrieb am 27.07.2005 um 14:00

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

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.

watchout schrieb am 28.07.2005 um 00:06

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...)

gue schrieb am 28.07.2005 um 07:48

Zitat von watchout
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...)

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

rettich schrieb am 28.07.2005 um 08:18

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

grOOvekill@ schrieb am 28.07.2005 um 09:07

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

Nein, ist es nicht, da hast Du vollkommen Recht. Die Gästebuchverwaltung beinhaltet die Möglichkeit, auf einen Eintrag zu antworten. Aus meiner Sicht wäre das durchaus ein Hinweis darauf, dass sich an der Website etwas getan hat. Könnte man natürlich auch weglassen. Es geht ja nur darum, das aktuelle Datum zu zeigen, wenn anhand Adminseiten Content auf der Website modifiziert/hinzugefügt wird.

watchout schrieb am 28.07.2005 um 10:52

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.

grOOvekill@ schrieb am 28.07.2005 um 11:30

Zitat von watchout
@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.

Ach, was wäre ich froh, wenn ich das, was sie mir in der Abendschule über sinnvolle Datenstrukturen versucht haben beizubringen, noch wüßte!

Nein, Datenbanken sind für mich ein Buch mit sieben Siegeln, ehrlich. 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.

Bin ja schon froh, dass ich mehr oder weniger selber auf die Lösung des Problems gekommen bin.

Selbstverständlich weiß ich dennoch Eure Hilfe hier zu schätzen.

watchout schrieb am 28.07.2005 um 11:53

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