Mal wieder zurück zum Thema
- Was muss man beachten...
Abhängig von der Art der Bearbeitung ist daran zu denken, wie Transaktionen und Sperren eingesetzt werden. Handelt es sich bei dem Projekt um viele eigenständige Datensätze (wie z.B. ein Protokoll) oder ist die Struktur mehr hierarchisch aufgebaut (wie z.B. Aufträge, Positionen, Lieferungen).
Das Datenbankdesign ist dabei wirklich immens wichtig. Man muss einen Mittelweg finden zwischen der extremen Normalform (keine Redundanz) und entsprechender Performance. Bei der Normalisierung wird nämlcih oft vergessen, dass manche
DB nur eine begrenzte JOIN-Verschaltelungstiefe unterstützen. Und was nützt eine
DB die insgesamt wenig Felder, geringen Platzbedarf hat und der 4. NF entspricht, wenn Du permanent 6-fach verschachtelete JOIN deswegen benötigst und ab der 7. sagt Die
DB "ist nicht". Oder entsprechend das Absacken der Performance.
Soll im Projekt vorgangsorientiert oder eher visuell (QBE) gearbeitet werden?
Generell solltest Du, wenn möglich, Transaktionen einsetzen. Dabei ist aber auch wieder die Dauer der Transaktionen zu beachten. Wenn ein Benutzer einen Auftrag 10 Minuten lang bearbeitet, dürfen durch die Transaktion nur die direkt verarbeiteten Daten geschützte werden. Absolut fatal ist, wenn man z.B. eine zentrale Tabelle mit lfd. Nummern hat, die dann ebenfalls geblockt bleibt. Also Transaktionen isolieren und wenn möglich nur für kurze, zusammenhängende Update-Operationen.
Views und Stored Procedures ersparen Dir viel Arbeit und Redundanz im Projekt. Allerdings ist da die Frage, ob Du für immer by
MySQL bleiben willst, denn meistens setzen unterschiedliche
DB auch andere
SQL-Dialekte für ihre Scripts ein, die nicht zueinander kompatibel sind. Und leider kommt immer irgendwann der Zeitpunkt, wo man aus Bequemlichkeit oder weil es funktional momentan keine andere Lösung zu geben scheint, proprietäre Syntax einsetzt.
Viel Spass...