Hey Dierk,
Ich habe bisher eigentlich immer gelesen, dass man sämtliche
Tabellen auf die sogenannte dritte Normalfrom bringen soll,
sodass in dieser Tabelle keine transitiven Abhängigkeiten
vorliegen ( wie es so schön heisst ).
klar, bei abhängigen Tabellen sollte immer beachtet werden, dass eine referienzielle Integrität bestehnt, also mit Änderung- und Löschweitergabe.
Wie ich das meine richtig verstanden zu haben, bedeutet dies,
dass ich in meinem Adressbeispiel eine unterste Tabelle
Länderkennungen erstelle, in welcher nur eine Beziehung
zwischen dem Länderkürzel ( DE, NE, FR . . . ) und bspw. einem
Autowert existiert. Also eine 2,n Matrix.
so eine Tabelle kann man sich sparen. Ob nun in der Haupttabelle zwei Buchstaben oder zwei Zahlen (Verknüpfungs-ID) gespeichert werden macht den Kohl nicht fett (äh die DB nicht größer).
Die Tabelle darüber ist dann eine 3,n Tabelle. Ein
durchnummerierender Autowert, eine Spalte Länder (
Deutschland, Niederlande, Frankreich . . . ) und eine Spalte
Länderkürzel, welcher ich dann Ziffern zuordne, die ich dann
mit der Tabelle Länderkennungen verknüpfen kann.
viel zu aufwändig: wenn du schon eine Länder/(L)änder(k)enn(z)eichen -Tabelle erstellen willst, dann nur eine, wo beide Werte drin stehen, da nur ein LKZ zu einem Land passen kann, d.h. du hast ja dann keine 1:n Verknüpfung, die dir ggf. ein paar Bit an Datenbankgröße sparen würde.
btw. seit Umstellung der DIN für Postadressen ist das LKZ im Adressfeld nicht mehr zulässig, d.h. das kannst du dir sowieso sparen!!
(wenn sich bspw. eine Länderkennung ändern würde, müsste ich doch in
der Tabelle Länder jeden einzelne DE in ein DEU ändern oder ? )
klar, das macht man mit einer Änderungsabfrage, die in einer Minute programmiert ist und grade mal 10 Sekunden für die Änderung bei 100.000 Datensätzen braucht.
Und es würde dann doch irgendwann 10000 Mal das Wort Berlin
stehen, als nur ein Beispiel.
ob dort nun 1000 mal Berlin steht, oder 1000 mal ein Verweis in eine zusäztliche Tabelle, ist datentechnisch weniger relevant, aber programmiertechnisch hinterher ein Riesen Aufwand, um dann alle Verweistabellen einzubinden, wenn ich mal eine Telefonliste haben will.
Sinnvoll ist sowas in meinen Augen nur, wenn über 1 Mio. Adressen vorliegen. Da kann man dann ein paar KB an Datenbankgröße sparen.
Aber wie du sagst, gehst du andern vor, indem du alles ? (
meinst du alle Adressdaten ? ) in eine Tabelle verwirklichst ?
Aber aufspalten musst du doch dann trotzdem irgendwann, oder
nicht ?
Alle Adressdaten in eine Tabelle. Das „Aufspalten“ erfolgt später über Filter bzw. Abfragen.
Und um auf mein eigentliches Problem zurückzukommen . . . die
Eingangsrechnungen.
Würdest du eine Tabelle Eingangsrechnungen erstellen, die
sämtliche Werte enthält ?
klar, auf jeden Fall, nur eine Tabelle Rechnungseingang.
Also Rechnungseingang, vom wem sie eingegangen ist, wann sie
mit Skonto zu bezahlen ist, in welchen Bereich diese Rechnung
einzuordnen ist ( Büromaterial, Dienstleistungeinkauf . . . .
) . . .
All dieses in einer Tabelle ?
jein, bis auf die Adresse mit Zusatzinformationen von den Lieferanten, die würde ich in eine Lieferanten-Tabelle speichern, da diese auch noch für andere Zwecke genutzt werden können und nur den Verweis dann ins Rechnungseingangsbuch einbinden.
D.h. du mußt differenzieren, ist es ein „kleiner“ Wert in einem Feld, oder sind es viele Felder mit unterschiedlichen Werten wie z.B. Adress, Telefon, Fax - Informationen einer Firma. Dabei ist es natürlich sinnvoll diese an einer Stelle zentral zu speichern, nicht sinnvoll ist es für Länderbezeichnungen und LKZs etc.
Das widerspricht denke ich total meinem Buch, welches ich
durchgearbeitet habe ( extra um diese anfänglichen Fehler eben
nicht zu machen und mir spätere Arbeit zu ersparen )
keine Ahnung welches Buch du da gelesen hast, diese Vorgehensweise ist sinnvoll bei großen / sehr großen Datenbanken um Platz zu sparen.
Du mußt differenzieren:
Einzelwerte würde ich nicht in einer seperaten Tabelle speichern.
Kunden- , Lieferantendaten mit ggf. einer anhängenden Tabelle für Ansprechpartner und deren Daten würde ich wieder separieren.
Grüße aus Essen
Wolfgang