В языке PL/pgSQL нет ассоциативных массивов, которые позволяют получить значение по ключу. И это досадно. Но ладно.
Первый способ имитировать ассоциативный массив
Создайте два массива, упорядоченных по одному и тому же критерию. Первый из них должен содержать ключи, второй - значения. После этого для получения значения по ключу нужно
10 лет назад я написал первый пост в мой блог – про установку Oracle XE 11gR2 на Windows. Сколько воды утекло...
В 2022 комания Oracle удалила мой аккаунт, которым я пользовался лет двадцать, после того как Россия попала под экспортные ограничения. (Как в том анекдоте, где опытный кадровик помогает молодому коллеге справиться к горой резюме от кандидатов, которые тому нужно просмотреть. Половину резюме – сразу в мусорную корзину со словами "Лузеры нам не нужны!") Но жизнь продолжается.
Когда-то я уже писал о "многоликом NULL", см. Часть I и Часть II. Сегодняшний пост в дополнение и в развитие этой темы.
Я неоднократно встречал утверждение, что NULL в SQL нужно понимать как "неизвестно что". С этим согласуется поведение операторов сравнения при сравнении двух NULL (команды выполнены в PostgreSQL 15):
select 1
where null = null
or null != null
or null < null
or null <= null
or null >= null
or null > null
;
no rows
Написанные на Python, утилиты dbang позволяют существенно сэкономить усилия при решении типичных задач, связанных с БД:
ddiff.py - выполняет запросы к двум БД и формирует отчет о расхождениях;dtest.py - выполняет запросы к БД и формирует отчет о найденных проблемах;dget.py - выгружает данные из БД в файлы csv, xlsx или html;dput.py - загружает данные из файлов csv или xlsx в таблицы БД;hedwig.py - на основе файлов создает и отправляет е-мейл.Утилиты могут работать с СУБД Oracle, PostgreSQL, SQLite и MySQL.
Ранее я описал механизм delta для регистрации изменений в таблицах БД Oracle, позволяющий обрабатывать изменения независимо нескольким клиентам.
Долгое время все решения на базе механизма delta делались для базовых таблиц с неизменными первичными ключами.
Исходить из неизменности значений первичного ключа во многих случаях оправданно, но, как всегда, жизнь оказывается богаче, и в серьезных системах встречаются случаи, когда первичный ключ изменяется. Иногда изменяется только часть составного первичного ключа. Иногда изменяется значение первичного ключа из одного столбца, например, в ходе исправления ошибки ввода.
Попробуем разобраться, как же корректно обрабатывать изменения первичного ключа базовой таблицы, используя механизм delta.
Ранее я описал механизм delta для регистрации изменений в таблицах БД Oracle, позволяющий обрабатывать изменения независимо нескольким клиентам.
Работа описанного механизма опирается на таблицу изменений с rowdependencies. Что делает его зависимым от СУБД Oracle. А в один прекрасный день возникает желание использовать хорошо зарекомендовавший себя механизм в СУБД PostgreSQL или другой СУБД с триггерами.
Можно ли использовать более универсальный подход при реализации таблицы изменений вместо таблицы с rowdependencies?
Если значение первичного ключа изменяется не при выполнении специальных административных процедур, а в ходе обычной эксплуатации системы, то это выглядит как ошибка проектирования системы. Однако, иногда приходится иметь дело с такими системами.
Вопрос об изменении значения первичного ключа может также возникнуть в контексте интеграции систем.
Например, система А посылает в шину данных сообщения об изменениях бизнес-сущности Товар. И в этих сообщениях каждый отдельный экземпляр сущности – индивидуальный товар – идентифицируется бизнес-ключом, значение которого может быть изменено пользователем системы А (см. мой пост Кейс: изменение значения бизнес-ключа). А в системе Б, которая получает сообщения из шины данных и на их основании актуализирует собственную копию бизнес-сущности Товар, бизнес-ключ является первичным ключом таблицы в БД. И на него ссылаются внешние ключи из других таблиц.
Сможет ли система Б обновить первичный ключ, если она получит сообщение об изменении бизнес-ключа?
Возьмем некоторую сущность модели данных, экземпляры которой идентифицируются бизнес-ключом. Бизнес-ключ - это код или номер, который известен конечным пользоватлям системы (представлен в пользовательском интерфейсе) и используется в коммуникациях. Например, артикул товара, код подразделения компании, табельный номер сотрудника. Когда один сотрудник передает другому список товаров, он передает список артикулов. Когда подразделение компании заводит заявку на обслуживание, оно указывает код подразделения; этот же код подразделения фигурирует в копроративных отчетах.
Бизнес-ключ, как правило, имеется у справочников (страны, типы заказа, ...), ресурсных сущностей (товар, поставщик, ...) и операционных сущностей (заказ, промо-акция, ...). Другие сущности (конфигурации, бизнес-транзакции) используют внешние бизнес-ключи как часть собственного уникального ключа.
Бывает, что бизнес-ключ изменяется пользователем.