Datenbankstruktur

[strauberry]

Hallo zusammen,

bin momentan an der DB-Struktur für ein projekt dran und habe die Wahl zwischen zwei Lösungswegen... kann mich aber nicht entscheiden

Es wird ein timereporting -> Ich muss in der DB den Start- und endzeitpunkt (mit Datum und Uhrzeit) einer Tätigkeit speichern.
Bei der Ausgabe möchte ich nach KW anzeigen, es soll aber auch möglich sein, die gesamtstunden eines Monats für eine Tätigkeit auszulesen.

Verwende ich hierfür lieber den PHP-Timestamp und speicher das in ein int-Feld oder nehme ich zwei Spalten mit DATE und TIME Format?

Vielen Dank!

strauberry

[illusion]

Also ich würde den Timestamp vorziehen

[onemorenerd]

Ich würde die entsprechenden Datentypen der DB nutzen und so viel Logik wie möglich auch in der DB laufen lassen (direkt in den Queries, als Trigger oder Stored Procedures).
Ob nur eine Date- und eine Time-Spalte oder nur eine Datetime-Spalte, würde ich vom konkreten Vorhaben abhängig machen; im Zweifelsfall von der besseren Perfomance.

[Le_Cheffe]

Hi !

Ich würde die Timestamp vorziehen und die Logik ins Programm einbauen, da du so bei evtl. Wechsel der Datenbank (vielleicht reicht ja auch ein Update auf eine neue Version oder dein Provider hat noch eine ältere Version, die gerade das nicht kann) nicht auf deren Features angewiesen bist.

Gruß

Le Cheffe

[thommyk]

Abfragen bzw. Berechnungen, also auch Datums und Zeitberechnungen, die man mit SQL erledigen kann, sollte man nicht mit PHP machen, da (My)SQL die bessere Performance hat.

Würde also auch eher zum Date + Time bzw DATETIME Format tendieren

[wahsaga]

Re: Datenbankstruktur

Original geschrieben von strauberry
Verwende ich hierfür lieber den PHP-Timestamp und speicher das in ein int-Feld oder nehme ich zwei Spalten mit DATE und TIME Format?

Weder noch.

Unix Timestamp ist weniger gut, siehe onemorenerds Argument.

In zwei Spalten anlegen ist aber natürlich auch Murks - ein DATETIME-Feld wäre m.E. am angebrachtesten.


Das Argument mit dem möglichen Wechsel des DBMS zieht hier m.E. weniger. Simple Datumsoperationen sollte MySQL schon in frühen Versionen gekonnt haben, und neue Versionen dürften diesbezüglich ziemlich sicher abwärtskompatibel sein.
Und beim Wechsel auf ein ganz anderes DBMS kann sich immer Änderungsaufwand ergeben - deshalb versuchen, möglichst nah am ANSI-SQL zu bleiben, würde ich sagen.

[onemorenerd]

Damit wären wir bei der Frage, die sich eigentlich immer stellt:
- Entwickelt man für einen bestimmten DB-Server oder viele verschiedene
- und für eine bestimmte Version eines DB-Servers oder möglichst viele
- und für ein bestimmtes Szenario (für einen Hoster)?

Meist kann man gewisse Abhängigkeiten durch Abstraktionslayer umgehen, aber selten alle.

[strauberry]

Vielen Dank für eure hinweise! Hat mir sehr geholfen!

Das System wird für MySQL entwickelt, da gibt es auch in Zukunft keine Änderungen... und bei den Versionen denke ich auch, dass das auch ältere versionen hinbekommen.

Vielen Dank!