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

Helfe beim Thema Primärschlüssel in jeder Tabelle zwingend? in Microsoft Access Hilfe um das Problem gemeinsam zu lösen; Hallo zusammen, ich stelle mir gerade die Frage, ob bei einer 1:n-Beziehung beide Tabellen einen Primärschlüssel haben müssen/ sollen. Nehmen wir... Dieses Thema im Forum "Microsoft Access Hilfe" wurde erstellt von steve005, 25. Oktober 2008.

  1. Primärschlüssel in jeder Tabelle zwingend?


    Hallo zusammen,

    ich stelle mir gerade die Frage, ob bei einer 1:n-Beziehung beide Tabellen einen Primärschlüssel haben müssen/ sollen.

    Nehmen wir folgendes Beispiel an:

    Tabelle 1:

    Primärschlüssel Kundennummer: Typ Text - nicht Autowert
    Nachname: Typ Text
    Vorname: Typ Text


    Tabelle 2 Produkte:

    Kundennummer - Typ Text
    Produkt - Typ Text
    Kaufdatum - Typ Datum/Uhrzeit

    In der Tabelle 2 ist das Feld Kundennummer mit einem Index versehen, mit Option doppelte Werte. Definition einer 1:n Beziehung über das Feld Kundennummer.

    Sollte die Tabelle 2 zusätzlich mit einem Primärschlüssel ausgestattet werden? In diesen Beispiel Primärschlüssel mit Mehrfachindex über Kundennummer+Produkt+Kaufdatum?

    Hat die Definition eines Primärschlüssels in der Tabelle 2 Vorteile?

    Vielen Dank im voraus!

    :)
     
    steve005, 25. Oktober 2008
    #1
  2. Ich persönlich würde die Kundennummer nicht als Primärschlüssel nehmen, sondern als Feld mit eigenem Index ohne Duplikate.

    Das ergibt A eine "Schnellere" Verknüpfung, spart B Daten und C ist es generell eher unvorteilhaft "Geschäftsdaten" als Verknüpfungstypen zu verwenden, da sich diese Eigenschaften ändern können, erst nach aktivierung zugeteilt werden sollten usw. Weiter muss bei einer Änderung dieser Daten in einem Datensatz, nicht aber durch die komplette Datenbank durchgeändert werden. --> Stichwort referentielle Integrität, Aktualisieren. Die Verknüpfungsdaten bleiben bestehen, es ändert sich nur ein Feldwert. Dadurch gibt es sicher auch keine probleme mit gesperrrten datensätzen usw.

    Ich persönlich finde das jeder Tabelle ein Primärschlüsselfeld gehören sollte. In M:N Beziehungen kann man sich streiten ob da en Mehrschlüsselfeld oder doch lieber ein eigener zum Zuge kommen sollte. Ich mag lieber eigene.
     
    WeinGeist, 26. Oktober 2008
    #2
  3. Hallo WeinGeist,

    das verstehe ich nicht ganz. Die Kundennummer ist doch in Tabelle 1 eindeutig, warum dann zusätzlich ein ID-Feld mit Typ Autowert anlegen?

    Ich definiere eine 1-N Beziehung über das Kundennummer und setze "mit referentielle Integrität" und "Aktualisierungsweitergabe" und "Löschweitergabe" auf True.

    Ist dagegen etwas einzuwenden?
     
    Zuletzt von einem Moderator bearbeitet: 7. Januar 2021
    steve005, 26. Oktober 2008
    #3
  4. Primärschlüssel in jeder Tabelle zwingend?

    die Gründe habe ich doch schon genannt. Post lesen *wink.gif*
     
    WeinGeist, 26. Oktober 2008
    #4
  5. FW
    FW
    ... um auf Deine Frage zu antworten: Nein, es besteht keine Notwendigkeit, einen Primärschlüssel festzulegen. Es ist aber sinnvoll, einen eindeutigen Schlüssel für die Felder festzulegen, deren Inhalte nicht mehrfach vorkommen sollen. Nur mit einem eindeutigen Schlüssel in der Haupttabelle kann auch eine referentielle Integrität mit einer Detailtabelle erstellt werden!
    Ansonsten ist es natürlich so, dass ein Rechner schneller (Ganz-)Zahlen als Zeichenketten verarbeiten kann, was auch für Schlüsselfelder gilt!
    Wenn Deine Kundennummer also nicht numerisch ist, dann ist es spätestens bei großen Datenmengen oder komplexen Abfragen hinsichtlich der Verarbeitungsgeschwindigkeit deshalb sinnvoll, stattdessen einen numerischen Schlüssel zu verwenden. Dient ein Textfeld als Schlüssel für die referentielle Integrität, so muss hier auch gesehen werden, dass durch den Fremdschlüssel dann unnötig große Datenfelder mitgeführt werden, wodurch die DB bei großen Datenmengen unnötig "aufgebläht" wird.
    Die Aussage von WeinGeist
    ist in diesem Zuammenhang natürlich Quatsch! Sobald eine referentielle Integrität erstellt werden kann und Aktualisierungs- und Löschweitergabe aktiviert werden, werden entsprechende Änderungen in der Haupttabelle automatisch auch in der Detailtabelle vorgenommen und hierfür bedarf es lediglich eines eindeutigen, nicht aber unbedingt eines Primärschlüssels...
     
  6. Anderer Meinung alsdie Geister dieser Welt zu sein könnte gefährlich werden aber ich riskier es mal.
    Der Primärschlüssel dient ja in erster Linie der eindeutigen Identifizierung eines Datensatzes. Von daher gibt es wohl in einer Kunden/Lieferantentabelle nichts besseres als jeweilige Nummer. Mit der einen Einschränkung - da geb ich Urs gerne Recht - werden die Nummernkreise mal umgestellt hat man etwas Arbeit (die sich bei ordentlicher referentieller Integrität, Atualisierungs-und Löschweitergabe in Grenzen hält oder gar nicht ins Gewicht fällt).
    Für die zweite Tabelle ist nicht unbedingt ein PK erforderlich sofern hier nicht irgendwann Unterdatensätze dran hängen (z.B.Lieferscheine, Rechnungen ...).
    Da es nachträglich Aufwand bereitet einen (AutoWert-)Key 'nachzurüsten' würde ich ihn von Anfang an setzen, wer weiß ob du ihn in einem halben Jahr nicht doch brauchst. *wink.gif*
    Ansonsten bin ich kein großer Freund von AutoWerten und spätestens bei der Umstellung auf ein anderes DB-System muß etwas anderes her.
     
    Marsu65, 26. Oktober 2008
    #6
  7. Hallo,

    über Sinn und Unsinn von künstlichen oder natürlichen Schlüsseln ist immer viel zu diskutieren.

    Hier z.B. Choosing a Primary Key: Natural or Surrogate? gibt es starke Argumente für künstliche Schlüssel.

    Und hier klar, warum natürliche Felder als Key oftmals unsinnig sind: Relationships Should NOT Be Natural! | What Is "Naturally Occurring Data"? | InformIT

    Und selbst auf externe Standards ist kein Verlass: in unserer Firma haben wir numerische Schlüssel für Währungen, die ich oft in die ISO-COdes (USD, EUR, ...) übersetzen muss. Wer jetzt denkt, dass sei 1:1, liegt leider falsch, denn z.B. die türkische Lira und die rumänischen Lei haben bei gleichbleibendem ISO- und z.T. auch numerisczhem Code ein paar Nullen gestrichen... eine direkte Verjoinung ergäbe dann lustige Kurssrpünge über ein paar Zehnerpotenzen....

    Es gibt nichts was es nicht gibt.

    Und cet.par.: das einzig senkrechte sind GUIDs.
     
    Atrus2711, 26. Oktober 2008
    #7
  8. Primärschlüssel in jeder Tabelle zwingend?

    Ein Primärschlüssel sollte meiner Meinung nach in jede Tabelle, damit das DBMS sich nicht zu viel plagen muss, um den DS herauszufinden, der bearbeitet werden sollte. Auch wenn die Tabelle nicht als Fremdschlüsseltabelle dient, besteht doch die Möglichkeit, dass man die DS bearbeiten will. *wink.gif*

    Welche Art von Feld(er) dieser PK enthält, ist Geschmackssache. Auch eine manuell vergebene Kundennummer kann durchaus als PK genutzt werden. So eine wird normalerweise nicht geändert und für Notfälle gibt es die Aktualisierungsweitergabe in der RI. Ich selbst lege auf Felder, die von einem "normalen" Benutzer befüllt werden, allerdings keinen PK. Bei "Admin-Tabellen" nutze ich wiederum sehr gerne einen manuell festgelegten PK.
    Bei 1:n- und n:m-Tabellen verzichte ich oft auf einen 1-Felder-PK und verwende einen 2-Felder-PK. (Beispiel: Fertigungsschritte zu einem Teil: PK = TeileID + Ablaufnummer, die vom System festgelegt wird.)


    @Marsu: Welches DBMS unterstützt keine Autowerte, Identity-Werte, Sequences oder wie auch immer diese Typen heißen wollen?
    Per Trigger lässt sich so ein "Autowert" jederzeit erzeugen ... dieser muss übrigens nicht einmal eine Zahl sein.
     
    Josef P., 26. Oktober 2008
    #8
  9. Tach, wie wärs wenn auch du meinen Post lesen würdest? *rolleyes.gif*
    Nicht bös gemeint, aber meine Aussage im Sinne von Aktualisierung war auf die Tatsache bezogen, dass die DB die Daten eben durch die ganze DB ändern muss. Nicht du selbst. Sprich man will einen Primary-Key ändern, das DB-System muss nun sämtliche FK's durchgehen, weil ja referentialle Integrität gefordert ist mit aktualisierungserweiterung etc. Ist einer dieser Datensätze dummerweise in Bearbeitung, guckt man in die Röhre. So sind solche Änderungen "kleinste" Aktionen, es wird ein Datensatz bearbeitet.

    weitere Nachteile ergeben sich bei sich selbst referenzierenden Tabellen. Ist dummerweise ein Link auf sich selbst vorhanden im selben Datensatz, dann viel Spass. *mrcool

    Weil sich Geschäftsfelder nunmal in ihrer ich sage mal Formatierung ändern können, aus welchem Grund auch immer, tut man gut daran, diese nicht für FK's zu verwenden. Sobald externe Mitarbeiter, welche nicht immer online sind dazukommen, fallen solche Szenarien schonmal auch ins Wasser, weil eine Kundennummer generiert wird obwohl er ned weiss, was für eine. Ist der PK einfach ne GUID, kannst die ohne Probleme [EDIT: Hier sollte generieren stehen] importieren und die Kundennummer anschliessend von der Hauptdatenbank importieren und alle Schlüssel sind korrekt. Die Kudennummer wird dann verteilt.

    Alles andere hatte ich bereits erwähnt hast also nur wiederholt. *wink.gif*
    - Schnellere Joins
    - Weniger Speicherplatz --> Nur 1 Textfeld.

    @Marsu: Nimm dich in Acht ... *grins *grins
     
    Zuletzt von einem Moderator bearbeitet: 7. Januar 2021
    WeinGeist, 26. Oktober 2008
    #9
  10. Ich versuche noch einmal eine andere Formulierung:
    Alle Felder, die der Benutzer nach der Erstellung des DS bearbeiten kann, würde ich nicht als PK verwenden. ich kann mir aber gut vorstellen, dass man Felder als PK verwendet, die nur zum Zeitpunkt der Eingabe vom Benutzer befüllt werden dürfen. (Wobei auch in solchen Fällen ein Surrogatschlüssel sehr praktisch sein kann - denn was ist, wenn sich der Benutzer bei der Eingabe vertippt hat?)

    Generell zum PK: erstellt einmal in einem aktiven DBMS eine Tabelle ohne PK bzw. Unique Index und verknüpft diese in Access ... dann erübrigt sich die Frage, ob ein PK erforderlich ist, wenn ihr die Daten in der verknüpften Tabelle bearbeiten wollt.

    1 Autowert (long) = 4 Byte
    2 x smallint = 4 Byte bzw. 1 x smallint + 1 x tinyint = 3
    @Urs: aufpassen bei Pauschalierungen. *biggrin.gif*
    Ein 2-Felder-PK sinnvoll eingesetzt kann zu Performance-Vorteilen führen. (Datenmenge ist wird imo immer weniger wichtig. *wink.gif*)

    ... aber nur im Vergleich zu Text-Feldern, oder? (Weil ein Zahlenvergleich schneller als ein Stringvergleich abläuft.)
     
    Josef P., 26. Oktober 2008
    #10
  11. \@Josef: War doch nix wirklich Pauschal *wink.gif*
    Betreffend Speicherplatz, das war auf das Textfeld bezogen, mach damit mal die Rechnung. *wink.gif* Ich selber verwende für Typs auch öfter die kleinen Zahlenfelder. AutoWerte eh so gut wie nie, höchstens für mich zu Historyzwecken. Als PK überhaupt nicht, weils mir persönlich zu unflexibel ist. Das man etwas speicherplatz spart wenn man die Kunden-Nummer direkt verwendet wenn Typ Zahl ist, ist mir schon klar, ist ja ein Feld weniger das gebraucht wird. Die Rede war aber von Text.

    Nur mal angenommen man hat nen Kundenstamm. Dieser hat mehre Adressen, diese liegen alle in der selben Tabelle. Wie machst da die Kunden-Nummer als PK? Das ist ein durchwegs gängiges Szenario. --> Lieferadressen. Jedem ne eigene Kunden-Nummer? Obwohl der keine Braucht?

    Oder noch eins, die DB soll plötzlich MultiMandanten-fähig sein, die Kundennummer aber pro Mandant. Ist das schon als PK definiert gehts wieder nicht.

    Ein anderes: Die Firma hat wenige Kunden, aber macht mit denen SEHR viel. sagen wir ein paar dutzende. Er erstellt die Kundennummer mit 3 Ziffern 000 fängt bei 100 an.
    Nun hat er ne neue Geschäftstätigkeit und es kommen tausende Nummern hinzu. Er möchte nun 10000 verwenden. Müssen nun alle PK's angepasst werden und durch die ganze DB durch durch das DB-System abgeändert werden, das gibt einiges Konflikpotenzial. Ansonsten wäre das simpel und ohne Risiko weil die Änderung sich nur auf ein einziges Feld pro Adresse bezieht in einer Tabelle. Also gar nix wildes.

    Was ich damit sagen will: Mit der Verwendung von Geschäftsfeldern als PK verbaut man sich ne Menge Wege, welche bei Änderung der Anforderung eine Änderung des Designs mit sich ziehen, was mit enormen Aufwand verbunden ist. Ist einfach meine Erfahrung damit. Warum also ein Design, welches vielleicht über Jahre weiterentwickelt wird, von Anfang an soweit einschränken? Mir hätte das enorm viele Stunden erspart.
     
    WeinGeist, 26. Oktober 2008
    #11
  12. Soll ich mir jetzt Gedanken machen, wie man bei einem fehlerhaften Datenmodell den PK festlegt? *biggrin.gif*

    tabFirmen
    - idFirma
    - ...

    tabAdressen
    - fiFirma
    - AdressNr (vom DBMS vergebene Systemnummer)
    - Straße
    - ...
    PK = fiFirma + AdressNr

    tabKunden
    - Kundennummer (PK)
    - fiFirma (unique index)
    - ...
    Anm.: hier kann allerdings je nach weiterem Datenmodell ein Tausch von PK und unique index sinnvoll sein. (PK = fiFirma, K-Nr = unique index) ... je nachdem ob die K.-Nr. oder die Firmenkennung das führende System ist.

    Wenn du sicherstellen willst, dass die Kundennummer eindeutig ist, kommst du meiner Meinung nach an einer Kunden-Tabelle nicht vorbei.


    Gerade bei Mandantenfähigkeit würde ich besonders genau überlegen, ob ich nicht jeden PK mit der Mandantenkennung ergänze. Durch so eine Mandantenkennung in den PK-Werten ist es nämlich unmöglich die DS untereinander zu mischen - bei Einfelder-PK kann das nämlich passieren.


    Nur damit kein Missverständnis auftritt: Natürlich muss die Wahl des PK sorgfältig gewählt werden. Ich stimme auch mit dir überein, dass Felder, die vom Benutzer geändert werden, kein PK sein sollten.
    Zu deinem Beispiel mit der Festlegung, dass die Kundennummer 4-Stellig werden soll: Einerseits würde ich eine Kundennummer, die als PK dient, nie als Textfeld verwenden und anderseits halte ich so eine Umstellung für kein besonders großes Vorhaben. Denn die macht hoffentlich nicht ein "normaler" User sondern ein DB-Admin und dieser wird für den Zeitpunkt der Umstellung ziemlich sicher einen schreibenden Zugriff auf die DB verbieten.

    Ich selbst verwende sehr oft Surrogatschlüssel - aber eben nicht nur diese, da in bestimmten Fällen ein anderer Schlüssel sinnvoller sein kann. *Smilie
     
    Josef P., 26. Oktober 2008
    #12
  13. Primärschlüssel in jeder Tabelle zwingend?

    Nö *wink.gif*
    Ich finde gleiche Daten gehören in die gleiche Tabelle. *wink.gif* Ist auch genau das was mich an den ganzen grossen "Systemen" immer stört, diese unflexibilität und verzettelheit von gleichen Daten.

    Doch, das geht problemlos. Über eine Typisierungstabelle *wink.gif*

    Die Idee dahinter ist eine andere, durch die Mandantenfähigkeit soll meiner Meinung nach der Vorteil genutzt werden, das eine Adresse eben so aktuell wie möglich ist. Also beide bzw. alle im Grunde auf den gleichen Adressatz zugreifen. Ein Mandant ist bei mir zum Beispiel nix anderes als auch eine Adresse. *wink.gif* Sprich jeder Kunde könnte Mandant sein, sind auch einige bei uns, wenn wir Lieferscheine in Ihrem Namen erstellen, denen ihre Lagerbuchhaltung usw.

    Sprich mit einem folgenden Design:
    tabContacts
    PK
    Anrede
    Name usw

    tabContactPos
    MAIN_ID --> Adresse 1
    SUB_ID --> Adresse 2
    Verknüpfungstyp --> Zbsp. Kunde
    Kunden-Nummer und sonstige Arten von Parametern


    die Pos Tabelle kann nun X-verschiedene Aufgaben übernehmen. Der ganze Adressstamm kann beliebig erweitert werden, mit so vielen Lieferadressen, Rechnungsadressen, Standorten, Kontaktpersonen wie man möchte. Jeder ist für sich selbst ein vollwertiger Eintrag in der Kontakttabelle, auch wenn der User diesen Anschein nicht unbedingt hat.

    Ich persönlich finde das eben sehr flexibel und man hat nicht die gleiche Adresse in X-Facher ausführung überall über die Datenbank verstreut. Insofern finde ich, dass die meisten Adress-/Mandantenstämme von sehr vielen Softwarelösungen unbrauchbar sind oder sich eine solche ähnliche Funktionalität richtig teuer pro Mandant bezahlen lassen bzw. in der Regel unmöglich ist. Ich habe zumindest keine vernünftige ERP-Lösung gefunden, welche mir diese Flexibilität bietet.

    Habe dich schon nicht missverstanden. *wink.gif* Nur schliesst man Probleme dieser art durch die Verwendung von Surrogat schlüssel bei Geschäftstypischen Felder eben von vornherein aus. Ein DB-Admin hat dann halt nicht viel Arbeit bei soner Änderung, die Überprüfungen halten sich sehr in Grenzen, das Konfliktpotenzial auch. (Armer Kerl). *grins
    Bei Systemtabellen benutze ich auch öfter mal direkt den entsprechenden Key, aber diese sind auch nicht mit Xbeliebigen Daten versehen.
     
    Zuletzt von einem Moderator bearbeitet: 7. Januar 2021
    WeinGeist, 26. Oktober 2008
    #13
  14. Hi Weingeist,
    der Begriff Mandant ist aber anders belegt. Was du da meinst, ist ein abstraktes Superobjekt "Personen", das als Kunde und als Lieferant auftreten kann. Das kann man durchaus so aufbauen, aber du brauchst dann trotzdem für das Auftreten einer Person als Kunde andere Infos als für das Auftreten als Lieferant.

    Unter Mandant verstehe ich mehrere "getrennte Bereiche" in einer DB. So kann z.B. ein Lohnbüro die gleiche DB nutzen für die Abwicklung der Lohnbuchhaltung für Firma X und für Firma Y, aber natürlich dürfen X und Y nichts miteinander teilen. Und wenn das Lohnbüro die DB den Firmen X und Y als Dienstleister bereitstellt, dann sind X und Y Mandanten. Jeder sieht nur seine Daten, ein Übergriff ist ausgeschlossen, aber das Lohnbüro kommt an alle Daten ran.

    HTH
     
    Atrus2711, 26. Oktober 2008
    #14
  15. Hallo FW und die anderen Profis hier,

    danke für eure Antworten!

    Dann habe ich gelernt, dass das Schlüsselfeld über die Tabellen in Beziehung stehen immer vom Typ Numerisch sein sollte. Dadurch wird die Datenmenge klein gehalten und die Verarbeitung erfolgt schneller.

    Nochmal zu meinen Beispiel, nun in geänderter Form:

    Tabelle 1:

    Kunden-nr: Typ Autowert (Primärschlüssel)
    Kundennummer: Typ Text
    Nachname: Typ Text
    Vorname: Typ Text

    Ich muss dann wohl noch einen Sekundärschlüssel (Mehrfachschlüssel) über die Felder Kundennummer+Nachname+Vorname definieren, mit der Option doppelte Werte NEIN.

    Das ist doch so korrekt oder nicht?

    Danke im voraus.
     
    Zuletzt von einem Moderator bearbeitet: 7. Januar 2021
    steve005, 26. Oktober 2008
    #15
Thema:

Primärschlüssel in jeder Tabelle zwingend?

Die Seite wird geladen...
  1. Primärschlüssel in jeder Tabelle zwingend? - Similar Threads - Primärschlüssel Tabelle zwingend

  2. Datensatze löschen INKLUSIV Primärschlüssel

    in Microsoft Access Hilfe
    Datensatze löschen INKLUSIV Primärschlüssel: Hey Ihr Lieben, gibt es die Möglichkeit Datensätze inklusiv Primärschlüssel zu löschen? Hintergrund: Ich habe einige Testdaten eingetragen, möchte nun "reale" Daten eintragen und gerne bei...
  3. Primärschlüssel/Fremdschlüssel aus 2.Tabelle automatisch einfügen

    in Microsoft Access Hilfe
    Primärschlüssel/Fremdschlüssel aus 2.Tabelle automatisch einfügen: Hallo zusammen, ich stehe gerade vor dem Problem, dass ich die Datensätze zwischen zwei Tabellen nicht verknüpfen kann. Konkret habe ich die beiden Tabellen tblEigenschaft und tblBasis. In der...
  4. Primärschlüssel für zwei Tabellen gebrauchen

    in Microsoft Access Hilfe
    Primärschlüssel für zwei Tabellen gebrauchen: Hallo zusammen, Ich beschäftige mich mit Access und Versicherungen. Dazu habe ich mir eine Datenbank gezimmert mit den Tabellen Unternehmen, Kontakte (Zwischentabelle), Personen, Adressen und...
  5. Bei Zusammenführung von Excel-Tabellen sollen ALLE Primärschlüssel aufgelistet werden

    in Microsoft Access Hilfe
    Bei Zusammenführung von Excel-Tabellen sollen ALLE Primärschlüssel aufgelistet werden: Hallo! Ich möchte in Access über die Funktion "Beziehungen" (unter 'Datenbanktools') zwei Excel-Tabellen (Preisliste Obst) zusammenführen. Dabei definiere ich die ID-Nr. der Obstsorten als...
  6. Primärschlüssel bei verknüpfter Tabelle aktivieren

    in Microsoft Access Hilfe
    Primärschlüssel bei verknüpfter Tabelle aktivieren: Hallo an alle, mein Problem: Ich habe eine neue Datenbank angelegt und ein Excelfile importiert mit der Einschränkung "Erstellen Sie ine Verknüpfung zur Datenquelle, indem sie eine verknüpfte...
  7. Hinzufügen oder Ändern des Primärschlüssels einer Tabelle in Access

    in Microsoft Access Tutorials
    Hinzufügen oder Ändern des Primärschlüssels einer Tabelle in Access: Hinzufügen oder Ändern des Primärschlüssels einer Tabelle in Access Access für Microsoft 365 Access 2019 Access 2016 Access 2013 Access 2010 Access...
  8. Hilfe für Access Datenbank

    in Microsoft Access Hilfe
    Hilfe für Access Datenbank: Hallo an alle! Ich habe da ein kleines Problem, ich habe schon länger nicht mit Access gearbeitet und benötige daher etwas Hilfe. Situation ist folgende: 1. Möchte ich eine Liste mit...
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Auf dieser Website werden Cookies für die Zugriffsanalyse und Anzeigenmessung verwendet.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden