Hallo,
kann ich einen zusammengesetzten Primärschlüssel als Fremdschlüssel innerhalb der Beziehungserstellung verwenden? Der Primärschlüssel soll aus Datentyp Zahl und kurzen Text bestehen.
Hallo,
lasse es sein, ist in der Handhabung viel zu sperrig. Es sind ja dann auch 2 Fremdschlüssel.
Nimm einen Autowert als PS und gut ist.
Zitat von: AccessDo66 am Februar 14, 2023, 14:54:22kann ich einen zusammengesetzten Primärschlüssel als Fremdschlüssel innerhalb der Beziehungserstellung verwenden?
Ja, in dem Dialog, der bei der Erstellung des Fremdschlüssels eingeblendet wird, kannst du mehrere Spalten auswählen.
MultiColumnFK.png
Zitat von: MzKlMu am Februar 14, 2023, 14:59:07lasse es sein, ist in der Handhabung viel zu sperrig. Es sind ja dann auch 2 Fremdschlüssel.
Nimm einen Autowert als PS und gut ist.
Es ist dann immer noch ein Fremdschlüssel, aber mit zwei Spalten.
Ja, es ist sperriger in der Handhabung, aber es gibt durchaus Szenarien, in denen beide FK-Spalten in der N-Tabelle erforderlich sind.
Hallo,
Zitat von: PhilS... in denen beide FK-Spalten in der N-Tabelle erforderlich sind.
Das hat ja mit einem PS zunächst mal nichts zu tun. Man kann die beiden Spalten auch ohne FK Atribut haben und zusätzlich den echten FK zum Autowert. Ggf. kann es sinnvoll sein über die (vorher) als FK vorgesehen Felder einen eindeutigen zusammengesetzten Index zu legen.
Die allermeisten Anwender vermeiden zusammengesetzte PS.
Ich wüsste kein Szenario wo man einen zusammengesetzten PS wirklich braucht, die Betonung liegt auf braucht.
Dass zusammengesetzte PS der reinen Lehre entsprechen, ist mir klar, aber die reine Lehre ist auch nicht immer sinnvoll bzw. praktisch.
Aber letztendlich muss das jeder machen wie er das für richtig hält. Ich gebe hier nur meine Meinung kund. :)
Ich werde es wohl lassen. Aber der Primärschlüssel muss eine Zahl sein? Verschiedene Tabellen und immer eine ID als Primärschlüssel in Form von 1,2,3 etc. Das finde ich wenig Aussagekräftig. Wie schreibt Ihr aussagekräftige Primärschlüssel?
Zitat von: PhilS am Februar 14, 2023, 16:14:02Zitat von: AccessDo66 am Februar 14, 2023, 14:54:22kann ich einen zusammengesetzten Primärschlüssel als Fremdschlüssel innerhalb der Beziehungserstellung verwenden?
Ja, in dem Dialog, der bei der Erstellung des Fremdschlüssels eingeblendet wird, kannst du mehrere Spalten auswählen.
MultiColumnFK.png
Zitat von: MzKlMu am Februar 14, 2023, 14:59:07lasse es sein, ist in der Handhabung viel zu sperrig. Es sind ja dann auch 2 Fremdschlüssel.
Nimm einen Autowert als PS und gut ist.
Es ist dann immer noch ein Fremdschlüssel, aber mit zwei Spalten.
Ja, es ist sperriger in der Handhabung, aber es gibt durchaus Szenarien, in denen beide FK-Spalten in der N-Tabelle erforderlich sind.
Das mit dem Dialog funktionierte bei mir nicht. Ich hatte aber auch zwei verschiedene Datentypen.
Zitat von: AccessDo66 am Februar 14, 2023, 17:28:45Aber der Primärschlüssel muss eine Zahl sein? Verschiedene Tabellen und immer eine ID als Primärschlüssel in Form von 1,2,3 etc. Das finde ich wenig Aussagekräftig. Wie schreibt Ihr aussagekräftige Primärschlüssel?
Ein Primärschlüssel muss nicht zwingend eine Zahl sein. Die Datentypen in beiden verbundenen Tabellen müssen nur identisch sein.
Ein Primärschlüssel hat die Aufgabe eindeutig zu sein. Ob er "aussagekräftig" ist spielt eigentlich keine Rolle, weil er vor allem auf technischer Ebene von deinem Programm verwendet wird. Wenn du eine "schöne" eindeutige Kennung für die Benutzer haben willst, sollte das besser eine zusätzliche, eindeutige Spalte sein.
Zitat von: MzKlMu am Februar 14, 2023, 16:46:43Das hat ja mit einem PS zunächst mal nichts zu tun. Man kann die beiden Spalten auch ohne FK Atribut haben und zusätzlich den echten FK zum Autowert.
Das hat schon mit dem PS zu tun. Der PS stellt sicher, dass du keine Kombination von Werten eingeben kannst, die in der 1-Tabelle der Relation nicht existiert.
ZitatWie schreibt Ihr aussagekräftige Primärschlüssel?
Gar nicht, siehe #6
Zitatdie in der 1-Tabelle der Relation nicht existiert.
Sofern denn die RI eingeschaltet ist.
Zitat von: Beaker s.a. am Februar 14, 2023, 17:47:39Sofern denn die RI eingeschaltet ist.
Der Begriff "Fremdschlüssel" impliziert zwingend Referenzielle Integrität, andernfalls ist es kein Fremdschlüssel, sondern nur ein minderfunktionaler Fliegendreck. ;-)
O.K., bei dir und mir. Aber es gibt ja immer solche, die das übersehen.
Ich habe allerdings auch übersehen >:( , dass die RI bei ihm gesetzt ist.
Bezüglich Beziehung und RI: Die Arbeit mit dem Beziehungsfenster-Assistenten vermittelt den Eindruck, dass Beziehungen keine RI benötigen, sondern dass die eine Zugabe ist. Sehr viele sind dann sehr assistentengläubig. Damit erspart man sich eine Auseinandersetzung mit Fachwissen, bzw. lehnt man eine solche gleich ab, weil man ja schon etwas "funktionierend" und also richtig gemacht hat.
Dass Flossen an den Füßen auf dem Lande anders funktionieren als im Wasser - solch ein Erkenntnisprozess tritt desweilen erst sehr viel später ein.
Wenn man eine Beziehung nativ mit Code erzeugt (DDL, DAO, ADOX), dann wird es schwer bis unmöglich sein, eine RI als Attribut nicht zu erzeugen.
Hallo,
Zitat von: AccessDo66Aber der Primärschlüssel muss eine Zahl sein? Verschiedene Tabellen und immer eine ID als Primärschlüssel in Form von 1,2,3 etc. Das finde ich wenig Aussagekräftig.
Der PS sollte eine Zahl sein (muss aber nicht). Mit Zahlen in Schlüsselfeldern kann Access am Besten umgehen.
Und aussagefähig muss ein PS schon gar nicht sein, im Regelfall ist der PS für den User auch nicht zu sehen.
Ergänzung zur Schlüssel-Diskussion:
Tabellen sind physisch, zumindest nach Komprimieren, nach dem Primärschlüssel sortiert. Eine brauchbare Reihenfolge ist für manches nützlich. Das wäre ein Pro für einen "aussagekräftigen" Primärschlüssel.
Schlüssel werden sehr häufig für vergleichende Operationen verwendet. Beim Verknüpfen zweier Tabellen werden ja Übereinstimmung von Primär- und Fremdschlüssel gesucht. Weitere vergleichende Operationen, die auch alle gerne durch Indizes unterstützt werden, sind Filtern, Sortieren, Gruppieren und teilweise Aggregieren.
Beim Vergleichen ist es in Anbetracht der Masse an Operationen (jeder Datensatz der einen Tabelle gegen jeden Datensatz der anderen Tabelle) hinsichtlich des Aufwandes und damit der benötigten Zeit nicht unerheblich, ob da 4 Byte gegen 4 Byte (Long) verglichen werden müssen oder vielleicht 20 Byte gegen 20 Byte (bei einem kurzen Text / 10 Byte + 2 Byte je Zeichen). Ein Mehrfelder-Schlüssel stellt sich bytemäßig auch etwas breiter auf.
Da in Abfragen Tabellenverknüpfungen (JOIN's) massenhaft benutzt werden, wenn auch sonst vielleicht nicht viel an zusätzlichen Operationen passiert, liegt hier das Pro eindeutig auf nichtssagenden einfachen Ganzzahlen und Einfachschlüssel.