Mailinglisten-Archive |
On Friday, 07 March 2003 09:36, Andreas Müller wrote: Ich weiss, ich wärme einen alten Thread wieder auf, aber ich möchte einfach doch meinen Senf dazu geben. > so langsam wirds 100% OT aber egal: Finde ich nicht, denn auch wenn ihr hier über sinn und Unsinn von Stored Procedures streitet respektive gestritten habt: Es geht auch um das richtige Design von Datenbanken und Datenbank-gestützten Applikationen. [Beispiel war Zeiterfassung] > Die Anzahl von Datensätzen sind absolut nicht entscheidend. Entscheident > ist eine gute Datenbanstruktur und durchdachte Anwendungslogik. In deinem > Fall wäre es z.B. fatal einfach die Zeiten zu loggen und dann am Schluß > auszuwerten. Dann entsteht ein Rechenaufwand der nich mehr schön ist. So ist es. Beim Beispiel Zeiterfassung kann man sich zum Beispiel eine Tabelle zu den einzelnen Buchungen aufbauen (insbes. Anmelden des Mitarbeiters und Abmelden), und eine mit den vorverarbeiteten Zeiten. Das kann dann zum Beispiel so aussehen: ZeitID <autoincrement> date date # Tag der Buchung AN_ID int # Arbeitnehmer-ID reg_Arbeitszeit real # reguläre Arbeitszeit Nacht_AZ real # AZ in der Nachtschicht UeStd real # Krank real # krankgemeldet für X Stunden ... In die Tabelle wird entweder beim Abmelden des Arbeitnehmers geschrieben (und dann entsprechend reg_AZ, Nacht_AZ, UeStd mit den passenden Werten gefüllt), oder eben beim Eintragen von Krankmeldungen. Dann kann man die einzelnen Abrechnungen zu 99% über einfache Selects erledigen, die restlichen vereinfachen sich extrem. Wie Du schon sagtest: So verteilt sich die Rechenzeit der Auswertung von der einmaligen Auswertung zu einer kontinuierlichen Erfassung/Verarbeitung. Regards, Sven Müller - IT - Network&Infrastructure - -- * Heinrich Berndes Haushaltstechnik GmbH & Co KG * Wiebelsheidestrasse 55, 59757 Arnsberg, Germany * Phone: +49 2932 475-282 / FAX: -325 * http://www.berndes.com -- Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter -->> http://www.4t2.com/mysql
php::bar PHP Wiki - Listenarchive