🔎 Сложная задача с собеса в компанию UNLIMIT
(Я её не решил в моменте т.е. как не решил, я предложил вариант, но он ресурсный и потому неподходящий.)
Задача на уровень Senior, а может быть Expert.

💡 Условие:

У нас — высоконагруженная база ORACLE:
📈 до 1000 и выше транзакций в секунду.
Часть из них — commit, часть — rollback.

Нужно:
📆 Назначать каждой транзакции уникальный порядковый номер в пределах суток (часа, минуты)
При этом:

🔁 Номера должны идти без пропусков и дублей.

📌 Сохраняем их в таблице transactions.

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

⚡ Назначение номера должно происходить быстро.

📊 Пример:

Дата Номер транзакции
01.01.2025 1
01.01.2025 2
... ...
01.01.2025 1000009
02.01.2025 1
02.01.2025 2
... ...

🤔 Как бы вы реализовали такой счётчик?
С условиями:

Без блокировок

Без пробелов

Быстро

И чтобы не сносило систему под нагрузкой

Пишите ваши идеи 👇

🔄 UPDATE 02.02.2025:

Спасибо, что с нами есть Иван Петрович.

📌 В PostgreSQL такое провернуть невозможно.
Дело в том, что PostgreSQL при попытке вставки уникального значения блокирует строку (если используется, например, SELECT ... FOR UPDATE, INSERT ... ON CONFLICT, уникальные индексы и т. д.).
Сессии, которые вставляют те же значения одновременно, вынуждены ждать — из-за row-level locks.

🔄 UPDATE 23.09.2025:

Спасибо, что с нами есть Евгений Артурович.

💡 В Oracle поведение аналогичное - при вставке двух новых значений в уникальный индекс ошибка проявляется в момент коммита. Поэтому для избежание конкуренции назначения номера должно быть в автономной транзакции.

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

#RealInterviewTasks #Oracle #PL/SQL

💡 Разбор «невозможной» задачи про сквозной счётчик-без-пробелов

🔑 Главные наблюдения
INSERT — самая быстрая DML-операция; читаем как можно меньше.

FAST FULL INDEX SCAN даёт O(1) чтение «хвоста» уникального индекса.

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

🛠 Алгоритм
Шаг Действие Почему это безопасно
1 Читаем последний номер через SELECT … ORDER BY num DESC FETCH 1
(FAST FULL INDEX SCAN) Один блочный I/O, без блокировок
2 INSERT INTO period_tx_idx(period, num) VALUES(:p, :last_num) Дешевле, чем update
3 Если вставка успешна → номер наш ✅ Уникальный индекс не дал коллизии
4 Если ORA-00001 / unique constraint → кто-то уже взял этот num → num := num + 1 и GO TO 2 Перебираем до победы — обычно 1-2 попытки

🔸 На практике при 1 000 TPS конкурируют считанные сессии → конфликт мизерный.
🔸 «Дырки» возможны только при аварийном выключении питания в момент вставки, и то чисто теоретически.

❗️ Практический совет
Такой счетчик надо организовывать после всей логики и всех проверок, все констрейны на уровне таблицы тоже должны быть дополнительно проверены, чтобы избежать неожиданного EXCEPTION.

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

#RealInterviewTasks #Oracle #PL/SQL

Скрипт для проверки. Можно запустить в разных сессиях и посмотреть.
UPDATE 23.09.2025 Указанный скрипт неточный.
Исправленный скрипт в комментариях.

🎵 "Вы хотите песен? Их есть у меня."
— С. Шнуров

Сегодня — не песня, а задачка на размышление (из собеса с одной иностранной компанией). На первый взгляд — идентичные конструкции, но за ними скрыта важная разница.

Сравните два варианта:
a)

SELECT *
FROM   table1 t1
WHERE  (SELECT t2.column2 
        FROM   table2 t2 
        WHERE  t2.id = t1.id) = t1.column1;

b)

CREATE OR REPLACE FUNCTION f1(id NUMBER) RETURN VARCHAR2 IS
  x table2.column2%TYPE;
BEGIN
  SELECT t.column2
  INTO   x
  FROM   table2 t
  WHERE  t.id = f1.id;

  RETURN x;
END f1;
/

SELECT *
FROM   table1 t1
WHERE  f1(t1.id) = t1.column1;

📌 Вопрос:
В чём концептуальная разница между этими двумя подходами?
Ясно, что написано криво, но это специально.

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

Обсудим в комментариях 👇
(а позже добавлю разбор)
#RealInterviewTasks #sql #Oracle #PostgreSQL #PL/SQL #PL/pgSQL

"Пусть я переору любого соловья..."
— Шнур

Недавний случай из практики.

Java-разработчики обращаются к БД, как умеют — через IN (...) :

<select id="select" resultType="Long">
  SELECT order_id
  FROM table_1
  WHERE order_id IN
  <foreach item="orderId" collection="orderIds" separator="," open="(" close=")">
    #{orderId}
  </foreach>
</select>

На выходе в логах базы — десятки разных SQL-запросов:

SELECT order_id FROM table_1 WHERE order_id IN (:1)
SELECT order_id FROM table_1 WHERE order_id IN (:1, :2, :3)
...
SELECT order_id FROM table_1 WHERE order_id IN (:1, ..., :999)

Вроде всё работает. Но вот вопрос:

❓ Корректно ли так обращаться к базе?
Если нет — почему, и как бы вы это исправили?

💬 Делитесь опытом и решениями — интересно, кто как решает такие "мелочи", которые под нагрузкой превращаются в проблему.

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

#Cases #sql #Oracle #PostgreSQL #PL/SQL #PL/pgSQL

Разбор задачи: В чём разница между SQL-запросом и вызовом PL/SQL-функции?
(К задаче из предыдущего поста)

💡 На первый взгляд оба варианта делают одно и то же — сравнивают значение из table1 с соответствующим значением из table2. Но давайте разберёмся, в чём концептуальная разница между двумя подходами.

📌 Вариант A — скалярный подзапрос

SELECT *
FROM   table1 t1
WHERE  (SELECT t2.column2 
        FROM   table2 t2 
        WHERE  t2.id = t1.id) = t1.column1;

Что происходит:
Это обычный SQL-запрос с коррелированным подзапросом.
Для каждой строки t1 выполняется подзапрос к table2.
Оптимизатор БД может применить merge join, hash join, nested loops или даже вынести подзапрос в джойн — всё зависит от статистики, индексов и плана выполнения.

Плюсы:
Оптимизируемо.
Может быть трансформировано оптимизатором.
Прозрачно для анализа выполнения.

📌 Вариант B — вызов пользовательской функции

CREATE OR REPLACE FUNCTION f1(id NUMBER) RETURN VARCHAR2 IS
  x table2.column2%TYPE;
BEGIN
  SELECT t.column2
  INTO   x
  FROM   table2 t
  WHERE  t.id = f1.id;

  RETURN x;
END f1;
/
SELECT *
FROM   table1 t1
WHERE  f1(t1.id) = t1.column1;

Что происходит:

На каждую строку table1 вызывается функция f1.
Внутри функции выполняется SQL-запрос к table2.

Ключевое отличие:

🔐Оптимизатор не может "заглянуть" внутрь PL/SQL-функции.
Запрос к table2 не участвует в планировании — он "чёрный ящик".
Это приводит к контекстным переключениям (SQL ⇄ PL/SQL), что негативно влияет на производительность.
Невозможно применить стандартные оптимизации (например, замену на JOIN).

🔐 Ещё одно ключевое отличие — влияние уровня изоляции
На практике результат запроса A и запроса B может отличаться, даже если они запущены одновременно в разных сессиях.

Почему?

📌 По умолчанию в Oracle используется уровень изоляции READ COMMITTED.
Это означает, что:

В варианте A (чистый SQL) вся выборка выполняется как единое целое — данные читаются в рамках одного "снимка" данных на момент начала запроса.

А вот во втором варианте с функцией — каждое обращение к table2 происходит внутри отдельного запроса, в момент вызова функции.

👉 Итог:
Функция будет видеть уже изменённые данные, если они модифицированы между строками основного SQL.
Даже если изменения происходят прямо в момент выполнения запроса — это легально на READ COMMITTED.

🔄 Пример:
Вы запускаете SELECT ... WHERE f1(t1.id) = t1.column1.

В это время другая сессия меняет table2.

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

🛡 Как избежать этого?
Чтобы зафиксировать момент чтения — можно использовать уровень изоляции SERIALIZABLE.

Однако:

Это не гарантирует успех — Oracle выдаст ошибку (ORA-08177: can't serialize access for this transaction), если во время выполнения будут обнаружены конфликтующие изменения.

Даже если изменён блок, в котором хранятся нужные строки (даже если сами строки не изменились), Oracle вернет ошибку.

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

#RealInterviewTasks #sql #Oracle #PostgreSQL #PL/SQL #PL/pgSQL

🛠 Разбор кейса: IN (...), 999 параметров и производительность

Продолжение истории про Java-разработчиков и их любимый IN (...).

На первый взгляд — всё логично: список orderIds, XML-мэппер MyBatis, всё красиво раскладывается в IN (:1, ..., :N).
Но в реальности — десятки SQL-запросов с разным количеством параметров. И каждый — новый hard parse
(hard parse - это режим, когда оптимизатор определяет план запроса. soft parse, когда оптимизатор берет готовый план из Кэша).

📉 Что это означает:

Нет повторного использования плана выполнения (cursor sharing не спасает).
Под нагрузкой — рост CPU и latch contention.
Объём shared pool растёт, plan cache фрагментируется.

❌ Почему это не ок:
Oracle не объединяет запросы с разным числом параметров.
При высоком QPS — постоянная генерация новых кусков кода (library cache misses).
Особенно тяжело в RAC — загружаются interconnect и global cache.

✅ Что с этим делать?
Передавай список ID через TABLE(...) или временную таблицу (если элементов коллекций более 10000):

SELECT order_id
FROM table_1
WHERE order_id IN (SELECT column_value FROM TABLE(:order_id_array))

👨‍💻 Ну и это ещё не всё.
Такие решения, как выше, часто используются вынужденно — особенно у full-stack и прикладных разработчиков, где БД рассматривается как «глупое хранилище».

Но если хотите, чтобы проект не развалился под нагрузкой — не обращайтесь к БД напрямую через таблицы и вьюхи.
Даже самые простые INSERT, UPDATE, DELETE, SELECT стоит заворачивать в API на стороне БД — процедуры, функции, пакеты.

❌ Не хотите переносить бизнес-логику в БД — не надо.
✅ Но обращайтесь через API, а не напрямую.

📉 Пока строк в таблице — тысячи, «как-то работает».
📉 На миллионах — начинает тормозить.
🔥 А на сотнях миллионов — всё гарантированно подвиснет, и не спасут никакие индексы, если запросов с клиентской стороны будет хаос.

📦 Зачем нужен API к базе:
✅ Код становится читаемым, стабильным и управляемым

✅ Пакеты и процедуры компилируются заранее → экономия CPU

✅ Внутри можно скрыть служебную механику: логирование, модификацию тех.полей, аудит, статистику

✅ Можно свободно переносить таблицы между схемами — интерфейс не меняется

✅ Упрощается миграция на новые модели хранения

✅ Можно централизованно обрабатывать ошибки, транзакции, валидации

✅ И ещё с десяток других плюсов

🧩 Итог:
Решения «в лоб» — работают, пока не стало больно.

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

#Cases

😌 Суббота, шабат, всё спокойно — разбираем лёгкую задачку.
Просто один странный запрос.

💡 Найдите, что не так с этим SQL-запросом

📦 У нас есть две таблицы:

CREATE TABLE table1 (id NUMBER NOT NULL, name VARCHAR2(100));
CREATE TABLE table2 (id NUMBER NOT NULL, address VARCHAR2(100));

🧩 И такой PL/SQL-блок:

DECLARE
  a NUMBER;
  b VARCHAR2(10);
BEGIN
  SELECT id, address
  INTO   a, b
  FROM   table1 t1 LEFT OUTER JOIN table2 t2 ON t1.id = t2.id
  WHERE  t2.address LIKE '%India%'
  GROUP BY t1.name, t2.address, t1.id
  HAVING MIN(t1.id) = MAX(t2.id);
END;

🔍 Задача:
В этом коде есть несколько ошибок и странных решений — как логических, так и синтаксических.

Я насчитал 6 неточностей и ошибок. Может быть есть больше?

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

❓Что здесь не так?
Напишите в комментариях, что бы вы исправили или переписали.

👇 Разбор выложу позже.
#RealInterviewTasks #sql #Oracle #PostgreSQL #PL/SQL #PL/pgSQL

🤔 Как вы сравниваете два значения в Oracle, если оба могут быть NULL?

Ситуация простая:

col1 = col2

Но оба поля могут быть NULL, и тогда сравнение возвращает FALSE.

Да, можно:
NVL(col1, 0) = NVL(col2, 0)
COALESCE(col1, -1) = COALESCE(col2, -1)
DECODE(col1, col2, 1, 0) = 1
col1 = col2 OR (col1 IS NULL AND col2 IS NULL)

Но все эти методы требуют "заглушек" или слишком громоздки.

🔍 А что используете вы в таких случаях? Есть ли у вас удобная и универсальная конструкция для сравнения "NULL-aware"?

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

#RealInterviewTasks #sql #Oracle #PL/SQL

Все варианты валидны.
⚠️ (В случае если вы уверены, что значения заглушек в таблице нет
и никогда не будет).
Но предлагаю рассмотреть ещё одну системную функцию,
которую Oracle использует сам внутри.

Она заменяет NULL на специальное внутреннее значение, чтобы можно было безопасно сравнивать:

SYS_OP_MAP_NONNULL(col1) = SYS_OP_MAP_NONNULL(col2)

Таким образом NULL = NULL будет возвращать TRUE, но без искажения логики (в отличие от NVL(col, 0)).

⚠️ Функция не документирована, но активно используется в системных операциях. Работает для разных типов и не требует подстановки "заглушек".

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

#RealInterviewTasks #sql #Oracle #PL/SQL

💡 Случай из практики.

Представим, что в проекте есть таблица table_1 с большим числом полей — 50, а то и 100.
Прикладные системы присылают данные в виде XML или JSON. На первом этапе мы их парсим, а затем вызываем метод, который должен обновить или вставить запись в таблицу.

Но есть нюанс:
🔹 один приклад может менять только 3–4 поля,
🔹 другой — 20–30,
🔹 третий вообще только одно.

Как быть?
Передавать 100 параметров в метод?
Писать 10 версий под каждый приклад?
Или, может, есть способ обойтись одним универсальным механизмом, который будет обновлять только то, что реально пришло?

🧩 Как бы вы это реализовали?

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

Пишите свои подходы — обсудим в комментариях или в следующем посте 😉
#CodeArchitecture

✨ Универсальный метод обновления: магия значений-заглушек ✨
Привет, друзья! 👋

В прошлом посте мы говорили о сложной задаче:
в таблице с 50–100 полями каждый вызов обновляет разное количество данных. Сегодня расскажу, как с этим можно справиться с помощью одного хитрого приёма — значений-заглушек (sentinel values).

Это — простой и рабочий способ, но есть и свои подводные камни. 🚧

🔍 Как это работает?
1️⃣ Для каждого типа данных выбираем уникальное «магическое» значение, которого точно не будет в реальных данных:

Числа — 2147483647 (максимум для 32-битного int)

Даты — 01.01.0101 (ну кто такое хранит?)

Строки — символ CHR(0) (невидимый и неиспользуемый)

2️⃣ В процедуре обновления ставим эти значения по умолчанию.

3️⃣ Когда приходит запрос, обновляем только те поля, где значение отлично от заглушки. Остальные — оставляем как есть.

⚖️ Плюсы и минусы
✔️ Гибко: обновляем ровно то, что нужно
✔️ Универсально: один метод на все случаи
✔️ Без дублирования кода

❌ Длинная сигнатура: 50–100 параметров — тяжело читать и писать
❌ Риск коллизий: кто-то вдруг захочет использовать заглушку в данных
❌ Неочевидно: новичку сложно понять логику по умолчанию

🚀 Есть идеи получше?
Обо всём этом — в следующем посте! 😉

🧩 А как вы бы сделали?
Пишите свои мысли и опыт в комментариях!
Будем разбираться вместе 🔥
#CodeArchitecture

Скрипт для проверки

💡 Простой вопрос из собесов по SQL и индексам
(про план запросов, но с подвохом)

У нас есть таблица:

CREATE TABLE employees (
  fio            VARCHAR2(50) NOT NULL,
  department_id  NUMBER       NOT NULL,
  start_date     DATE         NOT NULL
);

CREATE INDEX employees_i01 ON employees (fio, department_id);

И вот такой запрос:

SELECT fio
FROM   employees
WHERE  fio = :f AND department_id = :dep_id;

На него отлично работает индекс employees_i01, ведь все условия входят в ключ.

Теперь добавим новый фильтр:

SELECT fio
FROM   employees
WHERE  fio = :f AND department_id = :dep_id AND start_date >= :d;

❓ Как изменится производительность запроса?
1️⃣ Станет быстрее
2️⃣ Станет медленнее
3️⃣ Ничего не изменится

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

🤔 А как думаете вы?
📥 Пишите свои варианты и размышления в комментарии — обсудим!
#RealInterviewTasks

✍️ Ответ на вопрос по индексам:

Запрос:

SELECT fio
FROM employees
WHERE fio = :f AND department_id = :dep_id;
🔍 Отлично использует индекс employees_i01 (fio, department_id) — оба условия входят в его ключ, возможен index range scan с минимальным I/O.

Теперь добавляем:

AND start_date >= :d

💥 И тут может случиться подвох.

🧠 Что изменится? Индекс остался тем же, но появился дополнительный фильтр, не входящий в индекс. Oracle больше не сможет полностью удовлетворить запрос только по индексу — ему нужно будет идти в таблицу (table access by rowid), чтобы проверить start_date.

📉 Это добавляет дополнительный шаг (filter) и может замедлить выполнение. Особенно на больших таблицах с большим количество полей.

📌 Ответ: 2️⃣ Станет медленнее.

💎 Поддержка канала⁉️
#RealInterviewTasks

Анализируйте, пользуйтесь, ёшкин кот!!!👋

В прошлом посте мы разбирали, как обновлять разные наборы полей в одной процедуре с помощью значений-заглушек.
Это рабочий, но не идеальный метод.
Но прежний метод колхоз, по сравнению с текущим методом.
Универсального механизм на базе ключ-значение!

⚠️ Метод сложный, но он Вас обогатит во всех смыслах.
Много чему научитесь!

✨ Как это работает?

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

Тип-вариант (t_variant): Мы создаем объект, который умеет хранить числа, строки, даты и другие типы данных. Внутри него — разные поля, но за раз используется только одно.

Ассоциативный массив: Мы определяем константы (например, number_field= 1, varchar2_field = 5) для каждого поля в таблице. Затем создаем коллекцию или ассоциативный массив, где ключ — это номер поля, а значение — наш t_variant.

Универсальный метод (set_attribute): В процедуре мы просто добавляем в этот массив только те поля, которые нужно обновить.

Применение изменений (apply_changes): Отдельная процедура получает этот массив и обновляет только те столбцы, которые в нём есть.

🚀 Плюсы этого подхода:

Чистый код: Сигнатура процедуры обновления становится очень короткой — она принимает всего одну структуру!
Гибкость: Можно легко добавлять новые поля, не меняя сигнатуру процедуры.
Безопасно: Мы не используем "магические" значения, которые могут совпасть с реальными данными.

🚧 Минусы, конечно, тоже есть:

Сложность: Создание и поддержка кастомных типов (t_variant, коллекций) требует больше усилий.
Производительность: Работа с объектами и коллекциями может быть медленнее, чем простой UPDATE с CASE операторами.
Неочевидно: Для новичка это решение может показаться избыточным.

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

💎 Поддержка канала⁉️

Все слова благодарности, лайки, гневные комменты и всё что на душе накипело... 👇
#CodeArchitecture

Скрипт для анализа и проверки!

🎵«Помню, помню, помню я,
Как меня мать любила.
И не раз, и не два
Она мне говорила:
Не ходи на тот конец,
Не водись с ворами,
Тебя на каторгу сошлют,
Бряцать кандалами...»
— Народная

⚠️ Никогда не попадайте на каторгу, как бы много Вам не платили - всё равно будет ощущение, что Вас обокрали.

Задача из собеса как раз на такую каторгу.

💡 Что произойдёт после выполнения этого скрипта?

WHENEVER SQLERROR CONTINUE
CREATE TABLE test_tbl (x INT);
INSERT INTO test_tbl (x) VALUES (1);

BEGIN
  INSERT INTO test_tbl (x) VALUES (2);
  RAISE VALUE_ERROR;
END;
/
SELECT * FROM test_tbl;

Внутри BEGIN ... END — вставка и ошибка. Но стоит WHENEVER SQLERROR CONTINUE.

🤔 Вопрос:
Что отработает, а что нет? Что покажет SELECT?
Будут ли строки (1) и (2), или только (1)?

⚠️ Хотите проверить скрипты, но нет базы под рукой - онлайн-песочница
💎 Поддержка канала⁉️

✍️ Пишите в комментариях, как думаете.
(Не забудьте обосновать — там всё не так просто 😉)
#RealInterviewTasks #sql #Oracle #PLSQL