Office: Primärschlüssel in jeder Tabelle zwingend?

OK, lassen wirs einfach dabei und ich erstelle bei Gelegenheit die Beispieldatei. dann dürfte vieles klarer sein. *wink.gif*

Im Prinzip hast du es richtig verstanden, glaube ich. *wink.gif* Ich trenne sie lediglich an einem anderen Ort, das ist alles. Sprich es wird nicht innerhalb der reinen Adresstabelle getrennt, sondern eben über die Typzuweisungstabelle. Dadurch programmiere ich alles was mit Adressen zu tun hat genau einmal, über die ganze Datenbank. Ob nun Mitarbeiter, Sohn, Tochter, Firmenname, Standort, wirklich egal was. Dadurch kann jeder dieser personen eben bei der entsprechenden Aktivierung auch etwas anderes sein und gleichzeitig jenes.

Anderes Beispiel, Adressbücher:
Gewisse Leute haben eigene Adressbücher, hier gibts auch verschiedene Typen welche dann Zugewiesen werden, einige erscheinen Global, andere nur für bestimmte Personen usw.

Noch ein anderes: Unser Privates Adressbuch ist zum Beispiel auch darin abgelegt, sinnig oder nicht, die Leute kaufen aber auch bei uns ein, also sind sie mit einer simplen Typzuweisung auch Kunde und erscheinen in der Kundenauswahl und gleichzeitig auf Wunsch im Privaten Telefonbuch. Gleiches gilt für Kontaktpersonen von Firmen, einige werden auch Privat Kunde von uns, arbeiten aber gleichzeitig in der anderen Firma. Jetzt müsste ich sämtliche Telefonnummern redundant ablegen. Privatadresse auch. So gibt es sie genau einmal *wink.gif*

 

\@Urs:

Wenn ich das nicht getan hätte, hätte ich wohl auch kaum zitieren können.
Sei doch einfach mal ein wenig selbstkritischer und siehe, dass Deine Aussagen (nicht nur von mir) offensichtlich nicht immer so verstanden werden, wie Du es möchtest. Wenn Du Deine Beiträge selbst nochmal nach dem Erstellen diesbezüglich lesen würdest, würde Dir das vielleicht auch gelegentlich mal auffallen?
Es soll doch in diesem Forum nicht darum gehen, sich selbst darzustellen, sondern dem Fragenden verständlich zu helfen!
Ich war nicht der Meinung, dass ich Dich in meinem Beitrag nur wiederholt habe, falls wir die gleichen Problematiken angesprochen haben, dann habe ich diese wohl offensichtlich ein wenig verständlicher für steve005 geäußert.
Dessen Anliegen ist ja nun durch Deine Dispute mit den anderen Teilnehmern hier inzwischen auch ein wenig in den Hintergrund geraten!
Fühl Dich einfach weniger persönlich angegriffen und versuche einfach Dich verständlicher zu äußern, das erspart Irritationen, Zeit und offensichtlich auch Stress...

 

*confused.gif* Steve, noch da? *eek.gif*
Lass dich nicht abschrecken!
SCNR

 

\@FW: Fein. Dein Ausdrucksweise gefällt mir immer wieder. *grins
Du hast einen einzigen Satz zitiert und ihn nicht im verhältniss des Posts gesehen, sonst wäre dir aufgefallen, dass ich einen Satz später von gesperrten Datensätzen gesprochen habe, sowie die Tatsache das eben die Daten durch alle Tabellen durch geändert werden müssen. Auch habe einige andere Gründe gennant welche dagegen sprechen. In keiner Weise habe ich gesagt, dass er das manuell machen muss.
Persönlich nehme ich das gar nicht. Warum auch... Finde es nur belustigend und hab dich darauf hingewiesen. *redface.gif* Du scheinbar schon. *rolleyes.gif*

Aber: Wenn ich überzeugt bin von einem Konzept welches offensichtlich vorteile hat, in der praxis sich viele jahre bewährt hat gegen die anderen konzepte oder sich daraus entwickelt hat, dann sehe ich es nunmal nicht ein, den Standpunkt nicht zu vertreten den ich vertrete und versuche es eben ausführlich zu erklären und Gegenargumente zu bringen. Wenn jeder grad beim kleinsten Piep der "Grossen" kleinlaut beigeben würde, dann würde die Entwicklung stehen bleiben. Mir isses dabei auch herzlich egal wer das ist.

Tja, ist halt etwas ausgeufert die Diskussion im Sinne von nicht mehr das was gefragt ist. Ist das schlimm? Seine Frage wurde beantwortet also ist es imho nicht schlimm sogar eben evtl. noch hilfreich wenn ein paar Verschiedene Meinungen aufeinander treffen und man das beste für sich herauszupfen kann.

Gestresst bin ich dabei gar nicht, im Gegenteil, bei Forenbeiträgen und solchen lustigen Unterhaltungen mit dir kriegt der Arbeitstag gleich noch bissel mehr Farbe. Mir macht das ganz ehrlich ne Menge Spass deine Beiträge zu lesen und zu beantworten. *Smilie Wir amüsieren und gerade köstlich. *grins

 

\@Urs: Bevor das Ganze wieder ausufert und Du mich wieder mit persönlichen Nachrichten bombadierst, nur so viel: Wenn Du verstanden werden willst, dann solltest Du Dich auch bemühen, Dich entsprechend zu artikulieren. Den Menschen, die Dich nicht verstehen, zu unterstellen, sie hätten Deinen Beitrag nicht gelesen, ist wohl ein wenig einfach, wenn nicht sogar arrogant und das hilft keinem.
Und Dein Satz

zeigt mir schon, dass Du in merkwürdigen Kategorien denkst, die nicht wirklich stressfrei sein können.
Nochmal, wir sind hier nicht auf 'nem Schlachtfeld und es sollte hier wohl auch nicht darum gehen "Kleine" zu unterdrücken und "Großen" den Hof zu machen, sondern darum, dass wir hier verständlich in der Sache diskutieren und uns austauschen!

 

\@Weingeist:

Im Prinzip ist das die Bildung eines abstrakten Oberbegriffs, ähnlich einer Klassenhierarchie: die erbende Klasse übernimmt (maximal) alle Eigenschaften und Methoden der Oberklasse.

*Die* ultimative Oberklasse ist dann aber "Object". Und was kann die schon groß? "Ding" ist alles *philosphier* *biggrin.gif*

Ein bisschen typisierter würde ich es schon aufbauen.

HTH

 

[OT]
@Atrus2711: Ist Jet seit neuestem zu einem objektrelationalen DBMS geworden? *biggrin.gif*

 

\@FW: Denk was du denken willst. Du peilst es einfach ned. Du bist einfach absolut immun gegen eine entschuldigung oder eingestehen eines Fehlers von anderen. Das habe ich letztes mal versucht. Weit gefehlt. Daher bevor du anderen irgendwelche psychische Probleme unterstellst, solltest lieber mal vor der eigenen Haustür wischen und nicht anderen jene Probleme unterzustellen, die ganz offensichtlich dich betreffen. *grins

In diesem Sinne: Weiter mit der Stresstherapie. *grins

@Atrus: Das ist eigentlich gar nicht so Abstrakt. 99% der Felder sind ja allgemein gültig. Sind ja lediglich Adressinformationen gespeichert. Also immer das gleiche. die Ausnahmen bilden ein paar spezifische Felder. Die bleiben dann halt leer. Die Adressinformationen die gebraucht werden bleiben ja identisch, egal ob Kunde, Lieferant, Mandant oder ...

Ding: Eine Umschreibung für etwas, was man nicht so genau weiss, wie mans bezeichnen soll. *grins

 

\@Urs: na das nenn' ich 'ne gelungene Projektion.

 

\@Josef: Nein, ich wollte nur andeuten, wo die Idee hinführt, z.B. Adressen auf Gedeih und Verderb in einer Tabelle zu halten.

Wenn z.B. ein Kunde umzieht, heißt das ja nicht, dass die "Adresse", die schiere geologische Lokation, umzieht. Das geht überhaupt nicht (Kontinentaldrift jetzt mal ausgenommen *cool.gif* ). Vielmehr ändert sich eine Eigenschaft eines, na? Kunden. Eben. Da ich also nicht einfach die Adresse ändern darf (da wohnen zig Lieferanten, andere Kunden etc), muss ich also die Verwendung der Adresse als Kundenadresse ohnehin auswerten. Dann kann ich es auch beim Kunden lassen und spare mir viele Joins. Der vermeintliche Vorteil, Adressen zentral zu halten, ist keiner, denn Adressen als solche ändern sich nicht bzw. haben nichts gemeinsam.

Gruß

 

\@Atrus: Grundsätzlich habe ich immer nur eine einzige Join. Die ist von der Kontakt-Tabelle dahin wo sie gebraucht ist. Für die Auswahl einer Adresse aufgrund der Kriterien brauche ich eine zusätzliche Tabelle. Für die Auswertung also eine Join, für die Eingabe deren zwei.
Die Adresse an sich speichere ich aber auch so im Beleg ein. Die alten Rechnungen dürfen sich ja nicht verändern wenn wieder eine Kopie gedruckt wird.

Aber du hast schon recht, man kann das auch über diese "Kundentabelle" oder bei mir eben diese allgemeine Typ-Tabelle lösen wenn man möchte. Das hat aber mit dem System an sich nix zu tun die Adressen in der gleichen Tabelle zu halten, dann sind jedoch zwei Joins nötig. Bei der Auslagerung von verschiedenen Liefer/Lageradressen etc. zu einem Kunden hast das aber immer.

Die Lager-/Lieferadresse finde ich darum interessant weil ich dadurch die Möglichkeit habe, die Warenverschiebungen für sämtliche Adressen zu verwenden. So erspare ich mir sämtliche Standorte zusätzlich zu erfassen.

Nachteile hat jedes System, hier ist es jener wenn zum Beispiel der Hauptsitz eines Kunden an Adresse XYZ ist. Warenverschiebungen und Rechnungen gehen beide dahin. Nun wird der Hauptsitz verschoben, der Standort bleibt aber als Lager bestehen, die neuen Rechnungen müssen auf den neuen Standort lauten.

Das ist tatsächlich eine Zwickmühle und auch ein Nachteil des System. Weiss aber nicht ob du darauf hinauf wolltest.

Lösen könnte man es so, das eben wirklich die Verknüpfung an sich (Also in der Typtabelle) für jeweiligen Verlinkungen verwendet werden. Dann muss darin die eine AdressID angepasst werden und es werden jeweils zwei Joins benötigt. Das entspricht dann ungefähr der Kundentabelle, ist aber flexibler.

Ändert man einfach die Adresse ab bei der direkten Verknüpfung, dann sind die Statistikauswertungen für den alten Standort nicht mehr gültig. Erstellt man eine neue Rechnungsadresse, dann hat man nicht mehr pro Kunde direkten Zugriff.

Korrekterweise wäre jetzt der Zeitpunkt gekommen, jene Firmenadresse aufzusplitten und alle alten FK's auf das Duplikat mit der Kopie des alten Hauptsitze mit einer neuen Adresse (welche nun nicht mehr aktuell ist) zu bestücken oder die Kundenaufträge mit dem neuen Key. So handhabe ich das aktuell ist aber im vergleich zu Telefon-Nummern änderungen, Adressänderungen und dergleichen sehr selten.

Die Eierlegende Wollmilchsau ohne Nachteile wirds wohl auch nicht geben. Wie immer führen verschiedenen Wege nach Rom und man muss entscheiden welche Variante für einem die wenigsten Nachteile bringt.

 

\@Weingeist:

Da sind wir uns einig. Wir wollen nicht das beste System, sondern das am wenigsten schlechte. *mrcool

Ein schönes Schlusswort!

Gruß und *aushak*

 

Hi!

Interessanter Beitrag!

Ich würde gerne zu der ursprünglichen Fragen nach der Notwendigkeit eines Primärschlüssels in jeder Tabelle auch noch etwas aus der Sicht der Verwendung eines SQL Servers anstelle einer JetEngine beisteuern.

Grundsätzlich werden Tabellen ohne Primarschlüssel als HEAP bezeichnet und in der DB Engine (SQL Server) auch als solches registriert. (select * from sys.indexes where type = 0)
Nun zählt sicherlich nicht das Argument, 'Haufen' ist ein etwas unschöner Begriff für eine Tablle und daher legt man besser einen PK an; andere Argument ist treffender.

Um jeden Datensatz einer Tabelle eindeutig zu identifizieren benötigt jede DB Engine - und Du auch - einen eindeutigen Schlüssel. Diesen Schlüssel gibt es grundsätzlich in jeder normalisierten Tabelle, ob nun zusammengesetzt aus mehrerern Spalten oder nicht.
Gibt es diesen nicht oder lässt sich dieser nicht logisch ableiten, sind Datensätze garantiert redundant und die Tabelle nicht normalisiert. Wir sind uns einig das redundante Datensätze erstmal nicht gewollt sind.
Was passiert nämlich wenn wir redundante DS akzeptieren?
Nehmen wir an, wir haben eine Tabelle mit Kunden und eine Tabelle deren Kontoguthaben. Ist die Kundentabelle nicht normalisiert / indiziert und beinhaltet damit doppelte Kundeneinträge, multipliziert sich das Kontoguthaben mit der Anzahl der Redundanzen des Objekts Kunde ( Was ich nebenbei gemerkt, toll finden würde, wenn meine Bank meine Kundennummer mehrfach abgelegt hätte )
Wenn wir also nach den Normalisierungsregeln die Tabelle(n) normalisiert haben, kristallisiert sich immer ein möglicher Kandidat / Kombination aus mehreren Spalten als PK heraus.
Um zunächst Redundanzfreiheit zu gewährleisten, sollten wir also im eigenen Interesse den PK setzten.
Warum einen PK und nicht einfach einen UNIQUE Index?
Weil die Tabelle immer noch ein Dasein als HEAP fristen muss?
Ein PK ist eigentlich nichts anderes als ein Unique Key der keine NULL Values zulässt, während der unique key zumindest einen NULL Value in der Schlüsselspalte akzeptiert. NULL ist bekanntlich nicht mit etwas zu vergleichen. Daher führt Select * from Tabelle where column = NULL immer zu nichts (Ausnahme, wenn SET ANSI_NULLS ON)
Das ist der Grund, warum immer IS NULL und nicht = NULL zu schreiben ist und Null + irgendwas immer Null ist. Es ergeben sich möglicherweise also mehr Ergebnisse als TRUE und FALSE bei einem Vergleich eines UNIQUE Keys - nämlich unbekannt, true and false (bei Nullability der Schlüsselspalte).
Eine unique Key scheidet also offenbar als eindeutiger Schlüssel einer Tabelle aus - da dieser insofern NULL nie eindeutig ist sondern unbekannt.
Setzten wir also einen PK (der bekanntlich nie Spalten mit Nullability akzeptiert); somit ist die Tabelle kein Heap mehr (was diese vielleicht freut), besitzt einen eindeutigen Schlüssel und ist garantiert frei von redundanten DS.
Mit der Anlage des PK wird auch ein B-Baum erstellt. Hier wird also ein Indexbaum aufgebaut, der den schnellstmöglichen Zugriff auf den gesuchten DS bietet. Man kann sich den B-Baum als Index eines deutschen Buches vorstellen (nicht amerikanischen Buchs - da ist das etwas anders).
Man sucht nach einem Begriff in der alphabetischen Reihenfolge und erhält eine Seitenzahl - mit dieser Angabe muss man also nicht mehr das Buch von vorne bis hinten durchlesen um den gesuchten Begriff zu finden.

Wenn man öfter mal Bücher liest, weiss man, dass - insofern man einen Begriff mit dem Buchstaben E sucht - eher in der ersten häfte des Indexes (B-Baum) zu suchen ist.
Wie die DB Engine, halbiert man den Index(baum) erstmal und schaut ob E größer als der Anfangswert und kleiner als der Endwert der ersten Blattebene ist - ist dem so, halbiert man die Hälfte wieder, und so fort.
Zwangsläufig stößt man auf den Buchstaben E oder auch nicht (wenn es halt keinen Begriff gibt, der mit E beginnt) und erhält so die Seitenzahl oder aus der Sicht der DB Engine die Pagenumber / Seitenzahl der Tabelle und die Recordnumber ( Tabellen sind in Seiten zerlegt 8192 kb groß - aber das führt aber etwas zu weit). Mit dieser Information schlägt man / DBEngine die Seitenzahl auf und wir fündig.
Das sollte ein weiterer Grund für einen PK sein.

Auf dem SQL Server gibt es etwas, dass sich clustered Index nennt - und dafür würde ich immer einen PK setzen. Der clustered PK hält den gesamten Datensatz auf der Blattebene bereit und muss daher nicht mehr über den Index in die Tabelle einsteigen, was sehr viel schneller geht. Zudem leiten sich alle weiteren Indexes von dem clustered primary key ab und suchen daher also nie mehr direkt in der Tabelle sonder immer in der optimierten Struktur des Indexbaums.

Kommen wir auf das Thema zurück in dem es darum geht den möglichen Kanditaten für den PK zu identifizieren. Direkt ausgesprochen: ein natürlicher Schlüssel ist der Feind eines jeden ERM.
Warum? Laden wir bespielsweise Kundendatensätze aus mehreren CRM Systemen verschiedener BusinessUnits in unserer Datenbank um dort ein zentrales Reporting zu ermöglichen, haben wir eine Menge Spass. Garantiert haben alle Units (bsp. auch Länder) eigene Instanzen der DB des CRMs - da diese fremde Daten nicht sehen wollen / sollen und die Performance schneller ist je weniger DS das DBMS bereithält.
Nun fängt jede Unit normalerweise mit der Kundennummer 1 an und wenn die Kundennummer 1.000 angelegt wurde gibt es ein Geschenk vom Chef *wink.gif*

Bei dem Versuch diese gleichwertigen Daten aus den verschiedenen System mittels ETL zu importieren, stehen wir vor dem Problem dass die Kundennummer zwar je Unit nicht aber global eindeutig ist (resultierende Probleme siehe weit oben). Nun kann man sich helfen indem man noch eine Spalte einfügt die die Kundennummer mit der Unit eindeutig macht - also ein Mehrfachschlüssel aus mindestens diesen beiden Spalten.
Ein Mehrfachschlüssel ist als PK nicht so gut, da dieser den B Baum aufbläht und immer diese Unbequemlichkeiten in den JOINS auftreten - wer schreibt schon gerne einen Join über zwei oder mehr Attribute - und welche DB Engine hat große Lust das ganze schnell auszuwerten? Dann kommt noch das Problem der Reihenfolge der Indizierung in den Spalten zum Tragen - erst die am stärksten ausschließende Spalte, wie hier die Kundennummer und dann die Unit oder umgekehrt. Am Ende kommt dann jemand mit einer Abfrage in der garantiert der IndexSeek nicht zieht weill man das Prädikat im Select auf die zweite Spalte im Index setzt und der Index damit nicht greift und eine sequenzielle Suche gestartet wird - was viel langsamer ist. Also einen zweiten UniqueIndex Not Null auf die selben Spalten im umgekehrter Reihenfolge? Klar, vorher noch in den Mediamarkt und einen 100 Terrabytes Festplatte und eine Menge RAM geholt um die Indexes zu speichern. Dumm nur, dass bei jedem Insert, Delete und Update der B Baum nun für alle Indexes immer wieder neu aufgebaut werden muss (Ausnahme Pad Index und Fill Factor niedrig setzen - aber auch schlecht) und das bei einem Masseninsert ziemlich lange dauert.

Nun kommt noch ein Kunde auf die Idee seine Steuernummer zu ändern, die Rechnungen müssen aber noch ein paar Jahre rückwirkend mit der "alten" Steuernummer und die neuen Rechnung mit der neuen Steuernummer erzeugt werden können. Dann lagern wir die Steuernummer halt in eine neue Tabelle aus und erstellen einen 1: N Beziehung, so dass der Kunden mehr Steuernummern haben kann. Schwierig mit dem datumsbedingten automatischen Wechsel selbiger. Und der Kunde zieht auch noch um. Also 1:N Beziehung für Kunden Adressen.

Das wir immer komplexer! Erstelle also einen SURROGATE Key (PK) mit dem Du den gleichen Kunden mit mehreren Kundennummern oder historische Stände speichern kannst und dennoch eindeutig die N Tabellen über den surrogate Key zuorden kannst.

Wenn Du Dich einmal mit Datawarehousing beschäftigst wünschst Du Dir nichts mehr als einen PK als surrogate key in jeder Tabelle*wink.gif*

Man kann noch Seiten zu dem Thema schreiben, sich Gedanken machen, was passiert wenn bps. Kundennummer alphanummerisch sind und wie das dann mit dem Index im Vergleich zu einem nummerischen Index aussieht, aber ich denke eins sollte klar sein:

Setzte einen PK in jeder Tabelle - am besten einen surrogate key - und das auch in deiner N Tabelle!

 

Mein lieber Torsten,
sowas von fundiert. Ich habe zwar nicht alles ganz genau verstanden, aber das Wesentliche bestimmt. Danke.

Vielleicht könntest Du mir eines verraten. Ich hab' mir so ausgedacht, daß ein Feld, welches nur Zahlen enthält, wesentlich schneller durchsucht werden kann als eines mit alphanumerischen Zeichen. Es gibt schließlich nicht soviel Ziffern wie Buchstaben.
Stimmt das? (Nicht, daß es weniger Ziffern als Buchstaben gibt, sondern die Suchgeschwindigkeit.)

 

Klasse Thema. Dank an alle.*Smilie

Bestimmt habe ich da was überlesen: Wie erstelle ich am besten einen Surrogate Key. Der Sinn eines solchen ist mir auch klar... sollte ich also den Tip von Strausto auch ab jetzt beherzigen?

@Atrus2711

Zitat der Woche. Mit Deiner Erlaubnis auf meinem Handy gespeichert.*Smilie

@josef P.
Erinnerst Du Dich...wir beide hatten einen ähnliches Thema, aber eben nur was das Modell angeht. Und nich um die Grundsatzfrage. Das geht es auch um das "Super-Objekt" Personen und weiterhinten um die Darstellung von Personenbeziehungen. Mandanten und Mitarbeiterdaten werde ich aber auch weiterhin in sep. tabellen speichern.*tongue.gif*

Wer mag: http://www.ms-office-forum.de/forum/...d.php?t=227414