SQL Alchemy - Foreign Keys Beziehungen

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
RichardeRicharde
User
Beiträge: 16
Registriert: Montag 29. November 2021, 14:37

Hallo zusammen, ich habe eine Frage zu SQL Alchemy Fremdschlüsselbeziehungen.

Tab_A

Code: Alles auswählen

class Tab_a:
    __tablename__ = "tab_a"
    # Meta
    id = Column(Integer, primary_key=True)
    timestamp = Column(TIMESTAMP, unique=True)
    # Relations
    tab_b = relationship("Tab_b", back_populates="tab_a")
Tab_B

Code: Alles auswählen

class Tab_B:
    __tablename__ = "Tab_B"
    # Meta
    id = Column(ForeignKey("played_games.id"), primary_key=True)
    subid = Column(Integer, primary_key=True)
    # Relations
    tab_a = relationship("Tab_a", back_populates="tab_b")
Tab_C

Code: Alles auswählen

class Tab_c:
    __tablename__ = "Tab_C"
    # Meta
    c_id = Column(Integer, primary_key=True)
    b_id = Column(ForeignKey("tab_b.id"), primary_key=True)
    b_subid = Column(ForeignKey("tab_b.subid"), primary_key=True)
    # Relations
    # .....
Ist die Beziehung von Tab_B zu Tab_C für jede Beziehungsspalte many-to-many und kann ich diese in sql alchemy mit ORM nur über eine Zuordnungstabelle herstellen?

Betrachte ich den gesamten Schlüssel von Tab_B in der Beziehung zu Tab_C ist es ja eine one-to-many Beziehung.... ich wüßte aber nicht wie man das abbilden soll und gehe daher von aus das die Variante mit Zuordnungstabelle zu wählen ist.

Ich hoffe Ihr könnt mich dazu aufschlauen und Danke euch wie immer für euren Input und eure Zeit.

Richarde
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@RichardeRicharde: Fremdschlüssel die gleichzeitig Teil des Primärschlüssels sind‽ Mach mal bitte vernünftige Namen und erkläre mal die Bedeutung von dem ganzen, ob das so überhaupt Sinn macht.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
RichardeRicharde
User
Beiträge: 16
Registriert: Montag 29. November 2021, 14:37

Hallo und Danke für Deine Antwort.
Als Beispiel könnte ein ERP System herhalten...

- Belegkopftabelle
1. Belegnummer (key)
2. Anlegedatum

- Belegpostionstabelle
1. Belegnummer (Key - Foreign)
2. Positionsnummer (Key)
3. Material
4. Anzahl

Positionstexte
1. Belegnummer (Key - Foreign)
2. Belegposition (Key - Foreign)
3. Text-Id (Key)
4. Text

Viele Grüße
Richarde
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Du missbrauchst keys wegen ihrer unique Eigenschaften. Und das auch noch nicht mal richtig. Die Positionen müssen unique sein, und dAs ja nur pro Beleg. Also ein unique constraint über belegnummer und position.

Und die Referenz Belegnummer in Positionstexte ist redundant & gehört darum weg.
RichardeRicharde
User
Beiträge: 16
Registriert: Montag 29. November 2021, 14:37

Danke für Dein Input.
__deets__ hat geschrieben: Freitag 28. Januar 2022, 09:05 Du missbrauchst keys wegen ihrer unique Eigenschaften. Und das auch noch nicht mal richtig. Die Positionen müssen unique sein, und dAs ja nur pro Beleg. Also ein unique constraint über belegnummer und position.
Das war ja so ungefähr meine Frage.
In der Postionstabelle ist Belegnummer und Positionsnummer der Schlüssel, zusammen.
Etwas Missbrauchen möchte ich nicht, ich würde es gern richtig machen und verstehen. Jede Kombination Belegnummer & Posnr kann nur einmal in der Postab vorkommen, das ist richtig und möchte ich auch so umsetzen
__deets__ hat geschrieben: Freitag 28. Januar 2022, 09:05 Und die Referenz Belegnummer in Positionstexte ist redundant & gehört darum weg.
Ja, die Belegnummer wäre Redundant aber um sie wegzubekommen müsste man wiederum ein Index auf der Postabelle einführen weil man sonst die Zuordnung doch nicht hinbekommt?


Ich habe mir das komplette "SQLAlchemy 2.0 - The One-Point-Four-Ening 2021" by: Mike Bayer angeschaut und den Demo Code runtergeladen und versucht nachzuvollziehen - leider diese Sachen nicht sehr tief ein - Vergleiche dazu die Folien und Coding und Video zu "Advanced ORM"

Wenn jemand dazu noch Links zu Tuturials und Informationen für mein Problem hat wäre das toll. Die SQLAlchemy Anleitung ist ein bischen Fad.

Viele Grüße
Richarde
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Du hast recht mit dem compound key, das ist mir durch die etwas unglückliche Notation nicht gleich aufgefallen. Den hinter dem Namen zu annotieren ist dafür ungeeignet, weil es mehrere keys geben kann. Man benutzt stattdessen sowas wie

key (belegnummer, position)

Und damit verstehe ich dann auch die Modellierung der Positionstexte. Das soll dann auch eine compound key sein?

key (belegnummer, beleg_position, position)

Das geht dann zwar, würde ich aber nicht machen. Wie man sieht, schleppt man so die ganzen keys immer mehr mit. Redundanz ist das dann nicht, a er umständlich.

Ich würde dann trotzdem mit ID keys arbeiten, und die Position zusammen mit dem key als unique constraint formulieren.
RichardeRicharde
User
Beiträge: 16
Registriert: Montag 29. November 2021, 14:37

__deets__ hat geschrieben: Freitag 28. Januar 2022, 10:12 Du hast recht mit dem compound key, das ist mir durch die etwas unglückliche Notation nicht gleich aufgefallen. Den hinter dem Namen zu annotieren ist dafür ungeeignet, weil es mehrere keys geben kann. Man benutzt stattdessen sowas wie

key (belegnummer, position)
Ok, Danke. Funktioniert also beides gleich, sind nur unterschiedliche Notationen. :-)
__deets__ hat geschrieben: Freitag 28. Januar 2022, 10:12 Und damit verstehe ich dann auch die Modellierung der Positionstexte. Das soll dann auch eine compound key sein?
Ja
__deets__ hat geschrieben: Freitag 28. Januar 2022, 10:12 key (belegnummer, beleg_position, position)

Das geht dann zwar, würde ich aber nicht machen. Wie man sieht, schleppt man so die ganzen keys immer mehr mit. Redundanz ist das dann nicht, aber umständlich.

Ich würde dann trotzdem mit ID keys arbeiten, und die Position zusammen mit dem key als unique constraint formulieren.
Ok, Danke.


Bin ich dann in meiner Annahme hier richtig?
RichardeRicharde hat geschrieben: Donnerstag 27. Januar 2022, 14:53 Ist die Beziehung von Tab_B zu Tab_C für jede Beziehungsspalte many-to-many und kann ich diese in sql alchemy mit ORM nur über eine Zuordnungstabelle herstellen?

Betrachte ich den gesamten Schlüssel von Tab_B in der Beziehung zu Tab_C ist es ja eine one-to-many Beziehung.... ich wüßte aber nicht wie man das abbilden soll und gehe daher von aus das die Variante mit Zuordnungstabelle zu wählen ist.
Viele Grüße
Richarde
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

Die letzte Frage kann ich nicht beantworten, weil ich nicht weiss, was Tab_B und Tab_C sind. Ob die also 1:n oder n:m sein sollen oder muessen, weiss ich nicht. Klar ist aber: 1:n geht mit einem Fremdschluessel von B nach A, und m:n *immer* nur (egal ob SQLAlchemy oder nicht) mittels einer Zuordnungstabelle. Das gibt die relationale Algebra anders nicht her.

Und wenn du compound keys in SA willst, dann geht das zB so wie hier: https://docs.sqlalchemy.org/en/14/faq/o ... rimary-key
RichardeRicharde
User
Beiträge: 16
Registriert: Montag 29. November 2021, 14:37

Ok, Danke - ich schaue mir das mal an und Probiere das mal aus.

Viele Grüße
Richarde
Antworten