SQL *

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

Т.е., таблица изначально выглядит так:

CREATE TABLE coupons (
    id  bigint primary key generated by default as identity,
    user_id bigint not null,
    created_at timestamp not null,
    valid_until timestamp not null
)

К написанию этой статьи я подошёл после продолжительного использования Kotlin Exposed в рабочих, а также персональных проектах, когда я начал анализировать генерируемые SQL запросы. В тот момент я познакомился с проблемой N+1)

Всем привет! Я расскажу, с помощью каких алгоритмов и архитектуры можно разработать с нуля интерактивную диаграмму Ганта, способную без лагов отображать тысячи задач.

Статей о селектах хватает, попробуем про апдейты. "ТОП-100" вопросов не обещаю - тут бы с одним разобраться. Разработчиков OLTP-систем под MS SQL Server и кандидатов на подобные вакансии приглашаю под кат.

Код на T-SQL, и он идеален. Атомарности нет, целостность вернём ручными апдейтами, изоляция с дюрабилити только мешают. Программируем без оглядки на ACID, который жив лишь в статье википедии.

Привет! Меня зовут Артем. Я работаю Data Scientist'ом в компании МегаФон (платформа для безопасной монетизации данных OneFactor).

В данной статье разберемся что такое live coding интервью и как к нему готовиться.

Материал в первую очередь будет полезен Data Scientist'ам и ML инженерам, при этом некоторые разделы, например, Алгоритмы и структуры данных подойдут всем IT специалистам, которым предстоит пройти секцию live coding.

Речь сегодня пойдет об отказоустойчивости и даже о катастрофоустойчивости.

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

В рамках проектов аудита производительности мы обязательно проверяем систему заказчика на предмет используемых средств отказоустойчивости и катастрофоустойчивости. И если есть основания, обязательно предоставляем рекомендации по улучшениям. Соответствующий раздел в своё время стал обязательным в каждом отчёте аудита не на пустом месте. За долгие годы мы встречались с таким количеством ситуаций, что можно начинать писать книгу :) Сама по себе ситуация краха системы редкая, поэтому вопросы отказоустойчивости далеко не везде в приоритете, а с учетом распространения в последние годы разнообразных ЦОД’ов, появляется большой соблазн снять с себя ответственность за целостность базы данных и непрерывного доступа к ней. Так что, с появлением ЦОД’ов люди совсем расслабились. А зря.

 Опишу несколько характерных примеров из нашей практики, с которыми мы столкнулись, причем в роли спасателей клиентской инфраструктуры и данных. Иногда на кону стояло само существование БД, иногда – интервал потерянных данных, иногда – время простоя бизнеса.

Мы — SQL команда Срочного рынка Московской Биржи, занимаемся разработкой и сопровождением бэкофиса торгово-клиринговой системы Spectra с момента ее возникновения. Срочный рынок Московской Биржи — это более 500 фьючерсных и 30000 опционных инструментов, несколько миллионов сделок в день.

Торгово-клиринговая система Срочного рынка (ТКС Spectra) изначально строилась на основе MS SQL, и за пару десятков лет прошла сложный путь от нескольких серверов БД до огромной системы с сервис-ориентированной архитектурой. Долгое время вся бизнес-логика системы разрабатывалась в программном слое на серверах MS SQL: и матчинг заявок, и расчет обеспечения, и управление клиентами были реализованы на T-SQL.

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

В этой статье мы хотим рассказать об эволюции нашей системы разработки на SQL.

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

Всем привет! Искусственный интеллект уже научился писать простые запросы к базам данных, но можно ли совсем избавиться от кода в работе аналитиков? Мы расскажем про наши нейросетевые эксперименты, в которых мы научили BI-систему слушать, понимать и отрабатывать запросы аналитиков на естественном языке.

В команде R&D SberData мы ищем и разрабатываем технологии обработки, хранения и анализа данных Сбера. Мы исследуем все перспективные технологии, которые появляются на рынке, разрабатываем новые продукты, которые использует Сбер и его партнёры. Одно из приоритетных направлений для нас — это анализ данных. В Сбере более 100 тысяч пользователей BI (Business Intelligence). Естественно, что у такого количества аналитиков самые разные потребности и требования к сервису и продукту. И возможность сделать их работу проще и удобнее — это большой вызов и интересная задача для нашей команды. В этот раз мы пробовали научить LLM-модель написать правильный SQL-код по запросу на естественном языке.

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

Суть MERGE заключается в ее универсальности: она позволяет объединить операции INSERT, UPDATE и DELETE в одном запросе, автоматически выбирая нужное действие в зависимости от того, существует ли соответствующая запись в целевой таблице.

Вместо нескольких отдельных запросов INSERT, UPDATE, DELETE MERGE сокращает накладные расходы на сетевой трафик и уменьшает количество обращений к диску. MERGE облегчает реализацию шаблонов SCD и других сложных сценариев управления данными.

MERGE в PostgreSQL работает с соблюдением строгих стандартов SQL, обеспечивая совместимость и переносимость кода. Также PostgreSQL обрабатывает конфликты на уровне строк, позволяя тонко настраивать логику обработки данных с использованием условий WHEN MATCHED и WHEN NOT MATCHED.

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

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

Часть 1 серии вопросов для интервью по SQL

О применении Liquibase в проектах разработки

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

Доброго времени суток. 

Ты ж у нас один программист !!!
Небольшая вводная. Я для друзей, по их запросам, выгружаю данные из MS SQL Server'а. Друзья дают исходные данные, для которых надо сделать выгрузку в файлах .csv. Исходных данных (ИД) может быть от 1 до ... строк. Я загружал данные в sql таблицу с помощью задачи или Task в английской версии в SQL Server Management Studio (SSMS). Исторически сложилось, что все sql файлы со скриптами хранятся на моем ПК. Я файлы открывал в SSMS и запускал на выполнение. Результаты записывал в файл и отправлял сообщение, что обработка выполнена. Друзья забирали файлы с результатами. 

Но в один творческий день пришла идея автоматизировать этот процесс, чтобы Друзья все делали сами, с минимальным моим участием. 

SQL (Structured Query Language) – это язык программирования, используемый для управления реляционными базами данных. В этой статье я собрал вопросы по SQL, с которыми вы можете столкнуться на собеседовании. Их часто задают для проверки общих знаний и навыков.

В процессе разработки программ с обращениями к базам данных часто возникает проблема создания SQL-запроса по большому количеству таблиц. Существует два варианта: один сложный запрос с большим количеством Join’ов и условий или несколько простых SQL-запросов с последовательным применением результата обработанного запроса к следующим запросам. Какой более эффективный? Читайте в статье.

Что побудило меня написать эту статью? Я обучаю стажеров – системных аналитиков, и недавно столкнулась с такими вопросами, о которых раньше даже не задумывалась.

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

В этой статье мне хотелось разобрать разные вопросы с доказательными примерами.

В статье предлагается решение по быстрому написанию консистентного обновления базы данных в среде SAP NetWeaver на языке программирования ABAP (хотя подход может быть применен и к другим языкам). Описанный в статье подход является результатом субъективного опыта автора, но выполнен в соответствии с рекомендованным подходом ABAP-справки.

Если проект использует реляционную СУБД обязательно возникнет вопрос - как организовать скрипты для сохранения гибкости и уменьшения трудозатрат.

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

В данной статье рассмотрены некоторые особенности использования языка SQL в реляционных СУБД и Apache Hive. Кроме того, проведен сравнительный обзор возможностей и подходов, а также применение партиционирования на практике.

Материал будет полезен специалистам младших и средних грейдов, которые используют в своей практике SQL, но имеют мало опыта в Hive или Postgres.

В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.

Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:

«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»

Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.

Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.