В этой статье мы рассмотрим как в PostgreSQL реализованы уровни изоляции транзакций , какие аномалии допускаются при разных уровнях изоляции , а какие нет. 

Транзакции - это фундаментальное понятие во всех СУБД. Суть транзакции в том, что она объединяет последовательность действий в одну операцию по принципу «всё или ничего».

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

Стандарт SQL определяет четыре уровня изоляции транзакций:

SQLAlchemy - это инструментарий базы данных(database toolkit) для Python. Он предоставляет все возможности которые нам нужны при работе с реляционными базами данных , но при этом весь код будет написан на Python. Не нужно писать голые запросы специфичные для каждой реляционной базы данных и при этом задумываться об экранировании и об других важных вещах. Вместо этого SQLAlchemy позволяет абстрагироваться от используемой базы данных. Написанный код на Pyhon будет работать прекрасно работать с разными БД(Postgresql, MySql, Sqlite). Если вы на старте проекта используете одну БД , но вам нужно переключиться на другую, то вы можете это сделать безболезненно и с минимальными усилиями.

SQLAlchemy состоит из двух отдельных компонентов, известных как Core и ORM. И при этом ORM(Object Relational Mapper) реализован поверх ядра(Core). 

psql - это интерактивная программа , которая позволяет взаимодействовать с сервером базы данных. В этой программе мы можем выполнять операторы SQL и выполнять команды предоставляемые этой программой для изменения объектов баз данных. 
Вот некоторые основные команды psql (клиент PostgreSQL) с их описанием и примерами

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

В предыдущей статье , мы реализовали каталог товаров с переменным набором свойств используя паттерн проектирования EAV(Entity-Value-Product).Но для реализации данной задачи нам пришлось добавить несколько таблиц , но и это не позволило нам решить полностью проблему , так как значения могут быть разного типа. Достаточно , посмотреть на структуру таблиц в популярном интернет-движке Magento, который реализует паттерн EAV. Но за это приходиться дорого платить , когда мы делаем запросы на фильтрацию и выборку данных,так как нам приходиться писать запросы с объединением таблиц.