Glossar¶

1.x-Stil¶

2.0-Stil¶

1.x-Stil¶

2.0-Stil¶

Diese Begriffe sind neu in SQLAlchemy 1.4 und beziehen sich auf den SQLAlchemy 1.4-> 2.0 Übergangsplan, der unter SQLAlchemy 2.0 - Major Migration Guide beschrieben wird. Der Begriff „1.x-Stil“ bezieht sich auf eine API, die so verwendet wird, wie sie in der 1.x-Reihe von SQLAlchemy und früher (z. B. 1.3, 1.2 usw.) dokumentiert wurde, und der Begriff „2.0-Stil“ bezieht sich auf die Art und Weise, wie eine API in Version 2.0 aussehen wird. Version 1.4 implementiert fast die gesamte API von 2.0 im sogenannten „Übergangsmodus“, während Version 2.0 das Legacy- Query Objekt beibehält, um Legacy-Code weitgehend 2.0-kompatibel zu halten.

Siehe auch

SQLAlchemy 2.0 - Major Migration Guide

ACID¶

ACID-Modell¶

Ein Akronym für „Atomicity, Consistency, Isolation, Durability“; eine Reihe von Eigenschaften, die gewährleisten, dass Datenbanktransaktionen zuverlässig verarbeitet werden. (via Wikipedia)

Siehe auch

ACID-Modell (via Wikipedia)

Verbundbeziehung¶

Eine zweistufige Beziehung, die zwei Tabellen über eine Verknüpfungstabelle dazwischen verbindet. Die Verbundbeziehung unterscheidet sich von einer Many-to-Many-Beziehung dadurch, dass die Many-to-Many-Tabelle durch eine vollständige Klasse abgebildet wird, anstatt unsichtbar vom sqlalchemy.orm.relationship() Konstrukt gehandhabt zu werden, wie es bei Many-to-Many der Fall ist, sodass zusätzliche Attribute explizit verfügbar sind.

Wenn wir zum Beispiel Mitarbeiter mit Projekten verknüpfen und dabei die spezifische Rolle eines Mitarbeiters bei dem Projekt speichern möchten, könnte das relationale Schema wie folgt aussehen:

CREATE TABLE employee (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30)
)

CREATE TABLE project (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30)
)

CREATE TABLE employee_project (
    employee_id INTEGER PRIMARY KEY,
    project_id INTEGER PRIMARY KEY,
    role_name VARCHAR(30),
    FOREIGN KEY employee_id REFERENCES employee(id),
    FOREIGN KEY project_id REFERENCES project(id)
)

Ein SQLAlchemy-Deklarationsmapping für das obige könnte wie folgt aussehen:

class Employee(Base):
    __tablename__ = "employee"

    id = Column(Integer, primary_key=True)
    name = Column(String(30))


class Project(Base):
    __tablename__ = "project"

    id = Column(Integer, primary_key=True)
    name = Column(String(30))


class EmployeeProject(Base):
    __tablename__ = "employee_project"

    employee_id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    project_id = Column(Integer, ForeignKey("project.id"), primary_key=True)
    role_name = Column(String(30))

    project = relationship("Project", backref="project_employees")
    employee = relationship("Employee", backref="employee_projects")

Mitarbeiter können einem Projekt mit einem Rollennamen hinzugefügt werden

proj = Project(name="Client A")

emp1 = Employee(name="emp1")
emp2 = Employee(name="emp2")

proj.project_employees.extend(
    [
        EmployeeProject(employee=emp1, role_name="tech lead"),
        EmployeeProject(employee=emp2, role_name="account executive"),
    ]
)

Siehe auch

Many-to-Many

Atomarität¶

Atomarität ist eine der Komponenten des ACID-Modells und erfordert, dass jede Transaktion „alles oder nichts“ ist: Wenn ein Teil der Transaktion fehlschlägt, schlägt die gesamte Transaktion fehl und der Datenbankzustand bleibt unverändert. Ein atomares System muss die Atomarität in jeder Situation gewährleisten, einschließlich Stromausfällen, Fehlern und Abstürzen. (via Wikipedia)

Siehe auch

ACID

Atomarität (via Wikipedia)

angebunden¶

Zeigt ein ORM-Objekt an, das derzeit mit einer bestimmten Sitzung verbunden ist.

Siehe auch

Kurze Einführung in Objektdzustände

Backref¶

Bidirektionale Beziehung¶

Eine Erweiterung des Beziehungssystems, bei der zwei verschiedene relationship() Objekte gegenseitig miteinander verknüpft werden können, sodass sie im Speicher koordiniert werden, wenn sich auf einer Seite Änderungen ergeben. Die gebräuchlichste Methode, diese beiden Beziehungen zu erstellen, besteht darin, die Funktion relationship() für eine Seite explizit zu verwenden und das Schlüsselwort backref dafür anzugeben, sodass die andere relationship() automatisch erstellt wird. Dies können wir am Beispiel der One-to-Many-Beziehung wie folgt veranschaulichen:

class Department(Base):
    __tablename__ = "department"
    id = Column(Integer, primary_key=True)
    name = Column(String(30))
    employees = relationship("Employee", backref="department")


class Employee(Base):
    __tablename__ = "employee"
    id = Column(Integer, primary_key=True)
    name = Column(String(30))
    dep_id = Column(Integer, ForeignKey("department.id"))

Eine Backref kann auf jede Beziehung angewendet werden, einschließlich One-to-Many, Many-to-One und Many-to-Many.

Siehe auch

gebundener Parameter¶

gebundene Parameter¶

Bind-Parameter¶

Bind-Parameter sind das primäre Mittel, mit dem Daten an den DBAPI-Datenbanktreiber übergeben werden. Während die aufzurufende Operation auf der SQL-Anweisungszeichenfolge basiert, werden die Datenwerte separat übergeben, wobei der Treiber über Logik verfügt, die diese Zeichenfolgen sicher verarbeitet und an den Backend-Datenbankserver übergibt, was entweder die Formatierung der Parameter in die SQL-Zeichenfolge selbst oder die Übergabe an die Datenbank über separate Protokolle beinhalten kann.

Das spezifische System, mit dem der Datenbanktreiber dies tut, sollte für den Aufrufer keine Rolle spielen. Wichtig ist, dass Daten von außen **immer** separat und nicht als Teil der SQL-Zeichenfolge übergeben werden sollten. Dies ist sowohl für die angemessene Sicherheit gegen SQL-Injection als auch für die optimale Leistung des Treibers von entscheidender Bedeutung.

Siehe auch

Prepared Statement - auf Wikipedia

Bind-Parameter - auf Use The Index, Luke!

Parameter übermitteln - im SQLAlchemy Unified Tutorial

Kandidatenschlüssel¶

Ein Begriff der Relationenalgebra, der sich auf ein Attribut oder eine Gruppe von Attributen bezieht, die einen eindeutig identifizierenden Schlüssel für eine Zeile bilden. Eine Zeile kann mehr als einen Kandidatenschlüssel haben, von denen jeder als Primärschlüssel dieser Zeile verwendet werden kann. Der Primärschlüssel einer Tabelle ist immer ein Kandidatenschlüssel.

Siehe auch

Primärschlüssel

Kandidatenschlüssel (via Wikipedia)

https://www.databasestar.com/database-keys/

Kartesisches Produkt¶

Gegeben seien zwei Mengen A und B. Das kartesische Produkt ist die Menge aller geordneten Paare (a, b), wobei a in A und b in B liegt.

In Bezug auf SQL-Datenbanken tritt ein kartesisches Produkt auf, wenn wir aus zwei oder mehr Tabellen (oder anderen Subqueries) auswählen, ohne eine Art von Kriterium zwischen den Zeilen einer Tabelle und der anderen (direkt oder indirekt) herzustellen. Wenn wir gleichzeitig aus Tabelle A und Tabelle B auswählen, erhalten wir jede Zeile von A mit der ersten Zeile von B, dann jede Zeile von A mit der zweiten Zeile von B usw., bis jede Zeile von A mit jeder Zeile von B gepaart wurde.

Kartesische Produkte verursachen die Generierung enormer Ergebnismengen und können eine Client-Anwendung leicht abstürzen lassen, wenn sie nicht verhindert werden.

Siehe auch

Kartesisches Produkt (via Wikipedia)

Cascade¶

Ein Begriff, der in SQLAlchemy verwendet wird, um zu beschreiben, wie eine ORM-Persistenzaktion, die auf einem bestimmten Objekt stattfindet, sich auf andere Objekte erstreckt, die direkt mit diesem Objekt verbunden sind. In SQLAlchemy werden diese Objektverbindungen mit dem relationship()-Konstrukt konfiguriert. relationship() enthält einen Parameter namens relationship.cascade, der Optionen bietet, wie bestimmte Persistenzoperationen kaskadieren können.

Der Begriff „Cascades“ sowie die allgemeine Architektur dieses Systems in SQLAlchemy wurde, ob zum Besseren oder Schlechteren, vom Hibernate ORM übernommen.

Siehe auch

Kaskaden

CHECK-Constraint¶

Ein CHECK-Constraint ist eine Bedingung, die gültige Daten beim Hinzufügen oder Aktualisieren eines Eintrags in einer Tabelle einer relationalen Datenbank definiert. Ein CHECK-Constraint wird auf jede Zeile in der Tabelle angewendet.

(via Wikipedia)

Ein CHECK-Constraint kann einer Tabelle in Standard-SQL mit DDL wie folgt hinzugefügt werden:

ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5);

Siehe auch

CHECK-Constraint (via Wikipedia)

Spaltenklausel¶

Der Teil der SELECT-Anweisung, der die SQL-Ausdrücke aufzählt, die im Ergebnissatz zurückgegeben werden sollen. Die Ausdrücke folgen direkt auf das Schlüsselwort SELECT und sind eine durch Kommas getrennte Liste einzelner Ausdrücke.

Z. B.

SELECT user_account.name, user_account.email
FROM user_account WHERE user_account.name = 'fred'

Oben ist die Liste der Spalten user_acount.name, user_account.email die Spaltenklausel der SELECT.

Zusammengesetzter Primärschlüssel¶

Ein Primärschlüssel, der mehr als eine Spalte hat. Eine bestimmte Datenbankzeile ist anhand von zwei oder mehr Spalten eindeutig und nicht nur anhand eines einzelnen Werts.

Siehe auch

Primärschlüssel

Konsistenz¶

Konsistenz ist eine der Komponenten des ACID-Modells und stellt sicher, dass jede Transaktion die Datenbank von einem gültigen Zustand in einen anderen überführt. Alle Daten, die in die Datenbank geschrieben werden, müssen gemäß allen definierten Regeln gültig sein, einschließlich, aber nicht beschränkt auf Constraints, Kaskaden, Trigger und jede Kombination davon. (via Wikipedia)

Siehe auch

ACID

Konsistenz (via Wikipedia)

Constraint¶

Constraints¶

eingeschränkt¶

Regeln, die innerhalb einer relationalen Datenbank festgelegt sind und die Gültigkeit und Konsistenz von Daten sicherstellen. Gängige Formen von Constraints sind Primärschlüssel-Constraint, Fremdschlüssel-Constraint und CHECK-Constraint.

korreliert¶

Korrelierte Subquery¶

Korrelierte Subqueries¶

Eine Subquery ist korreliert, wenn sie von Daten in der umgebenden SELECT abhängt.

Unten wählt eine Subquery den aggregierten Wert MIN(a.id) aus der Tabelle email_address aus, sodass sie für jeden Wert von user_account.id aufgerufen wird und der Wert dieser Spalte gegen die Spalte email_address.user_account_id korreliert wird.

SELECT user_account.name, email_address.email
 FROM user_account
 JOIN email_address ON user_account.id=email_address.user_account_id
 WHERE email_address.id = (
    SELECT MIN(a.id) FROM email_address AS a
    WHERE a.user_account_id=user_account.id
 )

Die obige Subquery bezieht sich auf die Tabelle user_account, die sich nicht selbst in der FROM-Klausel dieser verschachtelten Abfrage befindet. Stattdessen wird die Tabelle user_account aus der umgebenden Abfrage empfangen, wobei jede aus user_account ausgewählte Zeile zu einer separaten Ausführung der Subquery führt.

Eine korrelierte Subquery befindet sich in den meisten Fällen in der WHERE-Klausel oder Spaltenklausel der unmittelbar umgebenden SELECT-Anweisung sowie in der ORDER BY- oder HAVING-Klausel.

In selteneren Fällen kann sich eine korrelierte Subquery in der FROM-Klausel einer umgebenden SELECT befinden; in diesen Fällen ist die Korrelation typischerweise darauf zurückzuführen, dass die umgebende SELECT selbst in der WHERE-, ORDER BY-, Spalten- oder HAVING-Klausel einer anderen SELECT verschachtelt ist, wie zum Beispiel:

SELECT parent.id FROM parent
WHERE EXISTS (
    SELECT * FROM (
        SELECT child.id AS id, child.parent_id AS parent_id, child.pos AS pos
        FROM child
        WHERE child.parent_id = parent.id ORDER BY child.pos
    LIMIT 3)
WHERE id = 7)

Eine Korrelation von einer SELECT-Anweisung direkt zu einer, die die korrelierte Abfrage über ihre FROM-Klausel umschließt, ist nicht möglich, da die Korrelation erst erfolgen kann, wenn die ursprünglichen Quellzeilen aus der FROM-Klausel der umschließenden Anweisung verfügbar sind.

CRUD¶

Ein Akronym, das für „Create, Read, Update, Delete“ steht. Der Begriff in SQL bezieht sich auf die Menge von Operationen, die Daten in der Datenbank erstellen, ändern und löschen, auch bekannt als DML, und bezieht sich typischerweise auf die Anweisungen INSERT, UPDATE und DELETE.

Cursor¶

Eine Kontrollstruktur, die die Durchquerung von Datensätzen in einer Datenbank ermöglicht. In der Python DBAPI ist das Cursor-Objekt tatsächlich der Ausgangspunkt für die Ausführung von Anweisungen sowie die Schnittstelle zum Abrufen von Ergebnissen.

Siehe auch

Cursor-Objekte (in pep-249)

Cursor (via Wikipedia)

Zyklomatische Komplexität¶

Ein Maß für die Codekomplexität, das auf der Anzahl der möglichen Pfade durch den Quellcode eines Programms basiert.

Siehe auch

Zyklomatische Komplexität

DBAPI¶

pep-249¶

DBAPI ist die Abkürzung für „Python Database API Specification“. Dies ist eine weit verbreitete Spezifikation in Python, um gemeinsame Nutzungsmuster für alle Datenbankverbindungspakete zu definieren. Die DBAPI ist eine „Low-Level“-API, die typischerweise die unterste Ebene darstellt, die in einer Python-Anwendung für die Kommunikation mit einer Datenbank verwendet wird. Das Dialektsystem von SQLAlchemy ist um die Funktionsweise der DBAPI aufgebaut und stellt einzelne Dialektklassen bereit, die einen bestimmten DBAPI auf einer bestimmten Datenbank-Engine bedienen. Beispielsweise bezieht sich die URL postgresql+psycopg2://@localhost/test für create_engine() auf die psycopg2 DBAPI/Dialekt-Kombination, während die URL mysql+mysqldb://@localhost/test auf die MySQL for Python DBAPI/Dialekt-Kombination verweist.

Siehe auch

PEP 249 - Python Database API Specification v2.0

DDL¶

Ein Akronym für **Data Definition Language**. DDL ist die Teilmenge von SQL, die relationale Datenbanken verwenden, um Tabellen, Constraints und andere permanente Objekte innerhalb eines Datenbankschemas zu konfigurieren. SQLAlchemy bietet eine reichhaltige API zum Erstellen und Ausgeben von DDL-Ausdrücken.

Siehe auch

Datenbanken mit MetaData beschreiben

DDL (via Wikipedia)

DML

DQL

gelöscht¶

Dies beschreibt einen der Hauptzustände, die ein Objekt innerhalb einer Sitzung haben kann; ein gelöschtes Objekt ist ein Objekt, das zuvor persistent war und dessen Zeile mit einer DELETE-Anweisung an die Datenbank gesendet wurde. Das Objekt wechselt in den detached-Zustand, sobald die Transaktion der Sitzung committet wird; alternativ, wenn die Transaktion der Sitzung zurückgerollt wird, wird das DELETE rückgängig gemacht und das Objekt kehrt in den persistenten Zustand zurück.

Siehe auch

Kurze Einführung in Objektdzustände

Deskriptor¶

Deskriptoren¶

In Python ist ein Deskriptor ein Objektattribut mit „Bindungsverhalten“, dessen Attributzugriff durch Methoden im Deskriptor-Protokoll überschrieben wurde. Diese Methoden sind __get__(), __set__() und __delete__(). Wenn eine dieser Methoden für ein Objekt definiert ist, wird es als Deskriptor bezeichnet.

In SQLAlchemy werden Deskriptoren intensiv verwendet, um Attributverhalten auf gemappten Klassen bereitzustellen. Wenn eine Klasse wie folgt gemappt wird:

class MyClass(Base):
    __tablename__ = "foo"

    id = Column(Integer, primary_key=True)
    data = Column(String)

Die Klasse MyClass wird gemappt, sobald ihre Definition abgeschlossen ist. Zu diesem Zeitpunkt werden die Attribute id und data, die als Column-Objekte beginnen, durch das Instrumentierungssystem mit Instanzen von InstrumentedAttribute ersetzt, die Deskriptoren sind und die oben genannten Methoden __get__(), __set__() und __delete__() bereitstellen. Das InstrumentedAttribute generiert einen SQL-Ausdruck, wenn es auf Klassenebene verwendet wird.

>>> print(MyClass.data==5)data = :data_1

und auf Instanzebene verfolgt es Änderungen an Werten und lädt auch Lazy-Loads nicht geladene Attribute aus der Datenbank.

>>> m1 = MyClass()
>>> m1.id = 5
>>> m1.data = "some data"

>>> from sqlalchemy import inspect
>>> inspect(m1).attrs.data.history.added
"some data"

detached¶

Dies beschreibt einen der Hauptzustände, die ein Objekt innerhalb einer Sitzung haben kann; ein detached-Objekt ist ein Objekt, das eine Datenbankidentität (d. h. einen Primärschlüssel) hat, aber keiner Sitzung zugeordnet ist. Ein Objekt, das zuvor persistent war und aus seiner Sitzung entfernt wurde, entweder weil es expunged wurde oder die besitzende Sitzung geschlossen wurde, wechselt in den detached-Zustand. Der detached-Zustand wird im Allgemeinen verwendet, wenn Objekte zwischen Sitzungen verschoben oder von/zu einem externen Objekt-Cache bewegt werden.

Siehe auch

Kurze Einführung in Objektdzustände

Dialekt¶

In SQLAlchemy ist der „Dialekt“ ein Python-Objekt, das Informationen und Methoden repräsentiert, die es Datenbankoperationen ermöglichen, auf einer bestimmten Art von Datenbank-Backend und einer bestimmten Art von Python-Treiber (oder DBAPI) für diese Datenbank auszuführen. SQLAlchemy-Dialekte sind Unterklassen der Klasse Dialect.

Siehe auch

Engine-Konfiguration

Diskriminator¶

Eine Ergebnisspalte, die beim polymorphen Laden verwendet wird, um zu bestimmen, welcher gemappte Klassentyp einer bestimmten eingehenden Ergebniszeile zugeordnet werden soll.

Siehe auch

Abbildung von Klassenhierarchien

DML¶

Ein Akronym für **Data Manipulation Language**. DML ist die Teilmenge von SQL, die relationale Datenbanken verwenden, um Daten in Tabellen zu *ändern*. DML bezieht sich typischerweise auf die drei allgemein bekannten Anweisungen INSERT, UPDATE und DELETE, auch bekannt als CRUD (Akronym für „Create, Read, Update, Delete“).

Siehe auch

DML (via Wikipedia)

DDL

DQL

Domänenmodell¶

Ein Domänenmodell in der Problemlösung und Softwareentwicklung ist ein konzeptionelles Modell aller Themen, die sich auf ein bestimmtes Problem beziehen. Es beschreibt die verschiedenen Entitäten, ihre Attribute, Rollen und Beziehungen sowie die Einschränkungen, die die Problemdomäne regeln.

(via Wikipedia)

Siehe auch

Domänenmodell (via Wikipedia)

DQL¶

Ein Akronym für **Data Query Language**. DQL ist die Teilmenge von SQL, die relationale Datenbanken verwenden, um Daten in Tabellen zu *lesen*. DQL bezieht sich fast ausschließlich auf die SQL SELECT-Konstruktion als die auf höchster Ebene verwendete SQL-Anweisung.

Siehe auch

DQL (via Wikipedia)

DML

DDL

Haltbarkeit¶

Haltbarkeit ist eine Eigenschaft des ACID-Modells, die bedeutet, dass nach dem Commit einer Transaktion diese bestehen bleibt, selbst im Falle von Stromausfall, Abstürzen oder Fehlern. In einer relationalen Datenbank zum Beispiel müssen nach der Ausführung einer Gruppe von SQL-Anweisungen die Ergebnisse dauerhaft gespeichert werden (auch wenn die Datenbank unmittelbar danach abstürzt). (via Wikipedia)

Siehe auch

ACID

Haltbarkeit (via Wikipedia)

Eager Load¶

Eager Loads¶

Eager Loaded¶

Eager Loading¶

Eagerly Load¶

Im Objekt-Relationalen Mapping bezieht sich ein „Eager Load“ auf ein Attribut, das mit seinem datenbankseitigen Wert zum selben Zeitpunkt wie das Objekt selbst aus der Datenbank geladen wird. In SQLAlchemy bezieht sich der Begriff „Eager Loading“ normalerweise auf verwandte Sammlungen und Instanzen von Objekten, die zwischen Mappings über das relationship()-Konstrukt verknüpft sind, kann sich aber auch auf das Laden zusätzlicher Spaltenattribute beziehen, oft aus anderen Tabellen, die mit einer bestimmten abgefragten Tabelle verbunden sind, wie z. B. bei der Verwendung von Vererbungs-Mappings.

Eager Loading ist das Gegenteil von Lazy Loading.

Siehe auch

Techniken für das Laden von Beziehungen

executemany¶

Dieser Begriff bezieht sich auf einen Teil der PEP 249 DBAPI-Spezifikation, der eine einzelne SQL-Anweisung angibt, die gegen eine Datenbankverbindung mit mehreren Parametersätzen aufgerufen werden kann. Die spezifische Methode ist bekannt als cursor.executemany() und hat viele Verhaltensunterschiede im Vergleich zur Methode cursor.execute(), die für den Aufruf einzelner Anweisungen verwendet wird. Die Methode „executemany“ führt die angegebene SQL-Anweisung mehrmals aus, einmal für jeden Satz übergebener Parameter. Die allgemeine Begründung für die Verwendung von executemany ist die Leistungssteigerung, bei der die DBAPI Techniken wie die einmalige Vorbereitung der Anweisung oder die Optimierung für die mehrfache Ausführung derselben Anweisung nutzen kann.

SQLAlchemy verwendet typischerweise die Methode cursor.executemany() automatisch, wenn die Methode Connection.execute() verwendet wird, bei der eine Liste von Parameterdictionaries übergeben wurde. Dies zeigt SQLAlchemy Core an, dass die SQL-Anweisung und die verarbeiteten Parametersätze an cursor.executemany() übergeben werden sollen, wo die Anweisung vom Treiber für jedes Parameterdictionary einzeln aufgerufen wird.

Eine wichtige Einschränkung der Methode cursor.executemany() in Verbindung mit allen bekannten DBAPIs ist, dass der cursor nicht so konfiguriert ist, dass er Zeilen zurückgibt, wenn diese Methode verwendet wird. Für **die meisten** Backends (eine bemerkenswerte Ausnahme sind die python-oracledb / cx_Oracle DBAPIs) bedeutet dies, dass Anweisungen wie INSERT..RETURNING typischerweise nicht direkt mit cursor.executemany() verwendet werden können, da DBAPIs normalerweise die einzelnen Zeilen aus jeder INSERT-Ausführung nicht aggregieren.

Um diese Einschränkung zu überwinden, implementiert SQLAlchemy ab Version 2.0 eine alternative Form von „executemany“, die als „Insert Many Values“-Verhalten für INSERT-Anweisungen bekannt ist. Dieses Feature nutzt cursor.execute(), um eine INSERT-Anweisung aufzurufen, die mit mehreren Parametersätzen in einer einzigen Round-Trip ausgeführt wird, wodurch derselbe Effekt wie bei der Verwendung von cursor.executemany() erzielt wird und gleichzeitig RETURNING unterstützt wird.

Siehe auch

Mehrere Parameter senden - Tutorial-Einführung in „executemany“

„Insert Many Values“-Verhalten für INSERT-Anweisungen - SQLAlchemy-Funktion, die die Verwendung von RETURNING mit „executemany“ ermöglicht

ablaufen¶

abgelaufen¶

lässt ablaufen¶

ablaufend¶

Ablaufend¶

Im SQLAlchemy ORM bezieht sich dies auf den Zeitpunkt, an dem die Daten in einem persistenten oder manchmal detached Objekt gelöscht werden, sodass beim nächsten Zugriff auf die Attribute des Objekts eine Lazy Load SQL-Abfrage ausgeführt wird, um die Daten für dieses Objekt in der aktuellen laufenden Transaktion zu aktualisieren.

Siehe auch

Aktualisieren / Ablaufen

Fassade¶

Ein Objekt, das als frontseitige Schnittstelle dient und komplexeren zugrunde liegenden oder strukturellen Code maskiert.

Siehe auch

Fassadenmuster (via Wikipedia)

flush¶

flushing¶

flushed¶

Dies bezieht sich auf den eigentlichen Prozess, der von der Arbeitseinheit verwendet wird, um Änderungen an einer Datenbank zu übermitteln. In SQLAlchemy erfolgt dieser Prozess über das Session-Objekt und ist normalerweise automatisch, kann aber auch manuell gesteuert werden.

Siehe auch

Flushing

fremdschlüssel-Constraint¶

Eine referentielle Einschränkung zwischen zwei Tabellen. Ein Fremdschlüssel ist ein Feld oder eine Menge von Feldern in einer relationalen Tabelle, die mit einem Kandidatenschlüssel einer anderen Tabelle übereinstimmt. Der Fremdschlüssel kann zum Querverweisen von Tabellen verwendet werden. (via Wikipedia)

Ein Fremdschlüssel-Constraint kann einer Tabelle in Standard-SQL mit DDL wie folgt hinzugefügt werden:

ALTER TABLE employee ADD CONSTRAINT dep_id_fk
FOREIGN KEY (employee) REFERENCES department (dep_id)

Siehe auch

Fremdschlüssel-Constraint (via Wikipedia)

FROM-Klausel¶

Der Teil der SELECT-Anweisung, der die anfängliche Quelle der Zeilen angibt.

Eine einfache SELECT-Anweisung wird ein oder mehrere Tabellennamen in ihrer FROM-Klausel enthalten. Mehrere Quellen sind durch ein Komma getrennt.

SELECT user.name, address.email_address
FROM user, address
WHERE user.id=address.user_id

Die FROM-Klausel ist auch der Ort, an dem explizite Joins angegeben werden. Wir können die obige SELECT-Anweisung mit einem einzigen FROM-Element neu schreiben, das aus einem JOIN der beiden Tabellen besteht.

SELECT user.name, address.email_address
FROM user JOIN address ON user.id=address.user_id

Identitätsschlüssel¶

Ein Schlüssel, der ORM-gemappten Objekten zugeordnet ist und ihre primäre Schlüsselidentität innerhalb der Datenbank sowie ihre eindeutige Identität innerhalb einer Session Identitätszuordnung identifiziert.

In SQLAlchemy können Sie den Identitätsschlüssel eines ORM-Objekts mithilfe der inspect() API anzeigen, um das Zustandsverfolgungsobjekt InstanceState zurückzugeben, und dann auf das Attribut InstanceState.key zuzugreifen.

>>> from sqlalchemy import inspect
>>> inspect(some_object).key
(<class '__main__.MyTable'>, (1,), None)

Siehe auch

Identitätszuordnung

Identitätszuordnung¶

Eine Zuordnung zwischen Python-Objekten und ihren Datenbankidentitäten. Die Identitätszuordnung ist eine Sammlung, die einem ORM Session-Objekt zugeordnet ist und eine einzige Instanz jedes Datenbankobjekts unter dessen Identität verwaltet. Der Vorteil dieses Musters besteht darin, dass alle Vorgänge für eine bestimmte Datenbankidentität transparent auf eine einzige Objektinstanz koordiniert werden. Bei der Verwendung einer Identitätszuordnung in Verbindung mit einer isolierten Transaktion kann ein Verweis auf ein Objekt, von dem bekannt ist, dass es einen bestimmten Primärschlüssel hat, praktisch als Proxy für die eigentliche Datenbankzeile betrachtet werden.

Siehe auch

Identitätszuordnung (via Martin Fowler)

Abrufen nach Primärschlüssel - wie ein Objekt in der Identitätszuordnung anhand des Primärschlüssels nachgeschlagen wird.

imperativ¶

deklarativ¶

Im SQLAlchemy ORM beziehen sich diese Begriffe auf zwei verschiedene Stile der Zuordnung von Python-Klassen zu Datenbanktabellen.

Siehe auch

Deklarative Zuordnung

Imperative Zuordnung

insertmanyvalues¶

Dies bezieht sich auf eine SQLAlchemy-spezifische Funktion, die es INSERT-Anweisungen ermöglicht, Tausende von neuen Zeilen innerhalb einer einzigen Anweisung zu emittieren und gleichzeitig serverseitig generierte Werte inline aus der Anweisung mithilfe von RETURNING oder ähnlichem zurückzugeben, um die Leistung zu optimieren. Die Funktion soll für ausgewählte Backends transparent verfügbar sein, bietet aber einige Konfigurationsoptionen. Eine vollständige Beschreibung dieser Funktion finden Sie im Abschnitt „Insert Many Values“ Verhalten für INSERT-Anweisungen.

Siehe auch

„Insert Many Values“-Verhalten für INSERT-Anweisungen

instrumentierung¶

instrumentiert¶

instrumentieren¶

Instrumentierung bezieht sich auf den Prozess der Erweiterung der Funktionalität und des Attributsatzes einer bestimmten Klasse. Idealerweise sollte das Verhalten der Klasse nahe an einer regulären Klasse bleiben, mit der Ausnahme, dass zusätzliche Verhaltensweisen und Funktionen verfügbar gemacht werden. Der SQLAlchemy Mapping-Prozess fügt unter anderem datenbankaktivierte Deskriptoren zu einer gemappten Klasse hinzu, von denen jeder eine bestimmte Datenbankspalte oder Beziehung zu einer verwandten Klasse darstellt.

isolation¶

isoliert¶

isolationsebene¶

Die Isolationseigenschaft des ACID-Modells stellt sicher, dass die gleichzeitige Ausführung von Transaktionen zu einem Systemzustand führt, der erzielt würde, wenn Transaktionen seriell, d. h. nacheinander, ausgeführt würden. Jede Transaktion muss in totaler Isolation ausgeführt werden, d. h. wenn T1 und T2 gleichzeitig ausgeführt werden, sollten sie voneinander unabhängig bleiben. (via Wikipedia)

Siehe auch

ACID

Isolation (via Wikipedia)

verzögerte Initialisierung¶

Eine Taktik, bestimmte Initialisierungsaktionen, wie z. B. das Erstellen von Objekten, das Befüllen von Daten oder das Herstellen einer Verbindung zu anderen Diensten, so lange zu verzögern, bis diese Ressourcen benötigt werden.

Siehe auch

Verzögerte Initialisierung (via Wikipedia)

lazy load¶

lazy loads¶

lazy loaded¶

lazy loading¶

Im Objektrelationalen Mapping bezieht sich ein „Lazy Load“ auf ein Attribut, das seinen datenbankseitigen Wert für einen bestimmten Zeitraum, typischerweise wenn das Objekt zum ersten Mal geladen wird, nicht enthält. Stattdessen erhält das Attribut eine Memoisation, die dazu führt, dass es beim ersten Gebrauch auf die Datenbank zugreift und seine Daten lädt. Mit diesem Muster können die Komplexität und die Zeit, die bei Objektabrufen aufgewendet werden, manchmal reduziert werden, da Attribute für verwandte Tabellen nicht sofort behandelt werden müssen.

Lazy Loading ist das Gegenteil von Eager Loading.

Innerhalb von SQLAlchemy ist Lazy Loading ein Schlüsselmerkmal des ORM und gilt für Attribute, die auf einer benutzerdefinierten Klasse gemappt sind. Wenn auf Attribute zugegriffen wird, die auf Datenbankspalten oder verwandte Objekte verweisen, für die kein geladener Wert vorhanden ist, nutzt das ORM die Session, mit der das aktuelle Objekt im persistenten Zustand assoziiert ist, und sendet eine SELECT-Anweisung in der aktuellen Transaktion aus, wobei eine neue Transaktion gestartet wird, falls keine im Gange war. Befindet sich das Objekt im detached-Zustand und ist nicht mit einer Session assoziiert, wird dies als Fehlerzustand betrachtet und eine informative Ausnahme ausgelöst.

Siehe auch

Lazy Load (via Martin Fowler)

N plus eins Problem

Spaltenladeoptionen – enthält Informationen zum Lazy Loading von ORM-gemappten Spalten.

Beziehungsladetechniken – enthält Informationen zum Lazy Loading von ORM-verwandten Objekten.

Implizite E/A bei Verwendung von AsyncSession vermeiden – Tipps zur Vermeidung von Lazy Loading bei Verwendung der Asynchronen E/A (asyncio)-Erweiterung.

viele zu viele¶

Ein Stil von sqlalchemy.orm.relationship(), der zwei Tabellen über eine dazwischen liegende Tabelle verbindet. Mit dieser Konfiguration kann jede beliebige Anzahl von Zeilen auf der linken Seite auf jede beliebige Anzahl von Zeilen auf der rechten Seite verweisen und umgekehrt.

Ein Schema, in dem Mitarbeiter Projekten zugeordnet werden können.

CREATE TABLE employee (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30)
)

CREATE TABLE project (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30)
)

CREATE TABLE employee_project (
    employee_id INTEGER PRIMARY KEY,
    project_id INTEGER PRIMARY KEY,
    FOREIGN KEY employee_id REFERENCES employee(id),
    FOREIGN KEY project_id REFERENCES project(id)
)

Oben ist die Tabelle employee_project die viele-zu-viele-Tabelle, die natürlich einen zusammengesetzten Primärschlüssel bildet, der aus dem Primärschlüssel jeder verwandten Tabelle besteht.

In SQLAlchemy kann die Funktion sqlalchemy.orm.relationship() diesen Beziehungsstil auf weitgehend transparente Weise darstellen, wobei die viele-zu-viele-Tabelle unter Verwendung von einfacher Tabellenmetadaten angegeben wird.

class Employee(Base):
    __tablename__ = "employee"

    id = Column(Integer, primary_key=True)
    name = Column(String(30))

    projects = relationship(
        "Project",
        secondary=Table(
            "employee_project",
            Base.metadata,
            Column("employee_id", Integer, ForeignKey("employee.id"), primary_key=True),
            Column("project_id", Integer, ForeignKey("project.id"), primary_key=True),
        ),
        backref="employees",
    )


class Project(Base):
    __tablename__ = "project"

    id = Column(Integer, primary_key=True)
    name = Column(String(30))

Oben sind die Sammlungen Employee.projects und die rückverweisende Sammlung Project.employees definiert.

proj = Project(name="Client A")

emp1 = Employee(name="emp1")
emp2 = Employee(name="emp2")

proj.employees.extend([emp1, emp2])

Siehe auch

Verknüpfungsbeziehung

Beziehung

One-to-Many

Many-to-One

viele zu eins¶

Ein Stil von relationship(), der einen Fremdschlüssel in der Tabelle des übergeordneten Mappers mit dem Primärschlüssel einer verwandten Tabelle verknüpft. Jedes übergeordnete Objekt kann dann auf genau null oder ein verwandtes Objekt verweisen.

Die verwandten Objekte haben ihrerseits implizit oder explizit eine eins-zu-viele-Beziehung zu beliebig vielen übergeordneten Objekten, die auf sie verweisen.

Ein Beispiel für ein viele-zu-eins-Schema (das, wie gesagt, identisch mit dem eins-zu-viele-Schema ist).

CREATE TABLE department (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30)
)

CREATE TABLE employee (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30),
    dep_id INTEGER REFERENCES department(id)
)

Die Beziehung von employee zu department ist viele-zu-eins, da viele Mitarbeiterdatensätze einer einzelnen Abteilung zugeordnet werden können. Eine SQLAlchemy-Zuordnung könnte so aussehen:

class Department(Base):
    __tablename__ = "department"
    id = Column(Integer, primary_key=True)
    name = Column(String(30))


class Employee(Base):
    __tablename__ = "employee"
    id = Column(Integer, primary_key=True)
    name = Column(String(30))
    dep_id = Column(Integer, ForeignKey("department.id"))
    department = relationship("Department")

Siehe auch

Beziehung

One-to-Many

backref

mapping¶

gemappt¶

gemappte Klasse¶

ORM-gemappte Klasse¶

Wir sagen, eine Klasse ist „gemappt“, wenn sie mit einer Instanz der Klasse Mapper verbunden wurde. Dieser Prozess assoziiert die Klasse mit einer Datenbanktabelle oder einem anderen auswählbaren Konstrukt, sodass Instanzen davon mithilfe einer Session persistiert und geladen werden können.

Siehe auch

Übersicht über ORM-gemappte Klassen

marshalling¶

data marshalling¶

Der Prozess der Umwandlung der Speicherrepräsentation eines Objekts in ein Datenformat, das für die Speicherung oder Übertragung an einen anderen Teil eines Systems geeignet ist, wenn Daten zwischen verschiedenen Teilen eines Computerprogramms oder von einem Programm zu einem anderen verschoben werden müssen. Im Zusammenhang mit SQLAlchemy müssen wir Daten oft in ein geeignetes Format „marshallen“, um sie für INSERT- und UPDATE-Anweisungen in die relationale Datenbank zu übergeben.

Siehe auch

Marshalling (via Wikipedia)

Erweiterung vorhandener Typen – SQLAlchemy’s TypeDecorator wird häufig für das Marshalling von Daten verwendet, wenn Daten für INSERT- und UPDATE-Anweisungen in die Datenbank gesendet werden, und für das „Unmarshalling“ von Daten, wenn sie mithilfe von SELECT-Anweisungen abgerufen werden.

metadata¶

Datenbank-Metadaten¶

Tabellenmetadaten¶

Der Begriff „Metadaten“ bezieht sich im Allgemeinen auf „Daten, die Daten beschreiben“; Daten, die selbst das Format und/oder die Struktur anderer Datenarten darstellen. In SQLAlchemy bezieht sich der Begriff „Metadaten“ typischerweise auf den MetaData-Konstrukt, eine Sammlung von Informationen über die Tabellen, Spalten, Constraints und andere DDL-Objekte, die in einer bestimmten Datenbank vorhanden sein können.

Siehe auch

Metadaten-Zuordnung (via Martin Fowler)

Arbeiten mit Datenbank-Metadaten – im SQLAlchemy Unified Tutorial

Method Chaining¶

generativ¶

„Method Chaining“, im SQLAlchemy-Dokumentationsumfang als „generativ“ bezeichnet, ist eine objektorientierte Technik, bei der der Zustand eines Objekts durch Aufrufen von Methoden auf dem Objekt konstruiert wird. Das Objekt verfügt über eine beliebige Anzahl von Methoden, von denen jede ein neues Objekt (oder in einigen Fällen dasselbe Objekt) mit zusätzlichem Zustand zurückgibt, der dem Objekt hinzugefügt wurde.

Die beiden SQLAlchemy-Objekte, die Method Chaining am meisten nutzen, sind das Select-Objekt und das Query-Objekt. Zum Beispiel kann einem Select-Objekt durch Aufrufen der Methoden Select.where() und Select.order_by() zwei Ausdrücke zu seiner WHERE-Klausel sowie eine ORDER BY-Klausel zugewiesen werden.

stmt = (
    select(user.c.name)
    .where(user.c.id > 5)
    .where(user.c.name.like("e%"))
    .order_by(user.c.name)
)

Jeder obige Methodenaufruf gibt eine Kopie des ursprünglichen Select-Objekts mit zusätzlichen Qualifizierern zurück.

Mixin-Klasse¶

Mixin-Klassen¶

Ein gängiges objektorientiertes Muster, bei dem eine Klasse Methoden oder Attribute zur Verwendung durch andere Klassen enthält, ohne die Elternklasse dieser anderen Klassen sein zu müssen.

Siehe auch

Mixin (via Wikipedia)

N plus eins Problem¶

N plus eins¶

Das N plus eins Problem ist ein häufiger Nebeneffekt des Lazy Load-Musters, bei dem eine Anwendung ein verwandtes Attribut oder eine Sammlung auf jedem Element eines Ergebnissets von Objekten durchlaufen möchte, wobei dieses Attribut oder diese Sammlung über das Lazy Load-Muster geladen werden soll. Das Endergebnis ist, dass eine SELECT-Anweisung gesendet wird, um das anfängliche Ergebnisset von übergeordneten Objekten zu laden; dann wird, während die Anwendung jedes Element durchläuft, für jedes Element eine zusätzliche SELECT-Anweisung gesendet, um das verwandte Attribut oder die Sammlung für dieses Element zu laden. Das Endergebnis ist, dass für ein Ergebnisset von N übergeordneten Objekten N + 1 SELECT-Anweisungen gesendet werden.

Das N plus eins Problem wird durch Eager Loading gemildert.

Siehe auch

Lade-Strategien

Techniken für das Laden von Beziehungen

eins zu viele¶

Ein Stil von relationship(), der den Primärschlüssel der Tabelle des übergeordneten Mappers mit dem Fremdschlüssel einer verwandten Tabelle verknüpft. Jedes eindeutige übergeordnete Objekt kann dann null oder mehr eindeutige verwandte Objekte referenzieren.

Die verwandten Objekte haben ihrerseits implizit oder explizit eine viele-zu-eins-Beziehung zu ihrem übergeordneten Objekt.

Ein Beispiel für ein eins-zu-viele-Schema (das, wie gesagt, identisch mit dem viele-zu-eins-Schema ist).

CREATE TABLE department (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30)
)

CREATE TABLE employee (
    id INTEGER PRIMARY KEY,
    name VARCHAR(30),
    dep_id INTEGER REFERENCES department(id)
)

Die Beziehung von department zu employee ist eins-zu-viele, da viele Mitarbeiterdatensätze einer einzelnen Abteilung zugeordnet werden können. Eine SQLAlchemy-Zuordnung könnte so aussehen:

class Department(Base):
    __tablename__ = "department"
    id = Column(Integer, primary_key=True)
    name = Column(String(30))
    employees = relationship("Employee")


class Employee(Base):
    __tablename__ = "employee"
    id = Column(Integer, primary_key=True)
    name = Column(String(30))
    dep_id = Column(Integer, ForeignKey("department.id"))

Siehe auch

Beziehung

Many-to-One

backref

ORM-annotiert¶

Annotationen¶

Der Ausdruck „ORM-annotiert“ bezieht sich auf einen internen Aspekt von SQLAlchemy, bei dem ein Core-Objekt wie ein Column-Objekt zusätzliche Laufzeitinformationen mitführen kann, die es als zu einer bestimmten ORM-Zuordnung gehörig kennzeichnen. Der Begriff sollte nicht mit dem gebräuchlichen Ausdruck „Typ-Annotation“ verwechselt werden, der sich auf Python-Quellcode-„Typ-Hinweise“ für die statische Typisierung bezieht, wie sie in PEP 484 eingeführt wurden.

Die meisten Codebeispiele in der SQLAlchemy-Dokumentation sind mit einer kleinen Anmerkung versehen, die sich auf „Annotiertes Beispiel“ oder „Nicht annotiertes Beispiel“ bezieht. Dies bezieht sich darauf, ob das Beispiel PEP 484-annotiert ist oder nicht, und steht nicht im Zusammenhang mit dem SQLAlchemy-Konzept „ORM-annotiert“.

Wenn der Ausdruck „ORM-annotiert“ in der Dokumentation vorkommt, bezieht er sich auf Core-SQL-Ausdrucksobjekte wie Table, Column und Select-Objekte, die aus einem oder mehreren ORM-Mappings stammen oder sich auf Unterelemente beziehen, die aus einem oder mehreren ORM-Mappings stammen, und daher ORM-spezifische Interpretationen und/oder Verhaltensweisen aufweisen, wenn sie an ORM-Methoden wie Session.execute() übergeben werden. Wenn wir beispielsweise ein Select-Objekt aus einem ORM-Mapping erstellen, wie die User-Klasse, die im ORM-Tutorial illustriert wird.

>>> stmt = select(User)

Der interne Zustand des obigen Select bezieht sich auf die Table, der User zugeordnet ist. Die User-Klasse selbst wird nicht sofort referenziert. So bleibt das Select-Konstrukt mit Core-Level-Prozessen kompatibel (beachten Sie, dass das Mitglied ._raw_columns von Select privat ist und nicht vom Endbenutzercode aufgerufen werden sollte).

>>> stmt._raw_columns
[Table('user_account', MetaData(), Column('id', Integer(), ...)]

Wenn jedoch unser Select an eine ORM- Session übergeben wird, werden die indirekt mit dem Objekt assoziierten ORM-Entitäten verwendet, um dieses Select in einem ORM-Kontext zu interpretieren. Die eigentlichen „ORM-Annotationen“ sind in einer weiteren privaten Variablen ._annotations zu sehen.

>>> stmt._raw_columns[0]._annotations
immutabledict({
  'entity_namespace': <Mapper at 0x7f4dd8098c10; User>,
  'parententity': <Mapper at 0x7f4dd8098c10; User>,
  'parentmapper': <Mapper at 0x7f4dd8098c10; User>
})

Daher bezeichnen wir stmt als ein **ORM-annotiertes select()-Objekt**. Es ist eine Select-Anweisung, die zusätzliche Informationen enthält, die dazu führen, dass sie bei Übergabe an Methoden wie Session.execute() auf eine ORM-spezifische Weise interpretiert wird.

pending¶

Dies beschreibt einen der Hauptzustände, den ein Objekt innerhalb einer Session haben kann; ein pending-Objekt ist ein neues Objekt, das keine Datenbankidentität hat, aber kürzlich mit einer Session assoziiert wurde. Wenn die Session einen Flush auslöst und die Zeile eingefügt wird, wechselt das Objekt in den persistenten Zustand.

Siehe auch

Kurze Einführung in Objektdzustände

persistent¶

Dies beschreibt einen der Hauptzustände, den ein Objekt innerhalb einer Session haben kann; ein persistentes Objekt ist ein Objekt, das eine Datenbankidentität (d. h. einen Primärschlüssel) hat und derzeit mit einer Session assoziiert ist. Jedes Objekt, das zuvor pending war und nun eingefügt wurde, befindet sich im persistenten Zustand, ebenso wie jedes Objekt, das von der Session aus der Datenbank geladen wurde. Wenn ein persistentes Objekt aus einer Session entfernt wird, wird es als detached bezeichnet.

Siehe auch

Kurze Einführung in Objektdzustände

plugin¶

plugin-aktiviert¶

pluginspezifisch¶

„plugin-enabled“ oder „plugin-specific“ kennzeichnet im Allgemeinen eine Funktion oder Methode in SQLAlchemy Core, die sich anders verhält, wenn sie in einem ORM-Kontext verwendet wird.

SQLAlchemy ermöglicht es Core-Konstrukten wie Select-Objekten, an einem „Plugin“-System teilzunehmen, das dem Objekt zusätzliche Verhaltensweisen und Funktionen injizieren kann, die standardmäßig nicht vorhanden sind.

Insbesondere ist das primäre „Plugin“ das „orm“-Plugin, das die Basis des Systems bildet, mit dem SQLAlchemy Core-Konstrukte verwendet, um SQL-Abfragen zu komponieren und auszuführen, die ORM-Ergebnisse zurückgeben.

Siehe auch

ORM-Abfrage vereinheitlicht mit Core Select

polymorph¶

Bezieht sich auf eine Funktion, die mehrere Typen gleichzeitig verarbeitet. In SQLAlchemy wird der Begriff normalerweise auf das Konzept einer ORM-gemappten Klasse angewendet, bei der eine Abfrageoperation unterschiedliche Unterklassen zurückgibt, basierend auf Informationen im Ergebnisdatensatz, typischerweise durch Überprüfung des Werts einer bestimmten Spalte im Ergebnis, bekannt als Diskriminator.

Polymorphes Laden in SQLAlchemy impliziert, dass eine oder eine Kombination aus drei verschiedenen Schemata verwendet wird, um eine Hierarchie von Klassen abzubilden: „joined“, „single“ und „concrete“. Der Abschnitt Mapping von Klassenerbhierarchien beschreibt die Erbhierarchie-Zuordnung vollständig.

primärer Schlüssel¶

primärer Schlüssel-Constraint¶

Ein Constraint, der die Eigenschaften jeder Zeile in einer Tabelle eindeutig definiert. Der Primärschlüssel muss Eigenschaften enthalten, die von keiner anderen Zeile dupliziert werden können. Der Primärschlüssel kann aus einem einzelnen Attribut oder mehreren Attributen in Kombination bestehen. (via Wikipedia)

Der Primärschlüssel einer Tabelle wird typischerweise, aber nicht immer, innerhalb der CREATE TABLE DDL definiert.

CREATE TABLE employee (
     emp_id INTEGER,
     emp_name VARCHAR(30),
     dep_id INTEGER,
     PRIMARY KEY (emp_id)
)

Siehe auch

zusammengesetzter Primärschlüssel

Primärschlüssel (via Wikipedia)

read committed¶

Eine der vier Isolations-Stufen von Datenbanken. Read Committed stellt sicher, dass eine Transaktion keinen Daten aus anderen gleichzeitigen Transaktionen ausgesetzt wird, die noch nicht committed wurden, wodurch sogenannte „Dirty Reads“ verhindert werden. Unter Read Committed kann es jedoch nicht wiederholbare Lesevorgänge geben, was bedeutet, dass sich die Daten in einer Zeile bei einem zweiten Lesevorgang ändern können, wenn eine andere Transaktion Änderungen committed hat.

read uncommitted¶

Eine der vier Isolations-Stufen von Datenbanken. Read Uncommitted stellt sicher, dass Änderungen an Datenbankdaten innerhalb einer Transaktion erst permanent werden, wenn die Transaktion committed wird. Innerhalb von Read Uncommitted kann es jedoch möglich sein, dass Daten, die in anderen Transaktionen nicht committed sind, innerhalb des Gültigkeitsbereichs einer anderen Transaktion sichtbar sind; diese werden als „Dirty Reads“ bezeichnet.

reflection¶

reflektiert¶

In SQLAlchemy bezieht sich dieser Begriff auf die Funktion des Abfragens von Schemakatalogen einer Datenbank, um Informationen über vorhandene Tabellen, Spalten, Constraints und andere Konstrukte zu laden. SQLAlchemy enthält Funktionen, die sowohl Rohdaten für diese Informationen liefern als auch Core/ORM-nutzbare Table-Objekte automatisch aus Datenbank-Schemakatalogen erstellen können.

Siehe auch

Reflektieren von Datenbankobjekten – vollständiger Hintergrund zur Datenbankreflexion.

Deklaratives Mappen mit reflektierten Tabellen – Hintergrundinformationen zur Integration von ORM-Mappings mit reflektierten Tabellen.

registry¶

Ein Objekt, das typischerweise global zugänglich ist und langlebige Informationen über einen Programmzustand enthält, der für viele Teile eines Programms allgemein nützlich ist.

Siehe auch

Registry (via Martin Fowler)

relational¶

relationale Algebra¶

Ein von Edgar F. Codd entwickeltes algebraisches System, das zur Modellierung und Abfrage der in relationalen Datenbanken gespeicherten Daten verwendet wird.

Siehe auch

Relationale Algebra (via Wikipedia)

relationship¶

relationships¶

Eine Verbindungseinheit zwischen zwei gemappten Klassen, die einer Beziehung zwischen den beiden Tabellen in der Datenbank entspricht.

Die Beziehung wird mit der SQLAlchemy-Funktion relationship() definiert. Nach der Erstellung inspiziert SQLAlchemy die beteiligten Argumente und zugrunde liegenden Mappings, um die Beziehung als eine von drei Arten zu klassifizieren: eins zu viele, viele zu eins oder viele zu viele. Mit dieser Klassifizierung übernimmt das Beziehungskonstrukt die Aufgabe, die entsprechenden Verknüpfungen in der Datenbank als Reaktion auf In-Memory-Objektassoziationen zu persistieren, sowie die Aufgabe, Objektverweise und Sammlungen basierend auf den aktuellen Verknüpfungen in der Datenbank in den Speicher zu laden.

Siehe auch

Beziehungskonfiguration

release¶

releases¶

released¶

Im Kontext von SQLAlchemy bezieht sich der Begriff „freigegeben“ auf den Prozess der Beendigung der Nutzung einer bestimmten Datenbankverbindung. SQLAlchemy nutzt Connection Pools, die eine Konfigurierbarkeit hinsichtlich der Lebensdauer von Datenbankverbindungen ermöglichen. Bei der Verwendung einer gepoolten Verbindung kann der Vorgang des „Schließens“ durch Aufruf einer Anweisung wie connection.close() dazu führen, dass die Verbindung an einen bestehenden Pool zurückgegeben wird, oder sie kann dazu führen, dass die zugrunde liegende TCP/IP-Verbindung, auf die sich diese Verbindung bezieht, tatsächlich heruntergefahren wird – welcher Vorgang stattfindet, hängt von der Konfiguration sowie dem aktuellen Zustand des Pools ab. Daher haben wir den Begriff *freigegeben* verwendet, um zu bedeuten: „Tue, was auch immer du mit Verbindungen tust, wenn wir sie nicht mehr benötigen“.

Der Begriff wird manchmal in der Phrase „transaktionale Ressourcen freigeben“ verwendet, um expliziter anzugeben, dass wir eigentlich den angesammelten transaktionalen Zustand auf der Verbindung „freigeben“. In den meisten Situationen erwirbt der Prozess der Auswahl aus Tabellen, der Ausgabe von Updates usw. isolierten Zustand auf dieser Verbindung sowie potenzielle Zeilen- oder Tabellensperren. Dieser Zustand ist lokal für eine bestimmte Transaktion auf der Verbindung und wird freigegeben, wenn wir einen Rollback ausgeben. Eine wichtige Funktion des Connection Pools ist, dass beim Zurückgeben einer Verbindung an den Pool auch die Methode connection.rollback() des DBAPI aufgerufen wird, so dass die Verbindung beim erneuten Einrichten für die Verwendung in einem „sauberen“ Zustand ist, ohne Referenzen auf die vorherigen Vorgänge zu halten.

Siehe auch

Connection Pooling

wiederholbares Lesen¶

Eine der vier Datenbank- Isolationsebenen, wiederholbares Lesen, bietet die gesamte Isolation von gelesene Daten beständig und darüber hinaus die Garantie, dass jede Zeile, die innerhalb einer Transaktion gelesen wird, von diesem Zeitpunkt an während der Dauer dieser Transaktion keine nachfolgenden externen Wertänderungen (d.h. von anderen gleichzeitigen UPDATE-Anweisungen) erfährt.

RETURNING¶

Dies ist eine Klausel, die kein SQL-Standard ist und von verschiedenen Backends in unterschiedlichen Formen bereitgestellt wird. Sie bietet die Möglichkeit, nach der Ausführung einer INSERT-, UPDATE- oder DELETE-Anweisung einen Ergebnisdatensatz zurückzugeben. Eine beliebige Menge von Spalten der übereinstimmenden Zeilen kann zurückgegeben werden, als ob sie aus einer SELECT-Anweisung erzeugt worden wären.

Die RETURNING-Klausel bietet sowohl eine dramatische Leistungssteigerung für gängige Update/Select-Szenarien, einschließlich des Abrufens von inline oder standardmäßig generierten Primärschlüsselwerten und Standardwerten zum Zeitpunkt ihrer Erstellung, als auch eine Möglichkeit, serverseitig generierte Standardwerte atomar abzurufen.

Ein Beispiel für RETURNING, idiomatisch für PostgreSQL, sieht wie folgt aus:

INSERT INTO user_account (name) VALUES ('new name') RETURNING id, timestamp

Oben liefert die INSERT-Anweisung nach Ausführung einen Ergebnisdatensatz, der die Werte der Spalten user_account.id und user_account.timestamp enthält, die oben als Standardwerte generiert worden sein sollten, da sie nicht anderweitig enthalten sind (beachten Sie jedoch, dass beliebige Spalten oder SQL-Ausdrücke in RETURNING platziert werden können, nicht nur Spalten mit Standardwerten).

Die Backends, die derzeit RETURNING oder eine ähnliche Konstruktion unterstützen, sind PostgreSQL, SQL Server, Oracle Database und Firebird. Die Implementierungen von PostgreSQL und Firebird sind im Allgemeinen voll funktionsfähig, während die Implementierungen von SQL Server und Oracle Database Einschränkungen aufweisen. Auf SQL Server ist die Klausel für INSERT- und UPDATE-Anweisungen als „OUTPUT INSERTED“ und für DELETE-Anweisungen als „OUTPUT DELETED“ bekannt; die wichtigste Einschränkung ist, dass Trigger in Verbindung mit diesem Schlüsselwort nicht unterstützt werden. In Oracle Database ist sie als „RETURNING…INTO“ bekannt und erfordert, dass der Wert in einen OUT-Parameter platziert wird, was nicht nur eine umständliche Syntax bedeutet, sondern auch nur für eine Zeile gleichzeitig verwendet werden kann.

SQLAlchemys UpdateBase.returning() System bietet eine Abstraktionsschicht über den RETURNING-Systemen dieser Backends, um eine konsistente Schnittstelle für die Rückgabe von Spalten zu bieten. Die ORM enthält auch viele Optimierungen, die RETURNING nutzen, wenn es verfügbar ist.

selektierbar¶

Ein Begriff, der in SQLAlchemy verwendet wird, um eine SQL-Konstruktion zu beschreiben, die eine Sammlung von Zeilen darstellt. Er ist weitgehend ähnlich dem Konzept einer „Relation“ in der Relationenalgebra. In SQLAlchemy gelten Objekte, die von der Klasse Selectable erben, als „selektierbar“, wenn SQLAlchemy Core verwendet wird. Die beiden gängigsten Konstrukte sind die Table und die Select-Anweisung.

Sentinel¶

Einfügen-Sentinel¶

Dies ist ein SQLAlchemy-spezifischer Begriff, der sich auf eine Column bezieht, die für eine Massen- insertmanyvalues Operation verwendet werden kann, um eingefügte Datensätze gegen über RETURNING oder ähnliches zurückgegebene Zeilen zu verfolgen. Eine solche Spaltenkonfiguration ist für Fälle notwendig, in denen das insertmanyvalues-Feature eine optimierte INSERT..RETURNING-Anweisung für viele Zeilen gleichzeitig durchführt und dennoch die Reihenfolge der zurückgegebenen Zeilen mit den Eingabedaten garantieren kann.

Für typische Anwendungsfälle kann der SQLAlchemy SQL-Compiler automatisch surgotale Ganzzahl-Primärschlüsselspalten als „Einfügen-Sentinels“ verwenden, und es ist keine Benutzerkonfiguration erforderlich. Für weniger gängige Fälle mit anderen Arten von serverseitig generierten Primärschlüsselwerten können explizite „Einfügen-Sentinel“-Spalten optional in Tabellenmetadaten konfiguriert werden, um INSERT-Anweisungen zu optimieren, die viele Zeilen auf einmal einfügen.

Siehe auch

RETURNING-Zeilen mit Parametersätzen korrelieren – im Abschnitt „Insert Many Values“-Verhalten für INSERT-Anweisungen

seriell¶

Eine der vier Datenbank- Isolationsebenen, seriell, bietet die gesamte Isolation von wiederholbarem Lesen und garantiert zusätzlich durch einen sperrbasierten Ansatz, dass sogenannte „Phantomlesevorgänge“ nicht auftreten können. Das bedeutet, dass Zeilen, die innerhalb des Geltungsbereichs anderer Transaktionen eingefügt oder gelöscht werden, innerhalb dieser Transaktion nicht erkennbar sind. Es wird garantiert, dass eine innerhalb dieser Transaktion gelesene Zeile weiterhin existiert, und es wird garantiert, dass eine nicht existierende Zeile nicht von einer anderen Transaktion eingefügt werden kann.

Serielle Isolation basiert typischerweise auf der Sperrung von Zeilen oder Zeilenbereichen, um diesen Effekt zu erzielen, und kann die Wahrscheinlichkeit von Deadlocks erhöhen und die Leistung beeinträchtigen. Es gibt jedoch auch nicht-sperrbasierte Schemata, die notwendigerweise auf der Ablehnung von Transaktionen beruhen, wenn Schreibkollisionen erkannt werden.

Sitzung¶

Der Container oder Geltungsbereich für ORM-Datenbankoperationen. Sitzungen laden Instanzen aus der Datenbank, verfolgen Änderungen an gemappten Instanzen und speichern Änderungen in einer einzigen Arbeitseinheit, wenn sie geleert werden.

Siehe auch

Verwendung der Sitzung

Unterabfrage¶

Skalare Unterabfrage¶

Bezieht sich auf eine SELECT-Anweisung, die in eine umschließende SELECT eingebettet ist.

Eine Unterabfrage gibt es in zwei allgemeinen Formen: eine als „skalare Auswahl“ bekannte, die spezifisch genau eine Zeile und eine Spalte zurückgeben muss, und die andere Form, die als „abgeleitete Tabelle“ fungiert und als Zeilenquelle für die FROM-Klausel einer anderen Auswahl dient. Eine skalare Auswahl kann in der WHERE-Klausel, der Spaltenklausel, der ORDER BY-Klausel oder der HAVING-Klausel der umschließenden Auswahl platziert werden, während die abgeleitete Tabellenform in der FROM-Klausel der umschließenden SELECT platziert werden kann.

Beispiele

eine skalare Unterabfrage, die in der Spaltenklausel einer umschließenden SELECT platziert ist. Die Unterabfrage in diesem Beispiel ist eine korrelierte Unterabfrage, da ein Teil der von ihr ausgewählten Zeilen über die umschließende Anweisung gegeben wird.
```
SELECT id, (SELECT name FROM address WHERE address.user_id=user.id)
FROM user
```
eine skalare Unterabfrage, die in der WHERE-Klausel einer umschließenden SELECT platziert ist. Diese Unterabfrage in diesem Beispiel ist nicht korreliert, da sie ein festes Ergebnis auswählt.
```
SELECT id, name FROM user
WHERE status=(SELECT status_id FROM status_code WHERE code='C')
```

eine abgeleitete Tabellenunterabfrage, die in der FROM-Klausel einer umschließenden SELECT platziert ist. Eine solche Unterabfrage erhält fast immer einen Alias-Namen.

SELECT user.id, user.name, ad_subq.email_address
FROM
    user JOIN
    (select user_id, email_address FROM address WHERE address_type='Q') AS ad_subq
    ON user.id = ad_subq.user_id

transient¶

Dies beschreibt einen der Hauptzustände eines Objekts innerhalb einer Sitzung; ein transients Objekt ist ein neues Objekt, das keine Datenbankidentität hat und noch nicht mit einer Sitzung verknüpft wurde. Wenn das Objekt der Sitzung hinzugefügt wird, wechselt es in den schwebenden Zustand.

Siehe auch

Kurze Einführung in Objektdzustände

eindeutige Einschränkung¶

eindeutiger Schlüsselindex¶

Ein eindeutiger Schlüsselindex kann jeden Datenwert in einer Datenbanktabelle eindeutig identifizieren. Ein eindeutiger Schlüsselindex besteht aus einer einzelnen Spalte oder einer Gruppe von Spalten in einer einzigen Datenbanktabelle. Keine zwei unterschiedlichen Zeilen oder Datensätze in einer Datenbanktabelle können den gleichen Datenwert (oder die gleiche Kombination von Datenwerten) in diesen eindeutigen Schlüsselindexspalten haben, wenn keine NULL-Werte verwendet werden. Abhängig von seinem Design kann eine Datenbanktabelle viele eindeutige Schlüsselindizes, aber höchstens einen Primärschlüsselindex haben.

(via Wikipedia)

Siehe auch

Eindeutiger Schlüssel (via Wikipedia)

Arbeitseinheit¶

Eine Softwarearchitektur, bei der ein Persistenzsystem wie ein Objekt-Relationaler Mapper eine Liste von Änderungen an einer Reihe von Objekten führt und diese ausstehenden Änderungen periodisch in die Datenbank schreibt.

SQLAlchemys Session implementiert das Unit-of-Work-Muster, bei dem Objekte, die mit Methoden wie Session.add() zur Session hinzugefügt werden, dann an der Unit-of-Work-basierten Persistenz teilnehmen.

Für eine Schritt-für-Schritt-Anleitung, wie Unit-of-Work-Persistenz in SQLAlchemy aussieht, beginnen Sie mit dem Abschnitt Datenmanipulation mit der ORM im SQLAlchemy Unified Tutorial. Für weitere Details siehe Grundlagen der Sitzungsverwendung in der allgemeinen Referenzdokumentation.

Siehe auch

Arbeitseinheit (via Martin Fowler)

Datenmanipulation mit der ORM

Grundlagen der Sitzungsverwendung

Versions-ID-Spalte¶

In SQLAlchemy bezieht sich dies auf die Verwendung einer bestimmten Tabellenspalte, die die „Version“ einer bestimmten Zeile verfolgt, während sich die Werte der Zeile ändern. Obwohl es verschiedene Arten von relationalen Mustern gibt, die eine „Versions-ID-Spalte“ auf unterschiedliche Weise verwenden, enthält die ORM von SQLAlchemy eine besondere Funktion, die es ermöglicht, eine solche Spalte als Mittel zum Testen auf veraltete Daten zu konfigurieren, wenn eine Zeile mit neuen Informationen aktualisiert wird. Wenn die zuletzt bekannte „Version“ dieser Spalte nicht mit der der Zeile übereinstimmt, wenn wir versuchen, neue Daten in die Zeile einzufügen, wissen wir, dass wir auf veralteten Informationen handeln.

Es gibt auch andere Möglichkeiten, „versionierte“ Zeilen in einer Datenbank zu speichern, die oft als „temporale“ Daten bezeichnet werden. Zusätzlich zu SQLAlchemys Versionierungsfunktion sind weitere Beispiele in der Dokumentation aufgeführt, siehe die Links unten.

Siehe auch

Konfigurieren eines Versionszählers – SQLAlchemys integrierte Versions-ID-Funktion.

Objekte versionieren – weitere Beispiele für Mappings, die Zeilen zeitlich versionieren.

WHERE-Klausel¶

Der Teil der SELECT-Anweisung, der die Kriterien angibt, nach denen Zeilen gefiltert werden sollen. Es handelt sich um eine einzelne SQL-Expression, die dem Schlüsselwort WHERE folgt.

SELECT user_account.name, user_account.email
FROM user_account
WHERE user_account.name = 'fred' AND user_account.status = 'E'

Oben bildet die Phrase WHERE user_account.name = 'fred' AND user_account.status = 'E' die WHERE-Klausel der SELECT.

SQLAlchemy 2.0 Dokumentation

SQLAlchemy 2.0 Dokumentation

SQLAlchemy 2.0 Dokumentation

Projektversionen

Glossar¶