Глоссарий

ACID
Модель ACID

Акроним «Atomicity, Consistency, Isolation, Durability»; набор свойств, гарантирующих надежную обработку транзакций базы данных. (через Википедию)

DBAPI
пеп-249

DBAPI - это сокращение фразы «Python Database API Specification». Это широко используемая спецификация в Python для определения общих шаблонов использования для всех пакетов подключения к базе данных. DBAPI - это API «низкого уровня», который обычно является системой самого низкого уровня, используемой в приложении Python для связи с базой данных. Система SQLAlchemy dialect построена вокруг работы DBAPI, предоставляя отдельные классы диалектов, которые обслуживают конкретный DBAPI поверх конкретного движка базы данных; например, URL create_engine() postgresql+psycopg2://@localhost/test относится к комбинации DBAPI/диалекта psycopg2, тогда как URL mysql+mysqldb://@localhost/test относится к комбинации DBAPI/диалекта MySQL for Python.

DDL

Аббревиатура от Data Definition Language. DDL - это подмножество SQL, которое реляционные базы данных используют для конфигурирования таблиц, ограничений и других постоянных объектов в схеме базы данных. SQLAlchemy предоставляет богатый API для построения и создания выражений DDL.

DML

Акроним для Язык манипулирования данными. DML - это подмножество SQL, которое реляционные базы данных используют для изменения данных в таблицах. DML обычно относится к трем широко известным операторам INSERT, UPDATE и DELETE, иначе известным как CRUD (сокращение от «Create, Read, Update, Delete»).

См.также

DML (via Wikipedia)

DDL

DQL

DQL

Акроним для Язык запросов к данным. DQL - это подмножество SQL, которое реляционные базы данных используют для чтения данных в таблицах. DQL почти исключительно ссылается на конструкцию SQL SELECT как на используемый оператор SQL верхнего уровня.

См.также

DQL (via Wikipedia)

DML

DDL

FROM пункт

Часть оператора SELECT, которая указывает на начальный источник строк.

Простой SELECT будет содержать одно или несколько имен таблиц в предложении FROM. Несколько источников разделяются запятой:

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

Предложение FROM также является тем местом, где задаются явные соединения. Мы можем переписать вышеприведенный SELECT, используя один элемент FROM, который состоит из JOIN двух таблиц:

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

Это относится к специфической для SQLAlchemy функции, которая позволяет операторам INSERT создавать тысячи новых строк в рамках одного оператора и в то же время позволяет возвращать генерируемые сервером значения в операторе с помощью RETURNING или аналогичных функций для оптимизации производительности. Эта функция должна быть прозрачно доступна для выбранных бэкендов, но предлагает некоторые конфигурационные возможности. Полное описание этой функции см. в разделе Поведение «Вставка многих значений» для операторов INSERT.

N плюс одна проблема
N плюс один

Проблема N плюс один является распространенным побочным эффектом шаблона lazy load, когда приложение хочет выполнить итерацию по связанному атрибуту или коллекции на каждом члене результирующего набора объектов, где этот атрибут или коллекция установлены для загрузки с помощью шаблона ленивой загрузки. В итоге выполняется оператор SELECT для загрузки начального результирующего набора родительских объектов; затем, по мере итерации приложения по каждому члену, для каждого члена выполняется дополнительный оператор SELECT для загрузки связанного атрибута или коллекции для этого члена. В итоге для результирующего набора из N родительских объектов будет выполнено N + 1 оператор SELECT.

Проблема N плюс один снимается с помощью eager loading.

ORM-аннотированный
аннотации

Фраза «ORM-annotated» относится к внутреннему аспекту SQLAlchemy, где объект Core, такой как объект Column, может нести дополнительную информацию во время выполнения, которая отмечает его принадлежность к определенному ORM-маппингу. Этот термин не следует путать с распространенной фразой «аннотация типа», которая относится к «подсказкам типа» исходного кода Python, используемым для статической типизации, как представлено в PEP 484.

Большинство документированных примеров кода SQLAlchemy имеют небольшое примечание «Аннотированный пример» или «Неаннотированный пример». Это относится к тому, аннотирован пример или нет, и не связано с понятием SQLAlchemy «ORM-аннотированный».

Когда в документации встречается фраза «ORM-annotated», это относится к объектам выражений Core SQL, таким как Table, Column и Select, которые происходят из или ссылаются на подэлементы, которые происходят из одного или более ORM отображений, и поэтому будут иметь специфические для ORM интерпретации и/или поведение при передаче ORM методам, таким как Session.execute(). Например, когда мы создаем объект Select из отображения ORM, такого как класс User, показанный в ORM Tutorial:

>>> stmt = select(User)

Внутреннее состояние приведенного выше Select относится к Table, на который сопоставлен User. На сам класс User непосредственно не ссылаются. Вот как конструкция Select остается совместимой с процессами уровня Core (обратите внимание, что член ._raw_columns в Select является приватным и не должен быть доступен коду конечного пользователя):

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

Однако, когда наш Select передается в ORM Session, сущности ORM, косвенно связанные с объектом, используются для интерпретации этого Select в контексте ORM. Фактические «ORM-аннотации» можно увидеть в другой частной переменной ._annotations:

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

Поэтому мы называем stmt объектом ORM-annotated select(). Это оператор Select, содержащий дополнительную информацию, которая заставляет интерпретировать его специфическим для ORM образом при передаче методам типа Session.execute().

активная нагрузка
большие нагрузки
с большой нагрузкой
активная загрузка
охотно загружать

В реляционном отображении объектов «нетерпеливая загрузка» относится к атрибуту, который заполняется своим значением со стороны базы данных одновременно с загрузкой самого объекта из базы данных. В SQLAlchemy термин «срочная загрузка» обычно относится к связанным коллекциям и экземплярам объектов, которые связаны между отображениями с помощью конструкции relationship(), но также может относиться к загрузке дополнительных атрибутов столбцов, часто из других таблиц, связанных с конкретной запрашиваемой таблицей, например, при использовании отображений inheritance.

Нетерпеливая загрузка - это противоположность lazy loading.

ассоциативные отношения

Двухуровневое отношение relationship, которое связывает две таблицы вместе с помощью таблицы ассоциации в середине. Отношение ассоциации отличается от отношения many to many тем, что таблица «многие-ко-многим» отображается полным классом, а не невидимо обрабатывается конструкцией sqlalchemy.orm.relationship(), как в случае «многие-ко-многим», так что дополнительные атрибуты явно доступны.

Например, если мы хотим связать сотрудников с проектами, сохраняя также конкретную роль этого сотрудника в проекте, реляционная схема может выглядеть следующим образом:

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)
)

Декларативное отображение SQLAlchemy для вышеуказанного может выглядеть следующим образом:

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")

Сотрудников можно добавить в проект, присвоив им имя роли:

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"),
    ]
)

См.также

many to many

атомарность

Атомарность является одним из компонентов модели ACID, и требует, чтобы каждая транзакция была «все или ничего»: если одна часть транзакции не работает, вся транзакция не работает, а состояние базы данных остается неизменным. Атомарная система должна гарантировать атомарность в любой ситуации, включая сбои питания, ошибки и аварии. (через Википедию)

в ожидании

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; ожидающий объект - это новый объект, который не имеет идентификатора базы данных, но недавно был связан с сессией. Когда сессия выдает команду flush и строка вставляется, объект переходит в состояние persistent.

ВОЗВРАЩЕНИЕ

Это нестандартное предложение, предоставляемое в различных формах некоторыми бэкендами, которое обеспечивает возврат набора результатов при выполнении оператора INSERT, UPDATE или DELETE. Может быть возвращен любой набор столбцов из сопоставленных строк, как если бы они были получены в результате выполнения оператора SELECT.

Предложение RETURNING обеспечивает значительное увеличение производительности в распространенных сценариях обновления/выбора, включая получение значений первичного ключа, сгенерированных в строке или по умолчанию, и значений по умолчанию в момент их создания, а также способ получения значений по умолчанию, сгенерированных сервером, атомарным способом.

Пример RETURNING, идиоматичный для PostgreSQL, выглядит следующим образом:

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

Выше, оператор INSERT предоставит после выполнения набор результатов, который включает значения столбцов user_account.id и user_account.timestamp, которые выше должны были быть сгенерированы как значения по умолчанию, поскольку в противном случае они не включены (но обратите внимание, что в RETURNING можно поместить любую серию столбцов или SQL-выражений, а не только столбцы со значениями по умолчанию).

Бэкенды, которые в настоящее время поддерживают RETURNING или аналогичную конструкцию, - это PostgreSQL, SQL Server, Oracle и Firebird. Реализации PostgreSQL и Firebird обычно являются полнофункциональными, в то время как реализации SQL Server и Oracle имеют оговорки. В SQL Server этот пункт известен как «OUTPUT INSERTED» для операторов INSERT и UPDATE и «OUTPUT DELETED» для операторов DELETE; главная оговорка заключается в том, что триггеры не поддерживаются в сочетании с этим ключевым словом. В Oracle он известен как «RETURNING…INTO» и требует, чтобы значение было помещено в параметр OUT, что означает не только неудобный синтаксис, но и то, что его можно использовать только для одного ряда за раз.

Система SQLAlchemy UpdateBase.returning() предоставляет уровень абстракции поверх систем RETURNING этих бэкендов, чтобы обеспечить согласованный интерфейс для возврата столбцов. ORM также включает в себя множество оптимизаций, которые используют RETURNING, когда он доступен.

выбираемый

Термин, используемый в SQLAlchemy для описания конструкции SQL, которая представляет собой коллекцию строк. Он во многом схож с понятием «отношение» в relational algebra. В SQLAlchemy объекты, являющиеся подклассами класса Selectable, считаются пригодными для использования в качестве «выбираемых» при использовании SQLAlchemy Core. Две наиболее распространенные конструкции - это конструкция Table и конструкция Select.

выпуск
выпускает
выпущено

В контексте SQLAlchemy термин «освобождение» относится к процессу завершения использования конкретного соединения с базой данных. В SQLAlchemy предусмотрено использование пулов соединений, что позволяет настраивать продолжительность жизни соединений с базой данных. При использовании пула соединений, процесс «закрытия» соединения, т.е. вызов оператора типа connection.close(), может иметь эффект возврата соединения в существующий пул, или эффект фактического закрытия основного TCP/IP соединения, на которое ссылается это соединение - что именно происходит, зависит от конфигурации, а также от текущего состояния пула. Поэтому мы использовали термин released, означающий «делайте все, что вы делаете с соединениями, когда мы закончили их использовать».

Иногда этот термин используется во фразе «освободить транзакционные ресурсы», чтобы более четко указать, что на самом деле мы «освобождаем» любое транзакционное состояние, которое накопилось на соединении. В большинстве ситуаций процесс выбора из таблиц, выпуска обновлений и т.д. приобретает состояние isolated на этом соединении, а также потенциальные блокировки строк или таблиц. Все это состояние является локальным для конкретной транзакции на соединении и освобождается, когда мы выполняем откат. Важной особенностью пула соединений является то, что когда мы возвращаем соединение в пул, также вызывается метод connection.rollback() DBAPI, так что когда соединение устанавливается для повторного использования, оно находится в «чистом» состоянии без ссылок на предыдущую серию операций.

грубый
CRUD

Акроним, означающий «Create, Update, Delete». Этот термин в SQL относится к набору операций, которые создают, изменяют и удаляют данные из базы данных, также известных как DML, и обычно относится к операторам INSERT, UPDATE и DELETE.

дескриптор
дескрипторы

В Python дескриптор - это атрибут объекта с «поведением связывания», доступ к атрибуту которого переопределен методами в descriptor protocol. Такими методами являются __get__(), __set__() и __delete__(). Если любой из этих методов определен для объекта, то говорят, что это дескриптор.

В SQLAlchemy дескрипторы активно используются для того, чтобы обеспечить поведение атрибутов для сопоставленных классов. Когда класс сопоставлен как:

class MyClass(Base):
    __tablename__ = "foo"

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

Класс MyClass будет mapped после завершения его определения, и тогда атрибуты id и data, начинающиеся как объекты Column, будут заменены системой instrumentation экземплярами InstrumentedAttribute, которые являются дескрипторами, предоставляющими вышеупомянутые методы __get__(), __set__() и __delete__(). При использовании на уровне класса InstrumentedAttribute будет генерироваться SQL-выражение:

>>> print(MyClass.data == 5)
{printsql}data = :data_1

и на уровне экземпляра отслеживает изменения значений, а также lazy loads выгружает атрибуты из базы данных:

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

>>> from sqlalchemy import inspect
>>> inspect(m1).attrs.data.history.added
"some data"
диалект

В SQLAlchemy «диалект» - это объект Python, который представляет информацию и методы, позволяющие выполнять операции с базой данных на определенном типе бэкенда базы данных и определенном типе драйвера Python (или DBAPI) для этой базы данных. Диалекты SQLAlchemy являются подклассами класса Dialect.

дискриминатор

Столбец набора результатов, который используется во время загрузки polymorphic для определения того, какой сопоставленный класс должен быть применен к конкретной входящей строке результатов.

долговечность

Долговечность - это свойство модели ACID, которое означает, что после фиксации транзакции она останется таковой даже в случае потери питания, сбоев или ошибок. В реляционной базе данных, например, после выполнения группы операторов SQL результаты должны храниться постоянно (даже если сразу после этого произойдет сбой базы данных). (через Википедию)

единица работы

Архитектура программного обеспечения, при которой система персистентности, например, объектно-реляционный картограф, ведет список изменений, внесенных в серию объектов, и периодически сбрасывает все эти изменения в базу данных.

SQLAlchemy’s Session реализует модель единицы работы, где объекты, добавленные в Session с помощью методов типа Session.add(), будут участвовать в персистенции в стиле единицы работы.

Для ознакомления с тем, как выглядит персистентность единиц работы в SQLAlchemy, начните с раздела Манипулирование данными с помощью ORM в Унифицированный учебник по SQLAlchemy. Затем для получения более подробной информации смотрите Основы использования сеанса в общей справочной документации.

идентификационный ключ

Ключ, связанный с объектами ORM-mapped, который идентифицирует их первичный ключ в базе данных, а также их уникальную идентичность в рамках Session identity map.

В SQLAlchemy можно просмотреть идентификационный ключ для объекта ORM, используя API inspect(), чтобы вернуть объект отслеживания InstanceState, затем посмотреть на атрибут InstanceState.key:

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

См.также

identity map

изоляция
изолированный
Изоляция
уровень изоляции

Свойство изоляции модели ACID гарантирует, что одновременное выполнение транзакций приводит к такому состоянию системы, которое было бы получено, если бы транзакции выполнялись последовательно, т.е. одна за другой. Каждая транзакция должна выполняться в полной изоляции, т.е. если T1 и T2 выполняются одновременно, то каждая из них должна оставаться независимой от другой. (через Википедию)

императив
декларативный

В SQLAlchemy ORM эти термины относятся к двум различным стилям отображения классов Python на таблицы базы данных.

иностранный гражданин

Ссылочное ограничение между двумя таблицами. иностранный

иностранный гражданин

ALTER TABLE employee ADD CONSTRAINT dep_id_fk
FOREIGN KEY (employee) REFERENCES department (dep_id)
исполнять многие

Этот термин относится к части спецификации PEP 249 DBAPI, указывающей на один оператор SQL, который может быть вызван против соединения с базой данных с несколькими наборами параметров. Конкретный метод известен как cursor.executemany(), и он имеет много поведенческих различий по сравнению с методом cursor.execute(), который используется для вызова одного оператора. Метод «executemany» выполняет данный SQL-оператор несколько раз, по одному разу для каждого набора переданных параметров. Общее обоснование использования метода «executemany» заключается в повышении производительности, при этом DBAPI может использовать такие приемы, как предварительная подготовка оператора только один раз или иная оптимизация для многократного вызова одного и того же оператора.

SQLAlchemy обычно использует метод cursor.executemany() автоматически, когда используется метод Connection.execute(), где был передан список словарей параметров; это указывает SQLAlchemy Core, что SQL оператор и обработанные наборы параметров должны быть переданы в cursor.executemany(), где оператор будет вызван драйвером для каждого словаря параметров отдельно.

Ключевым ограничением метода cursor.executemany(), используемого во всех известных DBAPI, является то, что cursor не настроен на возврат строк при использовании этого метода. Для большинства бэкендов (заметным исключением является cx_Oracle, / OracleDB DBAPIs) это означает, что операторы типа INSERT..RETURNING обычно не могут быть использованы с cursor.executemany() напрямую, поскольку DBAPI обычно не агрегируют один ряд из каждого выполнения INSERT вместе.

Чтобы преодолеть это ограничение, SQLAlchemy начиная с версии 2.0 реализует альтернативную форму «executemany», которая называется Поведение «Вставка многих значений» для операторов INSERT. Эта функция использует cursor.execute() для вызова оператора INSERT, который будет работать с несколькими наборами параметров за один цикл, таким образом, создавая тот же эффект, что и использование cursor.executemany(), но при этом поддерживая RETURNING.

См.также

Отправка нескольких параметров - учебное введение в «executemany»

Поведение «Вставка многих значений» для операторов INSERT - функция SQLAlchemy, позволяющая использовать RETURNING с «executemany»

истекает
истек срок действия
истекает
истекающий
Истекающий

В SQLAlchemy ORM означает, когда данные в объекте persistent или иногда detached стираются, так что при следующем обращении к атрибутам объекта будет выдан SQL-запрос lazy load, чтобы обновить данные для этого объекта, хранящиеся в текущей транзакции.

карта идентичности

Отображение между объектами Python и их идентификаторами в базе данных. Карта идентификации - это коллекция, связанная с объектом ORM Session, в которой хранится единственный экземпляр каждого объекта базы данных, ключ которого соответствует его идентификатору. Преимущество этого шаблона заключается в том, что все операции, выполняемые для определенного идентификатора базы данных, прозрачно координируются на одном экземпляре объекта. При использовании карты идентичности в сочетании с транзакцией isolated наличие ссылки на объект, который, как известно, имеет определенный первичный ключ, с практической точки зрения можно рассматривать как прокси к реальной строке базы данных.

См.также

Identity Map (via Martin Fowler)

Получение по первичному ключу - как искать объект в карте идентификации по первичному ключу

картезианское произведение

Если даны два множества A и B, то картезианское произведение - это множество всех упорядоченных пар (a, b), где a находится в A, а b - в B.

С точки зрения баз данных SQL, картезианское произведение возникает, когда мы выбираем из двух или более таблиц (или других подзапросов) без установления какого-либо критерия между строками одной таблицы и другой (прямо или косвенно). Если мы одновременно выбираем из таблицы A и таблицы B, мы получим каждую строку из A, сопоставленную с первой строкой из B, затем каждую строку из A, сопоставленную со второй строкой из B, и так далее, пока каждая строка из A не будет сопоставлена с каждой строкой из B.

Декартовы продукты вызывают генерацию огромных наборов результатов и могут легко вывести клиентское приложение из строя, если не принять меры.

картирование
отображено на карте
сопоставленный класс
Сопоставленный класс ORM

Мы говорим, что класс «сопоставлен», когда он был связан с экземпляром класса Mapper. Этот процесс связывает класс с таблицей базы данных или другой конструкцией selectable, так что его экземпляры могут быть сохранены и загружены с помощью Session.

каскад

Термин, используемый в SQLAlchemy для описания того, как действие ORM по сохранению, происходящее с определенным объектом, распространяется на другие объекты, которые непосредственно связаны с этим объектом. В SQLAlchemy эти ассоциации объектов настраиваются с помощью конструкции relationship(). relationship() содержит параметр relationship.cascade, который предоставляет варианты того, как определенные операции персистентности могут каскадироваться.

Термин «каскады», а также общая архитектура этой системы в SQLAlchemy были заимствованы, к лучшему или худшему, из Hibernate ORM.

См.также

Каскады

класс миксин
классы-миксины

Общий объектно-ориентированный шаблон, в котором класс, содержащий методы или атрибуты для использования другими классами, не обязательно должен быть родительским классом этих других классов.

См.также

Mixin (via Wikipedia)

ключ кандидата

Термин relational algebra, обозначающий атрибут или набор атрибутов, которые образуют уникальный идентифицирующий ключ для строки. Строка может иметь более одного ключа-кандидата, каждый из которых подходит для использования в качестве первичного ключа этой строки. Первичный ключ таблицы всегда является ключом-кандидатом.

консистенция

Согласованность является одним из компонентов модели ACID и гарантирует, что любая транзакция переведет базу данных из одного допустимого состояния в другое. Любые данные, записанные в базу данных, должны быть валидными в соответствии со всеми определенными правилами, включая, но не ограничиваясь constraints, каскады, триггеры и любые их комбинации. (через Википедию)

корреляции
коррелированный подзапрос
коррелированные подзапросы

Код subquery является коррелированным, если он зависит от данных в объемлющем SELECT.

Ниже подзапрос выбирает агрегированное значение MIN(a.id) из таблицы email_address таким образом, что он будет вызываться для каждого значения user_account.id, соотнося значение этого столбца со столбцом email_address.user_account_id:

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
 )

Приведенный выше подзапрос обращается к таблице user_account, которая сама не входит в предложение FROM этого вложенного запроса. Вместо этого таблица user_account получена из вложенного запроса, где каждая строка, выбранная из user_account, приводит к отдельному выполнению подзапроса.

Коррелированный подзапрос в большинстве случаев присутствует в WHERE clause или columns clause непосредственно заключающего оператора SELECT, а также в предложении ORDER BY или HAVING.

В менее распространенных случаях коррелированный подзапрос может присутствовать в FROM clause вложенного SELECT; в этих случаях корреляция обычно обусловлена тем, что вложенный SELECT сам вложен в предложение WHERE, ORDER BY, columns или HAVING другого SELECT, например:

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)

Корреляция от одного оператора SELECT непосредственно к другому, который включает коррелируемый запрос через свой пункт FROM, невозможна, потому что корреляция может быть продолжена только после того, как исходные строки источника из пункта FROM включающего оператора станут доступны.

курсор

Структура управления, которая позволяет обходить записи в базе данных. В Python DBAPI объект курсора фактически является отправной точкой для выполнения оператора, а также интерфейсом, используемым для получения результатов.

ленивая загрузка
ленивые нагрузки
ленивая загрузка
ленивая загрузка

В реляционном отображении объектов «ленивая загрузка» относится к атрибуту, который не содержит своего значения со стороны базы данных в течение некоторого периода времени, обычно при первой загрузке объекта. Вместо этого атрибут получает память, которая заставляет его обратиться к базе данных и загрузить свои данные при первом использовании. Используя этот шаблон, можно иногда уменьшить сложность и время, затрачиваемое на поиск объектов, поскольку атрибуты для связанных таблиц не требуют немедленного обращения.

Ленивая загрузка - это противоположность eager loading.

В SQLAlchemy ленивая загрузка является ключевой особенностью ORM и применяется к атрибутам, которые являются mapped на определенном пользователем классе. Когда происходит обращение к атрибутам, ссылающимся на столбцы базы данных или связанные объекты, для которых нет загруженного значения, ORM использует Session, с которым связан текущий объект в состоянии persistent, и выдает оператор SELECT в текущей транзакции, начиная новую транзакцию, если она не выполнялась. Если объект находится в состоянии detached и не ассоциирован ни с одним Session, это считается состоянием ошибки и выдается сообщение informative exception.

См.также

Lazy Load (via Martin Fowler)

N plus one problem

Варианты загрузки колонн - включает информацию о ленивой загрузке отображаемых столбцов ORM

Техники загрузки отношений - включает информацию о ленивой загрузке объектов, связанных с ORM

Предотвращение неявного ввода-вывода при использовании AsyncSession - советы по предотвращению ленивой загрузки при использовании расширения Асинхронный ввод/вывод (asyncio)

ленивая инициализация

Тактика задержки некоторых действий по инициализации, таких как создание объектов, заполнение данных или установление связи с другими службами, до тех пор, пока эти ресурсы не потребуются.

маршаллинг
сортировка данных

Процесс преобразования представления объекта в памяти в формат данных, подходящий для хранения или передачи в другую часть системы, когда данные должны быть перемещены между различными частями компьютерной программы или из одной программы в другую. С точки зрения SQLAlchemy, нам часто требуется «маршалинг» данных в формат, подходящий для передачи в реляционную базу данных.

См.также

Marshalling (via Wikipedia)

Дополнение существующих типов - TypeDecorator в SQLAlchemy обычно используется для маршалинга данных, когда данные отправляются в базу данных для операторов INSERT и UPDATE, и «размаршалинга» данных, когда они извлекаются с помощью операторов SELECT.

метаданные
метаданные базы данных
метаданные таблицы

Термин «метаданные» обычно относится к «данным, которые описывают данные»; данные, которые сами по себе представляют формат и/или структуру какого-либо другого вида данных. В SQLAlchemy термин «метаданные» обычно относится к конструкции MetaData, которая представляет собой набор информации о таблицах, столбцах, ограничениях и других DDL объектах, которые могут существовать в конкретной базе данных.

многие к одному

Стиль relationship(), который связывает иностранца

Связанные объекты, в свою очередь, будут иметь неявные или явные отношения one to many к любому количеству родительских объектов, которые ссылаются на них.

Примеров много для одной схемы (которая, заметим, идентична схеме one to many):

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)
)

Отношение от employee к department является отношением многие к одному, поскольку с одним отделом может быть связано много записей о сотрудниках. Сопоставление SQLAlchemy может выглядеть следующим образом:

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")

См.также

relationship

one to many

backref

многие ко многим

Стиль sqlalchemy.orm.relationship(), который связывает две таблицы вместе через промежуточную таблицу в середине. При такой конфигурации любое количество строк слева может ссылаться на любое количество строк справа, и наоборот.

Схема, в которой сотрудники могут быть связаны с проектами:

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)
)

Выше, таблица employee_project является таблицей «многие-ко-многим», которая естественным образом формирует составной первичный ключ, состоящий из первичного ключа каждой связанной таблицы.

В SQLAlchemy функция sqlalchemy.orm.relationship() может представлять этот стиль отношений в основном прозрачным образом, где таблица «многие-ко-многим» задается с помощью обычных метаданных таблицы:

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))

Выше определены коллекции Employee.projects и обратная ссылка Project.employees:

proj = Project(name="Client A")

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

proj.employees.extend([emp1, emp2])
модель домена

Модель домена в решении проблем и программной инженерии - это концептуальная модель всех тем, связанных с конкретной проблемой. Она описывает различные объекты, их атрибуты, роли и отношения, а также ограничения, которые регулируют проблемную область.

(через Википедию)

обратная ссылка
двунаправленные отношения

Расширение системы relationship, при котором два разных объекта relationship() могут быть взаимно связаны друг с другом, так что они координируются в памяти при изменениях, происходящих с каждой из сторон. Наиболее распространенным способом построения этих двух отношений является использование функции relationship() явно для одной стороны и указание ключевого слова backref для нее, так что другая relationship() создается автоматически. Мы можем проиллюстрировать это на примере, который мы использовали в one to many следующим образом:

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"))

Обратную ссылку можно применять к любым отношениям, включая отношения один ко многим, многие к одному и many to many.

ограничение
ограничения
ограниченный

Правила, установленные в реляционной базе данных, которые обеспечивают достоверность и согласованность данных. Общие формы ограничений включают primary key constraint, foreign key constraint и check constraint.

один ко многим

Стиль relationship(), который связывает первичный ключ таблицы родительского картографа с предыдущим.

Связанные объекты, в свою очередь, будут иметь неявное или явное отношение many to one к своему родительскому объекту.

Пример схемы один ко многим (которая, заметим, идентична схеме many to one):

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)
)

Отношение от department к employee - один ко многим, поскольку многие записи сотрудников могут быть связаны с одним отделом. Сопоставление SQLAlchemy может выглядеть следующим образом:

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"))

См.также

relationship

many to one

backref

отдельно стоящий

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; отсоединенный объект - это объект, который имеет идентификатор базы данных (т.е. первичный ключ), но не связан ни с какой сессией. Объект, который ранее был persistent и был удален из своей сессии либо потому, что он был удален, либо потому, что принадлежащая ему сессия была закрыта, переходит в состояние detached. Состояние detached обычно используется при перемещении объектов между сессиями или при перемещении в/из внешнего кэша объектов.

отношения
отношения

Соединительный блок между двумя сопоставленными классами, соответствующий некоторой связи между двумя таблицами в базе данных.

Отношение определяется с помощью функции SQLAlchemy relationship(). После создания SQLAlchemy проверяет аргументы и основные сопоставления, чтобы классифицировать отношение как один из трех типов: one to many, many to one или many to many. При такой классификации конструкция отношения выполняет задачу сохранения соответствующих связей в базе данных в ответ на ассоциации объектов в памяти, а также задачу загрузки ссылок на объекты и коллекций в память на основе текущих связей в базе данных.

отражение
отраженный

В SQLAlchemy этот термин относится к возможности запроса каталогов схем базы данных для загрузки информации о существующих таблицах, столбцах, ограничениях и других конструкциях. SQLAlchemy включает функции, которые могут как предоставлять исходные данные для этой информации, так и автоматически конструировать объекты Core/ORM, пригодные для использования Table, из каталогов схем баз данных.

См.также

Отражение объектов базы данных - полная информация об отражении баз данных.

Декларативное отображение с помощью отраженных таблиц - история интеграции отображений ORM с отраженными таблицами.

первичный ключ
ограничение первичного ключа

Ключ constraint, который однозначно определяет характеристики каждой строки в таблице. Первичный ключ должен состоять из характеристик, которые не могут быть продублированы ни в одной другой строке. Первичный ключ может состоять из одного атрибута или нескольких атрибутов в комбинации. (через Википедию)

Первичный ключ таблицы обычно, хотя и не всегда, определяется в пределах CREATE TABLE DDL:

CREATE TABLE employee (
     emp_id INTEGER,
     emp_name VARCHAR(30),
     dep_id INTEGER,
     PRIMARY KEY (emp_id)
)
переходный

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; переходный объект - это новый объект, который не имеет идентификатора базы данных и еще не был связан с сеансом. Когда объект добавляется к сессии, он переходит в состояние pending.

плагин
с поддержкой плагинов
специфический для плагинов

«plugin-enabled» или «plugin-specific» обычно указывает на функцию или метод в SQLAlchemy Core, который будет вести себя по-другому при использовании в контексте ORM.

SQLAlchemy позволяет конструкциям Core, таким как объекты Select, участвовать в системе «плагинов», которые могут внедрять в объект дополнительные поведения и возможности, не присутствующие по умолчанию.

В частности, основным «плагином» является плагин «orm», который лежит в основе системы, что SQLAlchemy ORM использует конструкции Core для составления и выполнения SQL-запросов, возвращающих результаты ORM.

повторяющееся чтение

Один из четырех уровней базы данных isolation, повторяемое чтение обладает всеми свойствами изоляции read committed, а также тем, что любой конкретный ряд, прочитанный в рамках транзакции, гарантированно не будет иметь никаких последующих внешних изменений значения (т.е. от других параллельных операторов UPDATE) в течение всей транзакции.

подзапрос
скалярный подзапрос

Относится к оператору SELECT, который встроен в объемлющий SELECT.

Подзапрос бывает двух видов: один известен как «скалярный select», который должен возвращать ровно одну строку и один столбец, а другой - как «производная таблица», служащая источником строк для пункта FROM другого select. Скалярный select может быть помещен в WHERE clause, columns clause, предложение ORDER BY или HAVING вложенного select, тогда как форма производной таблицы может быть помещена в предложение FROM вложенного SELECT.

Примеры:

  1. скалярный подзапрос, помещенный в columns clause вложенного SELECT. Подзапрос в этом примере является correlated subquery, потому что часть строк, из которых он выбирает, задана через вложенный оператор.

    SELECT id, (SELECT name FROM address WHERE address.user_id=user.id)
    FROM user
  2. скалярный подзапрос, помещенный в WHERE clause вложенного SELECT. Этот подзапрос в данном примере не является коррелированным, так как выбирает фиксированный результат.

    SELECT id, name FROM user
    WHERE status=(SELECT status_id FROM status_code WHERE code='C')
  3. подзапрос производной таблицы, помещенный в FROM clause вложенного SELECT. Такому подзапросу почти всегда присваивается псевдоним.

    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
полиморфный
полиморфно

Относится к функции, которая обрабатывает несколько типов одновременно. В SQLAlchemy этот термин обычно применяется к концепции сопоставленного класса ORM, когда операция запроса возвращает различные подклассы на основе информации в наборе результатов, обычно путем проверки значения определенного столбца в результате, известного как discriminator.

Полиморфная загрузка в SQLAlchemy подразумевает, что для отображения иерархии классов используется одна или комбинация трех различных схем: «объединенная», «одиночная» и «конкретная». Раздел Отображение иерархий наследования классов полностью описывает отображение наследования.

постоянный

Это описывает одно из основных состояний объекта, которое объект может иметь в Session; постоянный объект - это объект, который имеет идентификатор базы данных (т.е. первичный ключ) и в настоящее время связан с сеансом. Любой объект, который ранее был pending и теперь вставлен, находится в состоянии персистентности, как и любой объект, который был загружен сеансом из базы данных. Когда постоянный объект удаляется из сессии, он известен как detached.

приборостроение
инструментальный
инструментарий

Инструментарий - это процесс расширения функциональности и набора атрибутов определенного класса. В идеале, поведение класса должно оставаться близким к обычному классу, за исключением того, что становятся доступными дополнительные поведения и возможности. Процесс SQLAlchemy mapping, помимо прочего, добавляет в сопоставленный класс descriptors с поддержкой базы данных, каждый из которых представляет определенный столбец базы данных или связь с родственным классом.

прилагается

Указывает на объект ORM, который в настоящее время связан с конкретным Session.

проверка ограничений

Контрольное ограничение - это условие, определяющее допустимые данные при добавлении или обновлении записи в таблице реляционной базы данных. Контрольное ограничение применяется к каждой строке таблицы.

(через Википедию)

Контрольное ограничение может быть добавлено к таблице в стандартном SQL с помощью DDL, как показано ниже:

ALTER TABLE distributors ADD CONSTRAINT zipchk CHECK (char_length(zipcode) = 5);
реестр

Объект, обычно глобально доступный, который содержит долгоживущую информацию о некотором состоянии программы, которая обычно полезна для многих частей программы.

реляционный
реляционная алгебра

Алгебраическая система, разработанная Эдгаром Ф. Коддом, которая используется для моделирования и запроса данных, хранящихся в реляционных базах данных.

связанный параметр
связанные параметры
параметр привязки
параметры привязки

Связанные параметры являются основным средством передачи данных драйверу базы данных DBAPI. Хотя вызываемая операция основывается на строке оператора SQL, сами значения данных передаются отдельно, где драйвер содержит логику, которая безопасно обрабатывает эти строки и передает их на внутренний сервер базы данных, что может включать либо форматирование параметров в саму строку SQL, либо передачу их в базу данных с помощью отдельных протоколов.

Конкретная система, с помощью которой драйвер базы данных делает это, не должна иметь значения для вызывающей стороны; суть в том, что со стороны данные всегда должны передаваться отдельно, а не как часть самой строки SQL. Это необходимо как для обеспечения адекватной защиты от SQL-инъекций, так и для обеспечения наилучшей производительности драйвера.

сентинел
вставить часового

Это специфический термин SQLAlchemy, который относится к Column, который может быть использован для массовой операции insertmanyvalues для отслеживания записей INSERT данных против строк, переданных обратно с помощью RETURNING или аналогичных. Такая конфигурация столбцов необходима для тех случаев, когда функция insertmanyvalues выполняет оптимизированный оператор INSERT…RETURNING для многих строк одновременно и при этом может гарантировать соответствие порядка возвращаемых строк входным данным.

В типичных случаях компилятор SQLAlchemy SQL может автоматически использовать суррогатные целочисленные столбцы первичного ключа в качестве «отправителей вставки», и пользовательская настройка не требуется. Для менее распространенных случаев с другими разновидностями генерируемых сервером значений первичного ключа, явные столбцы «insert sentinel» могут быть дополнительно настроены в table metadata для оптимизации операторов INSERT, которые вставляют много строк одновременно.

сериализуемый

Один из четырех уровней базы данных isolation, сериализуемый, обладает всеми свойствами изоляции repeatable read, и дополнительно в рамках подхода, основанного на блокировке, гарантирует, что так называемое «фантомное чтение» не может произойти; это означает, что строки, которые INSERTed или DELETEd в рамках других транзакций, не будут обнаружены в данной транзакции. Строка, прочитанная в рамках данной транзакции, гарантированно продолжает существовать, а несуществующая строка гарантированно не может появиться при вставке из другой транзакции.

Сериализуемая изоляция обычно опирается на блокировку строк или диапазонов строк для достижения этого эффекта, что может увеличить вероятность возникновения тупиковых ситуаций и снизить производительность. Существуют также схемы, не основанные на блокировке, однако они обязательно предполагают отказ от транзакций при обнаружении коллизий записи.

Сессия

Контейнер или область действия для операций с базой данных ORM. Сессии загружают экземпляры из базы данных, отслеживают изменения в сопоставленных экземплярах и сохраняют изменения в единой единице работы при сбросе.

составной первичный ключ

Строка primary key, имеющая более одного столбца. Конкретная строка базы данных уникальна на основе двух или более столбцов, а не только одного значения.

См.также

primary key

стиль 1.x
стиль 2.0
1.x-стиль
2.0-стиль

Эти термины являются новыми в SQLAlchemy 1.4 и относятся к плану перехода SQLAlchemy 1.4 -> 2.0, описанному в SQLAlchemy 2.0 - руководство по миграции. Термин «стиль 1.x» относится к API, используемому в том виде, в котором он был документирован в SQLAlchemy серии 1.x и более ранних версиях (например, 1.3, 1.2 и т.д.), а термин «стиль 2.0» относится к тому, как API будет выглядеть в версии 2.0. Версия 1.4 реализует почти все API версии 2.0 в так называемом «переходном режиме», в то время как версия 2.0 все еще поддерживает унаследованный объект Query, чтобы позволить унаследованному коду оставаться в значительной степени совместимым с 2.0.

столбец id версии

В SQLAlchemy это относится к использованию определенного столбца таблицы, который отслеживает «версию» конкретной строки, поскольку строка меняет значения. Хотя существуют различные виды реляционных моделей, которые по-разному используют «столбец с идентификатором версии», ORM SQLAlchemy включает в себя определенную функцию, которая позволяет настроить такой столбец в качестве средства проверки устаревших данных, когда строка обновляется новой информацией. Если последняя известная «версия» этого столбца не совпадает с версией строки, когда мы пытаемся поместить в нее новые данные, мы знаем, что действуем на устаревшей информации.

Существуют и другие способы хранения «версионных» строк в базе данных, часто называемые «временными» данными. В дополнение к возможности версионирования в SQLAlchemy, в документации есть еще несколько примеров, см. ссылки ниже.

См.также

Настройка счетчика версий - встроенная в SQLAlchemy функция идентификации версии.

Версионирование объектов - другие примеры отображений, которые временно версифицируют строки.

удалено

Это описывает одно из основных состояний объекта, которое объект может иметь в пределах Session; удаленный объект - это объект, который ранее был постоянным и имел оператор DELETE, отправленный в базу данных в рамках flush для удаления его строки. Объект перейдет в состояние detached после фиксации транзакции сессии; в противном случае, если транзакция сессии будет откатана, DELETE будет отменен и объект вернется в состояние persistent.

уникальное ограничение
уникальный ключевой индекс

Уникальный ключевой индекс может однозначно идентифицировать каждую строку значений данных в таблице базы данных. Уникальный ключевой индекс включает в себя один столбец или набор столбцов в одной таблице базы данных. Никакие две разные строки или записи данных в таблице базы данных не могут иметь одинаковое значение данных (или комбинацию значений данных) в столбцах уникального ключевого индекса, если не используются значения NULL. В зависимости от своей конструкции

(через Википедию)

См.также

Unique key (via Wikipedia)

условие ГДЕ

Часть оператора SELECT, которая указывает критерии, по которым следует фильтровать строки. Это одно выражение SQL, которое следует за ключевым словом WHERE.

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

Выше, фраза WHERE user_account.name = 'fred' AND user_account.status = 'E' включает в себя пункт WHERE предложения SELECT.

условие о столбцах

Часть оператора SELECT, в которой перечисляются выражения SQL, возвращаемые в набор результатов. Выражения следуют непосредственно за ключевым словом SELECT и представляют собой список отдельных выражений, разделенных запятыми.

Например:

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

Выше список столбцов user_acount.name, user_account.email является пунктом столбцов в SELECT.

фасад

Объект, который служит в качестве лицевого интерфейса, маскирующего более сложный базовый или структурный код.

цепочка методов
генеративный

«Цепочка методов», называемая в документации SQLAlchemy «генеративной», - это объектно-ориентированная техника, при которой состояние объекта создается путем вызова методов объекта. Объект имеет любое количество методов, каждый из которых возвращает новый объект (или, в некоторых случаях, тот же объект) с дополнительным состоянием, добавленным к объекту.

Два объекта SQLAlchemy, которые наиболее часто используют цепочку методов, - это объект Select и объект Query. Например, объект Select может быть назначен

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

Каждый вызов метода выше возвращает копию исходного объекта Select с добавленными дополнительными классификаторами.

цикломатическая сложность

Мера сложности кода, основанная на количестве возможных путей через исходный код программы.

См.также

Cyclomatic Complexity

читать без фиксации

Один из четырех уровней базы данных isolation, read uncommitted означает, что изменения, внесенные в данные базы данных в рамках транзакции, не станут постоянными до тех пор, пока транзакция не будет зафиксирована. Однако в рамках read uncommitted возможно, что данные, не зафиксированные в других транзакциях, могут быть доступны для просмотра в рамках другой транзакции; такие случаи известны как «грязное чтение».

читать с полной отдачей

Один из четырех уровней базы данных isolation, read committed характеризуется тем, что транзакция не будет подвергаться воздействию данных из других параллельных транзакций, которые еще не были зафиксированы, предотвращая так называемое «грязное чтение». Однако при read committed возможны неповторяющиеся чтения, то есть данные в строке могут измениться при повторном чтении, если другая транзакция зафиксировала изменения.

Вернуться на верх