Hallo, Josef!
[...]
Auch [...] ;-)
Post by Michael ZimmermannStichwort "Aktenzeichenanomalie"; verstößt je nach
Konstellation gegen 0., 1., 3. oder Boyce-Codd-
Normalform.
Grundsätzlich gebe ich Dir recht, ...
Bis hierhin okay...
aber...
Es läßt nach ;-)
wenn es sich dabei um einen Wert handelt, welcher
nur _ein einziges mal erstellt_ wird, würde ich
den trotzdem in einem extra Feld ablegen und nicht
jedes mal neu errechnen. - mit dem Wissen dass ich
bewußt gegen die Regeln der n-ten
Normalform verstoße. ;-)
Es ist ein Unterschied, gegen eine Regel, die man kennt
und beherrscht aus - dokumentierten - Gründen und unter
Gewichtung aller Konsequenzen zu verstoßen oder von der
Existenz von Regeln gar nichts zu wissen.
Stichwort Geschwindigkeit
Das ist - ich meine das jetzt nicht persönlich - ein
unsinniges Pauschalurteil, das seit den 70er Jahren,
ohne den Fortschritt in der Hardware-Entwicklung zu
berücksichtigen, immer weiter vererbt wird, ohne es mit
Performance-Tests geprüft zu haben.
1. Code-lastige Sichtweise vieler Programmierer:
Performance ist nicht die Zeit, die der Code zum Laufen
braucht, sondern die Zeit, bis eine betriebliche
Aufgabenstellung erledigt ist - einschließlich der
Arbeitszeit, die nötig ist, um durch Denormalisierung
entstandene Widersprüche aus den Daten zu schütteln.
2. Prozessoren mögen lieber Zahlen als Text:
Eine Sortierung über 1, 2, 3 statt z. B. der damit
codierten Strings "Fremdartikel", "Eigenfertigung", etc.
ist trotz der Auslagerung (Normalisierung) der
Artikelkategorie in eine eigene Tabelle schneller(!),
als über ein integriertes Feld Artikelkategorie als
Text. Da die Codeziffern intern ausreichend sind, muß
man oft noch nicht mal joinen. Zusätzlich kann man
durch die reinen Zahlenschlüssel viele Bedingungen
ohne Iif und & durch boolesche Ausdrücke und rein
arithmetische Verknüpfungen wesentlich performanter
gestalten. Die Zahlencodierung einfacher Textspalten
entspricht in den Grundzügen der Domain-Key-Normalform.
3. Rushmore und ähnliche Optimierungen:
Die aus den 70ern stammende Aussage, daß Selektion
billiger als Join ist, kenne ich auch. Aber: Kein
gescheites DBMS (Access schon gar nicht) joint heute
noch intern nach der Basisregel Kreuzprodukt und
zeilenweise Auswahl der vom Join betroffenen Tupel.
Darauf bezieht sich nämlich das Join-Selection-Statement.
4. Weniger Daten durch normale Strukturen:
Pack mal eine dreifache Multi-Value-Dependency (4NF)
in eine Tabelle statt in drei. Dann hast Du statt
z. B. 30+50+70 = 150 DS, die Du *vor* dem Joinen
filterst, 30*50*80 = 120.000 (!) DS, mit denen Du Dich
jetzt ganz performant auseinandersetzen darfst.
5. Lieber richtig als schnell:
Obwohl ich selbst Performance-Fanatiker bin, das
klare Bekenntnis: Datenintegrität kommt ganz klar vor
Geschwindigkeit. Eine DB, die blitzschnell Fehler erzeugt,
ist nutzlos.
Wenn sich die Felder mit einem einfachen Feld1 & Feld2
& ... zusammensetzen wird man ja noch keinen Unterschied
merken (naja vielleicht doch: und zwar dann, wenn nach
diesem Feld gefilter wird),
Tut man ja nicht - man filtert nach den einzelnen
indizierten Feldern.
aber was ist, wenn sich der Feldwert mittels einer selbst
erstellten Funtkion ergibt? => diese immer in die Abfrage
einbauen finde ich nicht gerade empfehlenswert.
Kommt auf die Abfrage an und wofür sie gut ist. Wenn die
Abfrage dem User den errechneten Wert nicht zeigen muß,
ist er überflüssig, da die Informationen ja in anderen
Feldern atomar vorliegen und zum Filtern/Gruppieren
benutzt werden können.
Wenn der User den Wert sehen soll, bekommt er sowieso
ein Formular vorgesetzt. Da genügt meist *ein* berechneter
Wert (Einzelansicht), was schnell genug geht. Access
ist auch schlau genug, nur die sichtbaren Werte zu
berechnen. Das Problem, daß erst mal 200.000 DS
durchgerechnet werden, bevor die Anzeige kommt, stellt
sich nicht.
Nach allem, was ich bis jetzt an DB-Fragmenten die doch
nicht gelaufen sind, die unsere Firma dann bei Kunden zur
Weiterentwicklung übernommen hat, gesehen habe, drängt sich
mir eher der Eindruck auf, daß z. B. nicht normalisierte
Verbundabhängigkeiten weniger auf einem berechneten
Vergleich der zu erwartenden Laufzeiten bei Aufteilung
vs. einer Tabelle beruhen, sondern auf Unkenntis der
5. Normalform. Oder willst Du dagegen wetten? ;-)
Völlig normalisierte Grüße aus Mainz
Michael