Stundeneingabe erstellen

[Beach]

Hi,

ich muß ne Stundeneingabe die bisher über Excel läuft in eine Datenbank übertragen. Die vorhandene Daten der letzten Jahre sollen evtl. mit übernommen werden.
Das ganze soll dazu dienen zu verfolgen wieviele Stunden jedes Monat auf den verschiedenen Projekten gearbeitet wurde.

Ich habe mir gedacht das ganze mittels Formular und Textfeldern in HTML/PHP zu programmieren.

Jeder Mitarbeiter ca.40 Personen später evtl mehr arbeitet im Durchschnitt an 3-5 Projekten am Tag, Wenn ich jetzt für jeden Mitarbeiter pro Tag eine Datensatz verwende, dann kommen pro Jahr ca. 5*5*52*40=50000 Datensätze zusammen.
Ist das sinnvoll oder sollte ich lieber einen Datensatz je Monat und Projekt machen und 31 Splaten für die einzelnen Wochentage.

Ist es überhaupt praktikabel das über HTML/PHP zu machen, oder wisst Ihr nen besseren Ansatz.

Grüße Thomas

[Siechfred]

Das ganze soll dazu dienen zu verfolgen wieviele Stunden jedes Monat auf den verschiedenen Projekten gearbeitet wurde.

Das lässt sich problemlos über die Datenbankabfrage steuern.

Ich habe mir gedacht das ganze mittels Formular und Textfeldern in HTML/PHP zu programmieren.

Schön, und welches Datenbanksystem willst du verwenden?

Jeder Mitarbeiter ca.40 Personen später evtl mehr arbeitet im Durchschnitt an 3-5 Projekten am Tag, Wenn ich jetzt für jeden Mitarbeiter pro Tag eine Datensatz verwende, dann kommen pro Jahr ca. 5*5*52*40=50000 Datensätze zusammen. Ist das sinnvoll oder sollte ich lieber einen Datensatz je Monat und Projekt machen und 31 Splaten für die einzelnen Wochentage.

Ich würde mit mindestens drei Tabellen arbeiten:

• Tabelle Projekte mit einem Feld Projekt-ID und weiteren beschreibenden Feldern (Aufgabe o.ä.)
• Tabelle Mitarbeiter mit einem Feld Mitarbeiter-ID und weiteren beschreibenden Feldern (Name...)
• Tabelle Zeiterfassung mit den Feldern Projekt-ID, Mitarbeiter-ID, Datum, Zeit

Gegebenenfalls kannst du noch eine Tabelle Kunden hinzufügen, um Redundanzen in der Projekttabelle zu vermeiden, falls du dort die Kundendaten mit ablegen willst. Hast du das getan, kannst du über JOINs über die Tabellen Abfragen erstellen. Denkbar z.B.:

• Stunden je Projekt
• Stunden einzelner Mitarbeiter je Projekt
• Stunden einzelner Mitarbeiter je Projekt für einen bestimmten Zeitraum
• Stunden eines Mitarbeiters für einen bestimmten Zeitraum

Je normalisierter dein Datenbankdesign ist, um so vielfältiger sind die Auswertungsmöglichkeiten.

Siechfred

[Ilja]

yo,

Ist das sinnvoll oder sollte ich lieber einen Datensatz je Monat und Projekt machen und 31 Splaten für die einzelnen Wochentage.

50.000 Datensätze sind kein problem, sprich mach es nicht mit einer spalte pro tag.

Ist es überhaupt praktikabel das über HTML/PHP zu machen, oder wisst Ihr nen besseren Ansatz.

weder html noch php werden die zugriff auf die daten machen, sondern das jeweilige dbms. insofern betrifft die frage weniger html/php, sondern welches dbms system letzlich dahinter "hängt".

html hat meiner meinung nach immer den vorteil, man muss keinen zusätzlichen client installieren und fast jeder kennt sich mit einem browser aus.

Ilja

[Frank (no reg)]

Hello,

ich kenne viele Zeiterfassungssysteme, die mittels Webinterface arbeiten, ich habe auch selber schon komplette Systeme derer Art programmiert, weiterentwickelt, implementiert. Es gibt so gesehen keinen objektiven Nachteil einer zentralisierten html/php Lösung als Frontend für die Eingabe.

Verwende bitte einen Datensatz pro Zeiterfassung. Eine Zeiterfassung besteht dabei aus

• Referenz zum Benutzer (dem der die Zeit kontieren will)
• Referenz zur Tätigkeit (Projekt)
• optional für feinere Graninität Referenz zur Aufgabe innerhalb des Projekts
• Referenz zum Datum, bzw. das Datum für welches die Eintragung gelten soll
• die Menge der zu kontierenden Zeit in der von dir gewünschten genauigkeit (decimal(4,2) erlaubt -99,99 bis +99,99 Std. ...)

Also als Bespiel:

MA           | Projekt     | Aufgabe        | Datum      | Zeit   |
-------------|-------------|----------------|------------|--------|
Müller, M.   | ProjektX    | Dokumentation  | 2007-07-06 | 1.75   |
Müller, M.   | ProjektY    | Programmierung | 2007-07-06 | 4.00   |
Meier, R.    | ProjektX    | Meeting        | 2007-07-06 | 3.25   |

Du verstehst das Konzept?

Sinnlose Eingaben wie > 24.00 pro Tag verhinderst du mit Check-Constraints. Darüber hinausgehende halb-sinnlose Kontierungen wie mehr als 48h pro Woche verhinderst du durch die Geschäftslogik in PHP.

Es ist vollkommen unkritisch (wenn du nicht gerade mit Technik von 1965 arbeitest), 50.000 Datensätze für ein Jahr zu haben. Dein DBMS bietet dir für die Abfrage mind. 1 Möglichkeit zur Performancesteigerung - Indizierung.

Was du jetzt zur Auswertung betreiben kannst ...

• gib mir die gesamtzahl Stunden für Projekt X im Zeitraum ...
• gib mir die monatlich kontierten Stunden pro Mitarbeiter für die letzten 12 Monate

Das erreichst du durch den Gebrauch von Aggregatsfunktionen wie SUM(), AVG(), GROUP BY in eigentlich sehr trivialen SELECT Queries.

Obiges Modell kann natürlich noch soweit Normalisiert werden, dass die Tabelle technisch so aussieht:

MA-ID | Projekt-ID  | Aufgabe-ID | Datum      | Zeit   |
------|-------------|------------|------------|--------|
123   | 1           | 5          | 2007-07-06 | 1.75   |
123   | 2           | 3          | 2007-07-06 | 4.00   |
254   | 1           | 12         | 2007-07-06 | 3.25   |

Dazu hast du dann separate Tabellen für MA, Projekte, Aufgaben, die über deren Primärschlüssel mit obiger Tabelle verbunden sind.

Normalisierung ist ne feine Sache, allerdings hebt das überhaupt nix in Sachen Vielfältigkeit der Auswertungsmöglichkeiten. Entweder die Daten (Graninität) sind da oder sie sind nicht da.

Mehr fällt mir jetzt grad nicht mehr ein. :)

Ciao, Frank

[Siechfred]

Normalisierung ist ne feine Sache, allerdings hebt das überhaupt nix in Sachen Vielfältigkeit der Auswertungsmöglichkeiten. Entweder die Daten (Graninität) sind da oder sie sind nicht da.

Da dieser Ball an mich geht: Ich habe das mal anders beigebracht bekommen, was mir aber vor dem Hintergrund deiner Ausführungen irgendwie nicht mehr so einleuchtend vorkommt wie damals - naja, war noch dBASE und später ein bisschen Access, vielleicht war das damals ja noch richtig :)

Siechfred

[Frank (no reg)]

Moin,

je mehr Normalisierung, je mehr JOINs brauchst du, je mehr logische Lesevorgänge muss das DBMS machen. Deswegen sind analytische Modelle, die für die Abfrage optimiert sind (nicht für die Eingabe) eher denormalisiert. Z.b. Stern-Schema oder wenn's des unbedingt bruucht, Schneeflöcken-Schema (Snowflake). Der Informationsgehalt ist dabei annähernd identisch, die technische Datenmenge mehr, durch Explosion und Denormalisierung. Wie gesagt, entweder die Informationen sind da oder nicht.

Methodiken sind auch der natürlichen Evolution unterworfen. Kann durchaus sein, dass man damals davon ausgegangen ist, Normalisierung ist das Allheilmittel. (Bei uns nennt es sich gerade Sharepoint ;))

Cheers
Frank

[Beach]

Hi,

ich danke euch für die Vielen Tip's. Jetzt wo ich weiß dass es sowas schon gibt, denke ich dass ich's auch mit html/php/mysql machen werde.

Mir gings nur darum erst mal zu wissen ob Ihr das überhaupt für sinnvoll haltet, nicht dass ich hier programier und irgendwann stoße ich an die Grenzen der Browser und merke dass es auf diese Weise überhaupt nicht geht.

Jetzt muß ich mir dann auch mal Gedanken über das Design machen. Habt ihr dafür evtl Beispiele bei denen mann sich Anregungen holen kann wie man die Eingabe am besten aufbaut. Ich dacht als erstes an das klassische Tabellenlayout (z.B Blatt für 1 Monat mit den Taben in Spalten und den Projekten in Zeilen). Aber vermutlich wird das sehr aufwendig zu programieren.

Grüße Thomas

[Frank (no reg)]

Hallo nochmal,

ich verwende für die Eingabe immer Schema F. ;)

Also die standard Eingabe-Seite zeigt mir die Tage der Woche aktuelle Woche per default) in Spalten an und die Projekte als Zeilen. Insofern liegst du mit deiner Idee schon recht gut.

Als Tabellenfuss mache ich dann eine Summierung der Stunden für den gesamten Tag. Mit etwas Programmlogik färbe ich diesen Betrag denn rot wenn er zu hoch ist, nur mal so als weiterführender Gedanke.

In den Zellen (Zelle = Kreuzung aus Zeile/Spalte) die sich ergeben, habe einen Button zum Hinzufügen eines neuen Stunden-Eintrags und einen für die Details von dem Projekt/Tag. Der Detail-Button gibt mir nach (unter) der Tabelle dann eine Liste von Kontierungen für Projekt/Tag. Von dort aus kann ich Einträge editieren und wieder löschen.

Weiterhin zeige ich in der Tabellenzelle selbst noch die Summe der Stunden für dieses/n Projekt/Tag.

Projekt    | Montag    | Dienstag  | ....      | Total     |
-----------|-----------|-----------|-----------|-----------|
Projekt X  | 6.50  D + |         + | ....      |      6.50 |
Projekt Y  | 1.00  D + | 2.75  D + | ....      |      3.75 |
-----------|-----------|-----------|-----------|-----------|
Total      | 7.50      | 2.75      | ....      |     10.25 |
-----------|-----------|-----------|-----------|-----------|

D ist der Detail-Button, + der "Neuer Eintrag"-Button.

Die Liste für die Details sieht dann zum Bleistift so aus:

Montag, 7.10.2006

Projekt    | Aufgabe   | Stunden   |
-----------|-----------|-----------|-----------|-----------|
Projekt X  | Doku      | 3.50      | Ändern    | Löschen   |
Projekt X  | Proggen   | 3.00      | Ändern    | Löschen   |
-----------|-----------|-----------|-----------|-----------|

Die Logik für die Anzeige ist imho nicht wirklich kompliziert oder über die Maßen aufwendig, aber so trivial wie <h1>Hello World</h1> ist es dann auch nicht. Es ist imho einfach eine Verwendung von <table> (ja, für tabellarische Daten darf man wirklich <table> verwenden) und Schleifen deiner Programmlogik.
Die Totals am Zeilen- oder Spaltenende kannst du dann entweder dynamisch in PHP über die Schleifen und Arrays berechnen oder als separate Abfrageergebnisse aus der DB Holen.

Die einzigen Schreibaufgaben (Inserts und Updates) solltest du vom eigentlichen Eingabeformular für die Stundenkontierung machen, der Rest sind alles nur Selects mit ein paar JOINs, vielleicht auch UNIONs.

Die Verwendung eines DBMS (Version) mit Unterstützung für Unterabfragen (Subqueries) könnte dir für die Selects ganz hilfreich sein.

Soetwas wäre eine gute Aufgabe für einen Job-Kandidaten, stelle ich gerade fest. 4 Std. sollten da genügen.

Grüsse
Frank

[at]

Hallo.

(Graninität)

Muss man dafür Hohes C können?
MfG, at