Grenzen von MySQL

[Sven Heising]

Hola,
> Hallo Sven,
> so langsam wirds 100% OT aber egal:
wohl wahr, ich hoffe es kommt aber nicht so rüber als das ich nen Flame-War
starten will, das liegt mir nämlich fern!

> 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.
> In solchen Fällen ist das Ziel einer DB Entwicklung bei mir: Baue die
> Datenbank so das du mit einfach selects an so gut wie 100% deiner
> Informationen kommst. Verlagere dabei Anfragelogik in Daten und
> Anwendungslogik. Erzeuge beim Dateneingang die Daten gleich so wie sie
> später auch gut abfragbar sind. Verzichte _nicht_ auf redundante Daten,
> sichere diese aber über eine Anwendungsschnittstelle ab, sprich lass
keinen
> Entwickler an der Abstraktionsschicht vorbei auf die Datenbank. Und nimm
> mehr Plattenplatz in kauf.
Ich kann gerne die Datenbankstruktur zur Verfügung stellen. Wir sind seit 12
Jahren im Geschäft und es haben schon viele Leute die Struktur begutachtet
und ich bin mir auch relativ sicher das die i.O. ist. Will mir da aber nicht
den Mantel der Unfehlbarkeit umhängen, das wäre vermessen.

> Wenn ich dieses Rezept anwende bekomme ich meist eine Lösung die äußerst
> performant ist und mit Bordmitteln jeder DB zurechtkommt. Und gerade das
> Beispiel Zeiterfassung/BDE läßt sich mit den Funktionen sum und count
meist
> 100% erschlagen wenn die Daten gescheit vorliegen.
Bei genauerer Betrachtung wirst du festellen das sich leider nur sehr wenig
mit sum und count erschlagen lässt.
Es gibt da leider nen bisschen mehr als nur jeden Tag 8 Stunden
hinzuzuaddieren. Ich würde jetzt ins krasse OT abgleiten wenn ich über die
Problematik von Flexi und Gleitzeitsalden in Kombination mit Resturlaub und
Überstundenauszahlung abschweifen würde, aber es ist wiegesagt nicht mit 20
Tage aufaddieren getan. Leider gibt es da viele Sachen die man beachten
muss.

> An eins sollte man dabei denken: 1000 Arbeitnehmer, 30 Tage, 4
Schichten ->
> mind. 240.000 Buchungen im Monat. Investiere ich pro Buchung bei der
> Buchungserfassung 0,1 Sekunde mehr Rechenzeit verteilt sich diese Zeit
über
> den ganze Monat. Diese Zeit könnte mir am Ende wieder diese 0,1 Sekunde in
> den Auswertungen sparen und spart mit so über 6,5 Stunden Rechenzeit am
> Monatsende ein. Erkaufen tue ich das mit mehr Plattenplatz. Aber mal
> ehrlich: Wer hat damit heute noch Probleme?
Leider kannst du viele Sachen nicht bei der Buchung berechnen, Überstunden
seien da nur als Beispiel genannt. Klar kann ich am Tag der Buchung
nachschauen wieviele Stunden der Mitarbeiter gesamt gearbeitet hat und dann
x-8 = Überstunden rechenen, nur ist das dann ne Milchmädcherechnung.

Grüsse
Sven

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql