Counter - braucht's das?
Verfasst: Sa 30. Nov 2002, 20:55Ich hatte mal nebenbei einen Counter gebastelt, wollte aber jetzt neue Wege damit gehen:
normalerweise speichern Skripte ein Datum als Timestamp in ein Integer-Datenbankfeld. Ich habe jetzt mein Skript so umgschrieben, dass es selbiges kann, aber ganz ohne Timestamps.
Grund:
- keine Verletzung der Datentyp- und Programmierlogik: ein Datum wird als Date gespeichert und nicht als Integer oder gar String (das mag vielen marginal erscheinen, aber ich bin nunmal Perfektionist...)
- Timestamps sind nicht zukunftsfähig: in etwa 10 Jahren müssten alle Integer-Felder auf BigInt umgestellt werden, 2037 geht gar nichts mehr... ein Datum vor 1970 ist ebenfalls nicht drin
- Verringerung der Abhängigkeiten in der Datenbank, kompaktere Speicherung (Monatsstatistiken)
Nachteile:
- Die Formatierungspatterns für SQL dürfte kaum einer kennen, im Gegensatz zur PHP-Funktion date()
- läuft ein Counter mind. 10 Jahre, so dass ein echter äusserlicher Vorteil dieses Systems spürbar wird?
- soll man auf's Prinzip scheissen und lieber einem (leichten) Vorteil in der Gegenwart nachgeben?
Will es auf meiner privaten Page zum Download und Ausprobieren anbieten, bin aber noch unschlüssig...
P.S.:
Benchmarking via microtime(): beide Versionen sind gleich flott/langsam
wer sich die Sourcen ansehen will:
http://www.mad-teaparty.com/Chrstph/uphpcounter2.zip
P.P.S.:
wäre es eurer Meinung nach eine gute Idee, auch für so kleine Skripte eine DB-Klasse bereitzustellen, welche man wiederum an andere Systeme wie die PHPLIB anstöpseln kann?
normalerweise speichern Skripte ein Datum als Timestamp in ein Integer-Datenbankfeld. Ich habe jetzt mein Skript so umgschrieben, dass es selbiges kann, aber ganz ohne Timestamps.
Grund:
- keine Verletzung der Datentyp- und Programmierlogik: ein Datum wird als Date gespeichert und nicht als Integer oder gar String (das mag vielen marginal erscheinen, aber ich bin nunmal Perfektionist...)
- Timestamps sind nicht zukunftsfähig: in etwa 10 Jahren müssten alle Integer-Felder auf BigInt umgestellt werden, 2037 geht gar nichts mehr... ein Datum vor 1970 ist ebenfalls nicht drin
- Verringerung der Abhängigkeiten in der Datenbank, kompaktere Speicherung (Monatsstatistiken)
Nachteile:
- Die Formatierungspatterns für SQL dürfte kaum einer kennen, im Gegensatz zur PHP-Funktion date()
- läuft ein Counter mind. 10 Jahre, so dass ein echter äusserlicher Vorteil dieses Systems spürbar wird?
- soll man auf's Prinzip scheissen und lieber einem (leichten) Vorteil in der Gegenwart nachgeben?
Will es auf meiner privaten Page zum Download und Ausprobieren anbieten, bin aber noch unschlüssig...
P.S.:
Benchmarking via microtime(): beide Versionen sind gleich flott/langsam
wer sich die Sourcen ansehen will:
http://www.mad-teaparty.com/Chrstph/uphpcounter2.zip
P.P.S.:
wäre es eurer Meinung nach eine gute Idee, auch für so kleine Skripte eine DB-Klasse bereitzustellen, welche man wiederum an andere Systeme wie die PHPLIB anstöpseln kann?