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

Verwende nimmerische werte anstelle von strings. Integer nimmt auf dem sql Server 4 Byte in anspruch in kann so einen Bereich von -2 hoch 31 bis 2 hoch 31 speichern. Ein string würde dafür 11 Byte brauchen. Der Index ist also platzsparender zu speichern mit mehr Informationen pro indexseite und daher schneller im Aufruf da mehr Informationen je i / o und damit eine schnellere suche. Ein surrogate key erstellst du in access über die spalteneigenschaft autowert

 

Dank dir Torsten, dass du die Diskussion mal wieder auf die Sachebene zurückbewegt hast. *Smilie Für die von dir beschriebenen Szenarien wie z.B.

sind deine Argumente stichhaltig und führen zu eingedeutigen Schlüssen, wenn man keine ALTERNATIVE Lösung parat hat (s.u.).

Aus der Sicht eines Access-'Anfängers' (ich hoffe Steve verzeit mir) der seine ersten Gehversuche macht, wobei es um die Erstellung einer ganz einfachen Vertriebsdatenbank zu handeln scheint (meine persönliche Interpretation auf Grund der Tabellenbeschreibung), erscheint mir die Diskussion etwas überzogen. "Den Fragenden da abholen wo er steht" o.ä.
ist meiner Erfahrung nach oft hilfreicher, als die 'perfekte'*rolleyes.gif* Lösung, welche alle Eventualitäten berücksichtigt, anzubieten.

Anmerkung: hätten sich einige die Mühe gemacht, dem ersten Link von Martin (Atrus) in #7 zu folgen wäre es vielleicht nicht so hitzig geworden *wink.gif* mein Lieblingszitat aus dem Artikel zur Frage "Was, wenn man doch mal einen Fehler gemacht hat" ist

*wink.gif*

PS: bei der Planung der Nummernkreise kann das im Zitat von Torsten beschriebene Problem alternativ Lösen. (z.B. alle Kundennummern 5-stellig. Absatzgebiet A 1.Stelle = 1, Absatzgebiet B 1. Stelle = 2...)
Ein Wechsel der USt-ID kommt IMO nur bei Umwandlung, Rechtsformwechsel, Verschmelzung, Auf-, Abspaltung, Einbringung von Unternehmen in Frage. Ich jedenfalls habe dann einen neuen Kunden mit neuer Kundennummer (evtl. mit dem Vermerk 'ehemals XY GbR') da IMHO z.B. Rechnungen anders faktoriert werden müssen. Die 'Steuernummer' taucht auf meine Rechnungen nicht auf.

PPS: Kurzen Dank noch an Josef für den Hinweis in #8 ... bin noch ganz am Anfang, muss noch viel lesen und lernen *wink.gif*

 

Und was ist wenn wie das bei allem Systemen die ich bisher kennengelernt habe, als Kundennummer eine einfacher inkrementeller systemgenerierter Wert dient der bei dem nächsten neukunden einfach hochgezählt wird. Mit deinem Ansatz setzt du voraus dass man die kundennummer nach einem Muster geniert. Ich behaupte mal das geht eher selten. Das Muster ist ja eigentlich nichts anderes als ein in einer Spalte zusammengesetzter Index aus mehreren imaginären schluesselspalen die den DS eindeutig machen. Warum keinen schlanken Index auf einen Integer ?was ist wenn die festgelegte eine Stelle fuer bsp BusinessUnit nicht mehr reicht weil das geschäft wächst und du plötzlich 11 businessunits hast? Etwas anderes in richtung steuernummer. Wir hatten mal den Fall, das ein System nur 999 produktnummern zuließ . Also waren wir gezwungen irgendwann alte Produktenummern zu uberschreiben. Hätten wir nicht einen surrogate key beim Import der Daten neben der produktnummer im importierenden System erzeugt und den Link über die produktnummer gemacht und nicht über den nicht natürlichen key und damit indirekt eine Historie erzeugen können wären alle auswertungen falsch. Das alte Produkt hatte die produktnummer eins und den surrogate key 1 und das neue Produkt 1 den surrogate key 1000. Der Benutzer hat nur den produktnamen in den auswertungen zu sehen bekommen der folglich richtig war. Der natürliche Schlüssel produktnummer ist damit unwichtig und schlimmer noch kein Kandidat für einen PK. Ich wusste nicht dass du das Beispiel mit der steuernummer vor dm hintergrund der rechtsfrage bewertest und wir haben die gleiche kundenummer mehrfach in einem System wobei zunächst immer nur der jüngste DS angezeigt wird im system aber mehrere DS stehen die sich unterscheiden nur hält nicht in der kundennummer um eine Historie aufzugeigen

 

\@Marsu:
Nummernkreise sind die Pest:

• Ein Nummernkreis läuft irgendwann über, weil er die Nummern implizit begrenzt.
• Sprechende Schlüssel (1. Stelle bedeutet etwas, 2. Stelle bedeutet etwas etc) begrenzen die künftige Entwicklung. Wenn ich z.B. die Artikelgruppe in der 1. Stelle ablege, bin ich auf 10 Artikelgruppen begrenzt.
• Sobald das Prinzip durchbrochen werden muss, entstehen Artefakte. Und dann ist eh keine Verlass mehr auf die 1. Stelle bzw. die Kreise.

Primärschlüssel haben nur einen Job: sie müssen eindeutig sein. Sie müssen nicht

• einen realen Wert abbilden (oder hat der Kunde die Kundennummer auf der Stirn stehen?)
• regelmäßig sein (gleich lang ,einheitlich geformt, fortlaufend, lückenlos, ...)
• Geschäftslogik durchsetzen; dafür können eindeutige Indizes dienen. Der Primärschlüssel ist clustered, d.h. er gibt die physikalische Reihenfolge der Sätze auf der Platte an.

Ich bin ein großer Freund von GUIDs als Schlüssel, auch wenn Access die nicht allzugut verarbeiten kann. Aber man kommt endlich los von der Denke: "der nächste Kunde ist Kundennummer +1".

Und alles - alles, alles, alles! - was zu einem Kunden, Artikel etc "bekannt" ist und auch morgen noch abrufbar sein soll, muss in Felder der entsprechenden Tabelle. Nicht in die Stellen (1.,2.,3.) der Kunden- oder Artikelnummer.

Als Banker kann ich ein Lied davon singen: Bis vor ein paar Jahren wurden Wertpapiere mit der sog. WKN (Wertpapierkennummer) identifiziert, z.B. 555750 = Deutsche Telekom Aktien. Irgendein Vollpfosten hat sich dabei überlegt:

• WKNS sind 6stellig (1. Fehler, da dadurch max 1 Mio WKNs möglich sind)
• 1. Stelle 0 wird nicht vergeben (2. Fehler: 100000 WKNS fallen weg)
• 1. Stelle mit Wert 1-4 heißt: Anleihe
• 1. Stelle 5-9 heißt: Aktie oder Investmentfonds

Nun hielt dieses System ein paar Jahre. Da die WKNs aber wegen Dokumentationspflichten nicht "recycled" werden konnten, d.h. auch "ausgelaufene" Papiere haben ihre WKN behalten, wurden die irgendwann knapp. Dazu kam der Boom im Wertpapiermarkt: jede Garagenfirma warf Papiere auf den Markt, die mit WKNs versehen werden mussten. Und irgendwann, etwa so um ~1993, mussten die ersten Anleihen eine Aktiennummer ("falsche" Nummer an 1. Stelle) bekommen, weil einfach keine Anleihenummer mehr frei war. Ein Artefakt war entstanden. Jeder, der bis dahin an der ersten WKN-Stelle die Wertpapierarten unterschieden hat, war jetzt am Ende, denn es war kein Verlass mehr drauf. Man stellte um auf ein anderes System (ISIN). Ich hatte damals die Ehre, bei den Tests von bankweiten WP-Systemen diesen Mist auszubaden.

Die Wertpapierart ist eine Eigenschaft des Papiers. Sie kann (wenn man die Entwicklung anguckt) jeden Wert annehmen. Jeder, der da begrenzt und limitiert, handelt fahrlässig und darf dann früher oder später sein System umstellen. Oder andere dafür bezahlen *grins

Meide sprechende Schlüssel und Nummernkreise. Sie sind von Übel.

Gruß

 

Ich denke die Argumente überzeugen und hinsichtlich der Tatsache dass ein surrogate key nur für das System einen geringen Mehraufwand darstellt (wird ja systemseitig erzeugt) sollte man sich dafür entscheiden und nicht irgendwelche komplizierten Musterschlüssel generieren, deren Generierung zudem noch großen Aufwand und eine Validierung nachsichziehen.

 

\@Martin

Sehr gute Erläuterungen Deinerseits *wink.gif*

 

\@Strausto: Schöne Beiträge! *Smilie

Habe dazu auch mal einen sehr schönen Artikel genau zu diesem Thema gelesen, mit sehr vielen praxisorentierten Szenarien. Leider kann ich diesen nicht mehr finden (Firefox Bug mit Bookmarks sei Dank *grrr*).

@Marsu: Ich bin da nicht deiner Meinung, gerade solche schwerwiegenden Entscheide würde ich persönnlich eben einem Anfänger beibringen. Ist doch immer das gleiche Szenario mit Access-Anwendungen, klein Angefangen, irgendwann isses ein Mammut-Projekt. Da ist es schön, wenn solche "Kleinigkeiten" von Anfang an passen. Datenbankübergreifende PK-Mutationen machen kein Spass und man zögert die "Mutation" immer weiter hinaus. Vor allem weil durch die Verwendung der Kd-Nr als PK eben die Tabelle nie verknüpft wird, sondern die Kunden-Nummer immer direkt verwendet wird vom Schlüssel. Am meisten kommt dies in den ganzen Auswertungen zum tragen, welche sehr viel Zeit für die Änderung beanspruchen.

Die Adressverwaltung ist in jeder DB ein äusserst zentrales Modul, welches zudem sehr schwer einfach mal so anzupassen ist, weil es eben in jeder Ecke der Anwendungen seine Ableger hat. Deshalb bin ich der Meinung, dass dieses eben möglichst flexibel und dennoch sicher ausgelegt ist.

Zu deinem Szenario: Grundsätzlich möchtest du ja pro Kunde, auch wenn die Firma vorher anders geheissen hat, die Statistik sehen oder? Es ist doch mühsam, wenn man dann immer zwei anschauen muss. Plötzlich ist sogar der Vermerk weg und man weiss nicht mehr welcher das war.

@All:
Es gibt auch noch andere Szenarien. Mal ein paar welche ich selber schon hatte:
zum Beispiel wird plötzlich mal erwünscht, dass Aussenstellenmitarbeiter neue Kunden erfassen, mit ihm Aufträge und dergleichen. Allerdings soll auf die teure Mobile-Netzanbindung und all den Investitionen die damit zusammenhängen, verzichtet werden. Folglich kann man dem Kunden noch keine Kunden-Nummer zuteilen. Durch die Verwendung von SurrogateKeys, zum Beispiel GUID's, können diese immer ohne grosse Code-Hexereien direkt in die Datenbank übertragen werden. Per simplen Add-Methoden. Lediglich die Reihenfolge muss stimmen. Dabei muss man sich keine Gedanken über die Neugenierungen, wiederauslesen von AutoWerten in der HauptBackend machen um die Detaildatensätze zu Verknüpfen.

Mehrfachmandanten: Zum Beispiel im Detailhandel und Verkäufen auf Messen und dergleichen kommt es sehr oft vor, das Firmen mehrere eigenständige Verkaufsfirmen haben um mehrere Messeplätze zu erhalten und/oder ein breiteres Angebot auf verschiedene Firmen zu Verteilen. Diese möchten aber um Adressen möglichst aktuell zu halten, für Einladungen und dergleichen, einen gemeinsamen Adresstamm haben, vor allem aber für die Blacklist, also nicht wirklich zahlungswillige Kunden. Die KundenNummer bleibt aber pro Mandant. Sei es weil eine Firma zusätzlich aufgekauft wurde oder aus anderen Gründen. Da geben sich unweigerlich "Duplikate" in den Kundennummern, wenn diese in der gleichen Tabelle gehalten werden.
Auch kann so eine Auswertung des kompletten Kunden, über sämtliche Firmen erfolgen.

Es gibt genau für dieses Szenario in der Schweiz (Wohl auch im nahen Ausland) eine einzige käufliche Software, welche alles mögliche für die Branche abdeckt. Die ist manchmal ziemlich kompliziert, teilweise etwas veraltet (Im Sinne von Ergonomie und Speicherung der Daten) und die Reportingfähigkeiten und Auswertungen sind beschränkt. Haben dafür ein gutes Export-Modul, womit man dies selber nachrüsten kann mit externen Anwendungen. Mittlerweile bieten sie auch ein automatisches externes System an welches immer über Nacht eine MySQL-Datenbank für die Auswertung erzeugt.
Man muss einfach immer erst die Exports fahren vor der Auswertung. Zugriff auf die DB ist ohne wirklich eigehende Strukturkenntnis kaum möglich, da keine SQL-Sprache eingesetzt wird und die Verknüpfungen alle im Kopf stattfinden. Fast jeder setzt die Software aber ein, weil es eben keine andere gibt die genau dieses wichtige Feature bietet, lebt man mit ein paar Unanehmlichkeiten. Im Endkundenverkauf ist die "Filterung" von nicht zahlungswilligen Kunden etwas vom wichtigsten, häufig gehen die schwarzen Schafe nämlich von Firma zu Firma. Ergebnisse von Betreibungsanfragen können so direkt zentral abgelegt werden, einer der nicht bezahlen will oder sich jede Menge zeit lässt auch. Früher haben wir immer alles in unseren zwei Firmen nachgeschaut, jetzt schaut man das eben einmal nach. Die Zeitersparniss ist enorm.
Einige Firmen in der Branche haben 5 und mehr eigenständige Firmen, für die wäre es noch viel weniger lustig, immer den Adressstamm von allen 5 oder gar zehn zu durchforsten und Adressupdates zu machen. Ist zudem Fehleranfällig.

Da kränkeln eben alle mir bekannten "grösseren" Software, ausser dieser einen und das was ich für unseren Hauptbetrieb (Produktion) verwende, meine eigene. Nur ist es nicht unser Geschäft, Software zu vertreiben, vermarkten und Supporten. Dazu fehlt die Zeit und die Erfahrung.
Sicher gibt es noch andere, kleine Anbieter welche man einfach nicht kennt. Dabei ist es eigentlich gar keine grosse Hexerei, den Stamm zentral zu halten. Aber es ist eben nicht "normal" und nicht einfach mal so in grossen Umgebungen zu ändern.

Darum verstehe ich nicht, warum man sich solche Wege von Anfang an verbauen soll, gerade die Kunden welche keine der bekannten Anwendungen brauchen können, brauchen oder wünschen sich die nötige Flexibilität früher oder später und das fängt eben in erster Linie mit der Kontaktverwaltung an. Ich kenne sehr viele Firmen mit denen wir zu tun haben, welche sich so etwas schon gewünscht hätten und nun einfach mit diversen Duplikaten und teilweise externen Hilfsmittel zu arbeiten.

Alle solchen Szenarien benötigen aber eben Surrogate-Keys und eine unkonventionelle Art an die Sache heranzugehen um die nötige Flexibilität zu erhalten. Dieser Nischenplayer hatte nur deshalb Erfolg, weil er eben genau das bietet, was sämtliche grossen, eigentlich besseren Softwares, nicht bieten, in einigen Branchen wäre es schön sowas zu haben, in dieser ist es fast unerlässlich.

EDIT: @Martin, fein geschrieben. Hätte ich nicht treffender können. *biggrin.gif*

 

Hallo @Marsu und alle anderen Profis,

Ja, die Antworten gingen sehr ins Detail. Es ist aber toll, dass hier soviel Profis im Forum sind.

Ich fasse zusammen:
- Jede Tabelle sollte einen Primärschlüssel haben
- Der Schlüssel sollte den Typ Char haben
- Wenn möglich nicht den Autowert Schlüssel einsetzen, sondern einen anderen Surrogatschlüssel verwenden. Leider ist das nicht möglich, da Laien die DB bedienen und auch Datensätze hinzugefügt werden müssen.

Viele Grüße!
Steve

 

Das fasst du falsch zusammen:

Char ist ein Datentyp auf de SQLServer, in Access heißt der "Text".

Text als Key ist technisch möglich, aber (v.a. bei großen Datenmengen) unklug. Text wird sehr viel langsamer verglichen als numerische Werte, das merkst du bei jedem Join (und Keywerte werden oft verjoint). Und Textwerte riechen danach, dass der Anwender sie selbst eingibt und/oder ändern kann. Das zieht sich dann durch die ganzen Datenbank.

Edit: Nimm Autowerte oder unveränderliche Zahlenfelder. /EDit GUIDs wären noch besser, sind aber in Access nicht einfach zu handhaben.

Hast du meine beiden Links in #7 gelesen?

HTH

 

Und @Steve: Gerade wenn und weil Laien an der DB arbeiten, kann die gar nicht "wasserdicht" genug sein. Du musst mit den unmöglichsten Dingen rechnen.

Die einfachen Dinge sind manchmal die schwersten. *Smilie

 

Hallo Atrus2711

sorry, da habe ich mich leider verschrieben. Eine 1:n Verknüpfung sollte über Autowert --> Zahl (Long Integer) definiert sein.

 

@Martin: warum ist ein GUID als Surrogat besser?
Ich halte für einen Surrogat-PK Autowerte besser als GUID, da sie schön hintereinander in den Index geschrieben werden. Bei einem GUID muss immer "umsortiert" werden.

Ein GUID bringt allerdings bei Verwendung als FK Vorteil, wenn er im FE erzeugt wird: Man kann im FE bereits den Detail-DS inkl. den 1:N-DS in einem Zug anlegen und muss nicht auf das Ergebnis des Autowertes der Haupttabelle warten.

 

\@Marsu:

Es gibt keine einfache Vertriebsdatenbank. Realität ist komplex.

Man kann natürlich eine vereinfachte Wirklichkeit in der DB abbilden, um sich da einzuarbeiten. Aber das ist dann keine produktive DB. Ohne Kenntnisse in DB-Enwticklung aber kann/sollte man keine DB entwickeln, die produktiv werden soll.

Ich vergleiche das mal mit einem Bauingenieur: natürlich ist es "Kleinkram" für ihn, eine Hundehütte in der Statik durchzurechnen. Aber daran lernt er Statik. Und erst wenn er die Statik kann, kann er es wagen, größere Häuser zu bauen. Er riskiert sonst, dass die "ernsten" Gebäude unter der eigenen Last zusammenbrechen.

 

Auch ich arbeitet (wie an meinen Beiträgen zu erkennen) sehr oft und gerne mit GUID's. Es gibt ein paar Fallstricke welche es zu beachten gibt, dazu gehören:

Unterschiedliche Längen
Die Darstellung geht von 45 über 38 über 36 über 32 Zeichen. Dafür habe ich mir eine Umsetzungsfunction gebaut welche automatisch von einem in den anderen übersetzt. Access verwendet zur Anzeige 38, intern aber eigentlich 45, aktzeptiert aber auch die Länge 38. Andere Programme arbeiten oft mit der Textform und der Länge 36, ohne { und }, wieder andere nehmen auch noch die Bindestriche raus, gibt dann 32. Diese habe ich schon öfter in Datenmatrixen (eine Art Barcode) angetroffen.

Anbei ein Beispiel:
45: {guid {69DBBB40-A01D-42F3-B8DC-47FA359A4F31}}
38: {69DBBB40-A01D-42F3-B8DC-47FA359A4F31}
36: 69DBBB40-A01D-42F3-B8DC-47FA359A4F31
32: 69DBBB40A01D42F3B8DC47FA359A4F31

Interne StringFromGUID-Function
Die VBA-Interne StringFromGUID bring bei NullTypen eine Fehlermeldung, was lästig ist wenn man sie in einer Abfrage bzw. Datengrundlage für ein Form braucht.

Verknüpfung Haupt/Subform
Die direkte verknüpfung ist nur teils teils möglich, weil Access die GUID's nicht immer sauber umwandelt. Daher ist es teilweise nötig, in der Datengrundlage, also der Query, die eigene fStringFromGUID einzusetzen.

Zugriffe auf Recordsets
Innerhalb von Formularen kann man nicht direkt auf die Feldwerte zugreifen, also man kann nicht Me!FeldName verwenden. Auch nicht stringfromguid(Me!FeldName), beides gibt kein richtiges Ergebnis. Stattdessen muss man auf das Feld im Recordset des Formulars die GUID auslesen.

Suchen ersetzen
Nach GUID kann nich gesucht werden inenrhalb abfragen.

EDIT:
Vorteile
- Zusammenführen von Daten problemlos möglich --> Add-Methode
- Rezepturen, Vorlagen etc. können einfach dupliziert werden für die entsprechende Anwendung, die PK's werden in den jeweiligen Add Methoden generiert und können den FK's mit übergeben werden ohne das der generierte autoWert ausgelesen werden muss.
- Immer gültige ID's, über die komplette Datenbank. --> Man kann so auch leichen aufspüren.

 

\@Josef:

Wohl wahr und eigentlich auch zu berücksichtigen. Mir ist aber angenehmer, eine GUID im Frontend zu erzeugen, als auf die "serielle" ID des Backend zu warten. V.a. wenn der Server am anderen Ende der Welt steht.

Ich glaube auch, dass dein Einwand der schönen Reihenfolge nur die Schreibvorgänge beschleunigt. Der B-Tree muss eh neu ausbalanciert werden, da auch "serielle" Folgen entartete Bäume erzeugen. Vielleicht entarten sie nicht ganz so schnell wie GUID-"Folgen".

Bei einer Ein-Mann-DB oder bei einer DB, die nur vom LAN aus genutzt wird, ist ein Autowert besser, aber man muss dann halt neue IDs erstmal auslesen.