Как стать автором
Обновить
94.79

SQL *

Формальный непроцедурный язык программирования

Сначала показывать
Порог рейтинга
Уровень сложности

«IT-Планета 2025»: задачи третьего этапа по PostgreSQL

Время на прочтение12 мин
Количество просмотров511

На третьем этапе олимпиады мы, как обычно, решали задачки на SQL, но в этом году надо было написать запрос не просто правильный, но и короткий. Чем короче — тем лучше результат. В детстве мы развлекались таким на микрокалькуляторах и на ассемблере, а сейчас я решил посмотреть, что получится, если попробовать то же на SQL. Получилось, на мой взгляд, интересно. Практического смысла в этом, конечно, никакого нет, но практики и на работе хватит, а тут мы развлекаемся.

Чтобы хорошо выступить, надо было — помимо прочего — выстроить правильную стратегию. Сразу писать максимально короткий запрос, без пробелов и с односимвольными именами не получится — легко самому запутаться. Поэтому сначала надо было решить задачу «по-человечески», а уже потом применить всякие микрооптимизации и получить заветные баллы. Но решить задачу, даже простую, всегда можно разными способами, и не всегда заранее понятно, какой из вариантов окажется короче после оптимизации. Поэтому нужно было не останавливаться, пробовать разные подходы, и при этом аккуратно хранить все версии, чтобы в любой момент можно было посмотреть на запрос еще раз и, чем Тьюринг не шутит, выиграть байтик-другой.

Мы традиционно разрешали пользоваться всеми благами интернета, включая ИИ. На эту тему многие сейчас переживают, но, честно говоря, я пока не вижу причин для беспокойства. Вот если бы все участники показали одинаково прекрасный результат, пришлось бы что-то придумывать. И то, конечно, не запрещать ИИ, а делать задачи более сложными. Но результаты у всех разные, и без собственной головы на плечах их не удалось бы получить (я попробовал), поэтому пока все хорошо. Если финалисты меня читают, было бы интересно услышать комментарии от первого лица: пользовались ли вы ИИ, насколько он вам помог или, может быть, наоборот, только отвлекал?

Итак, к задачам

Новости

Как заставить вашу базу данных летать, а не ползать. Часть 3 – ещё три способа шардирования

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров2.5K

Всем привет! И снова с вами Илья Криволапов – системный аналитик в SENSE, где мы вместе с командой трудимся над проектом одного из цветных банков РФ. Напоминаю, что в профессии я уже больше пяти лет и, несмотря на фамилию, прод все еще живой и здоровый (ну почти)!

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

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

Материал будет полезен всем, кто проектирует, масштабирует или просто поддерживает «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Финальный рывок – поехали!

Читать далее

Миграция с Firebird на PostgreSQL. Что может пойти не так? Часть 3

Время на прочтение10 мин
Количество просмотров552

Третья часть статьи посвященной трудностям миграции с Firebird на PostgreSQL. (1ая часть, 2я часть).

Читать далее

Миграция с Firebird на PostgreSQL. Что может пойти не так? Часть 2

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров2.3K

В первой части обсуждалось как отличие реализации MVCC в Firebird и PostgreSQL может привести к сложностям при миграции информационной системы. Напоминаю девиз этой серии статей – "Ваши ожидания – это Ваши проблемы". Рассмотрим еще некоторые моменты, которые позволят Вам не находится в состоянии "обманутых ожиданий" при миграции с Firebird на PostgreSQL.

Читать далее

Миграция с Firebird на PostgreSQL. Что может пойти не так? Часть 1

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров6.2K

Не секрет, что в последние годы различные компании достаточно часто принимают решение о миграции работающей информационной системы с Firebird на PostgreSQL.

Типичная ситуация выглядит так:

Проект работает несколько лет. Заказчик «верит», что проблема не в проекте, а в СУБД. Firebird — «плохая» СУБД.

Читать далее

Изучение Python за 2 недели через боль и дедлайн: личная история

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров13K

Изучил Python за короткий срок. Личная история. Взяли без знаний, но я смог до всяческих дедлайнов, пройдя огромное количество стресса, изучить язык программирования и даже этим спасти проект.

Читать далее

Четвёртый (и предпоследний) шаг к повышению производительности Firebird

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров794

Данная статья является четвёртой частью перевода руководства по повышению производительности Firebird за авторством А.Ковязина и Э.Грегорио от 23.05.2024 (и потому продолжается сквозная нумерация пунктов), а так же текстовой расшифровкой соответствующего видео.

Читать далее

Пятый и последний шаг к повышению производительности Firebird

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров953

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

Читать далее

Как хранить деньги в базах данных и почему это не так просто, как кажется

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров22K

Хранение денежных сумм в базах данных и API: анализ подходов платежных систем

Хранение денег — вещь только на первый взгляд простая, а на деле содержит множество подводных камней. Выбрав не тот тип данных, можно получить неточности в расчётах, возможна путаница при переводе суммы из одной валюты в другую. А если ещё и подключать внешние API, у каждого из которых своя точность для одних и тех же валют, уследить за совместимостью еще труднее.

Разбираем, как решают эти проблемы Stripe, PayPal, Google Wallet и другие платежные системы. Сравниваем три основных подхода: Integer minor units, Decimal base units и String base units.

Читать далее

Работа с данными в DuckDB или не pandas’ом единым сыт DS

Время на прочтение9 мин
Количество просмотров2.3K

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

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

Читать далее

Типы данных для хранения вещественных чисел в PostgreSQL

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров1.8K

В статье рассматриваются особенности типов данных для хранения вещественных чисел в PostgreSQL.

Типы данных PostgreSQL для работы с вещественными числами:

1) float4, синоним real, синоним float(1..24)

2) float8, синоним float, синоним double precision, синоним float(25..53)

3) numeric синоним decimal. Диапазон для этого типа значительный: 131072 цифр до точки и 16383 цифр после точки. Но если при определении типа указать numeric(точность, масштаб), то максимальные значения точности и масштаба 1000. numeric можно объявить с отрицательным масштабом: значения могут округляться десятков, сотен, тысяч.

Кроме чисел и null поддерживаются значения Infinity, -Infinity, NaN.

Поля типов данных фиксированной длины не могут вытесняться в TOSAT-таблицу, переменной длины (numeric) могут.

float4 обеспечивает точность 6 разрядов (значащих чисел в десятичной системе счисления), float8 обеспечивает точность 15 разрядов. Последний разряд округляется:

Читать далее

Что нового в Apache Spark 4.0

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров2.5K

Apache Spark — это мощный фреймворк для распределённой обработки больших объёмов данных, позволяющий выполнять сложные вычисления на кластерах компьютеров с высокой производительностью и гибкостью.

И вот 23 мая 2025 года компания Apache выпустила новую версию Spark 4.

Стоит отметить, что Apache Spark — масштабный фреймворк с широким функционалом. В данной статье я сосредоточусь на нововведениях, которые в первую очередь затронут пользователей Spark SQL и PySpark.

Читать далее

Как не облажаться с типами данных в PostgreSQL

Уровень сложностиСредний
Время на прочтение19 мин
Количество просмотров9.7K

Недавно вышла отличная книга PostgreSQL Mistakes and How to Avoid Them от Jimmy Angelakos — системного архитектора, практика и давнего участника сообщества PostgreSQL. Книга подробно разбирает распространённые ошибки, с которыми сталкиваются разработчики и администраторы при работе с PostgreSQL, и предлагает практичные решения: от тонкостей конфигурации и миграции до антипаттернов в SQL и выбора типов данных.

Я перевёл одну из ключевых глав этой книги — про неправильное использование типов данных. В ней подробно объясняется, почему, например:

timestamp without time zone может ломать логику расчёта интервалов;

money — это не то, чем кажется (и почему он опасен);

char(n) и varchar(n) не дают ожидаемой экономии и даже вредны;

serial — это прошлый век, а identity — настоящее.

Глава будет полезна всем, кто работает с PostgreSQL в проде — особенно backend-разработчикам, независимо от языка и фреймворка. Если вы проектируете схемы БД, пишете SQL-запросы или просто хотите избежать неприятных грабель — стоит прочитать.

Читать далее

Ближайшие события

Реляционные базы данных в книге «Двенадцать стульев»: как устроен архив Коробейникова

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров2K

Меня зовут Екатерина Петрова, я автор медиа «вАЙТИ» и аналитик. Перечитывая свой любимый роман И. Ильфа и Е. Петрова «Двенадцать стульев», а именно сцену с архивариусом Коробейниковым, я вдруг поняла: его бумажный архив ордеров на имущество бывших дворян не что иное, как идеальный пример реляционной базы данных. Алфавитные указатели — это индексы, книги учета — таблицы с первичными ключами, ордера — настоящие транзакции.

Читать далее

Особенности SUMMARIZECOLUMNS в DAX

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров1.1K

Привет, Хабр! В аналитическом языке DAX одной из важных функций является SUMMARIZECOLUMNS. Эта функция готовит данные для дашбордов, также реализует декартово произведение полей группировки (если поля группировки из разных таблиц). Для понимания DAX полезно ознакомиться с особенностями SUMMARIZECOLUMNS, интересующимся деталями SUMMARIZECOLUMNS — добро пожаловать под кат :)

Читать далее

Портирование фреймворка ROOT на архитектуру e2k

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров1.3K

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

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

В статье рассмотрим "айсберг" проблем, с которыми пришлось столкнуться в ходе портирования ROOT, а такжк сферу и примеры его применения.

О портировании и тестах ROOT читайте далее

Регулярная отчетность. Цифры решают все

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров562

В послевоенное советское время убивали словом, по крайней мере, так было принято в кругу друзей прекрасного поэта Шефнера. Никакой крамолы, но это только полуправда: в Люблино уже тогда куда больше ценилась финка за голенищем, но оставим былое.

Как говорят нам опытные инфоцыгане коучи в модно-стильно-молодежно снятых роликах на YouTube RuTube — сейчас время data driven подхода! А значит убивают нынче цифрой. Я, если кому-то интересно, предпочитаю, семерку, она более всего походит на старый добрый мушкет или, на крайний случай, серп.

Шутки в сторону. В современном мире, когда каждая наша «улыбка» — не более чем поток единиц и нулей, который позволяет системе распознавания лиц списать с нас 67 рублей за проезд, цифры, действительно, определяют многое. Раньше обидным было слышать про небольшой размер достоинства, теперь, у топ-менеджмента корпораций досаду, гнев и злость вызывать маленькая EBITDA или ROI. О времена! О нравы! Да простит меня Александр Сергеевич.

10 лет назад я впервые познал силу цифр. До того момента я думал, что аналитика — это красивые отчеты, за которые платят много денег западным консалтинговым компаниям ради имиджа. Функциональное назначение трудов PWC, Mckinsey и прочих сильных мира сего ограничивалось следующим: орудие для удара по голове нерадивому сотруднику, оконный ограничитель летом в душном офисе, ну и, конечно, подставка под шатающийся стул. Все. То есть совсем все. Ни разу не видел, чтобы кто-то открыл их для того, чтобы принять какое-то важное решение, по крайней мере, так не везло мне. Творцы этих шедевров: несчастные стажеры, дизайнеры и прочие ребята в красивых костюмах с очень утомленными лицами и натянутыми улыбками, за которые тогда хотя бы не списывали деньги, сами в кулуарах признавали тщетность своих мук. Впрочем, это не мешало им продолжать ночами повторять сизифов труд, чтобы потом потратить заработанное на волшебные таблетки самого разного цвета и магических свойств.

Читать далее

Дело о похищенном рюкзаке: SQL, сложность и слепая вера в ИИ

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров1.3K

1. Тревожный звонок

Был хмурый лондонский вечер, когда в нашу скромную квартиру на Бейкер-стрит ворвался взволнованный инспектор Лестрейд.

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

Читать далее

Тестирование систем и движков массивно-параллельных вычислений. Часть II. TPC-DS

Уровень сложностиСредний
Время на прочтение13 мин
Количество просмотров1.5K

Привет! Сегодня я продолжаю тему сравнения систем и движков массивных параллельных вычислений. В прошлой публикации я раскрыл основные принципы проведения тестирования, которыми руководствуется наша команда, и привел результаты как реальных промышленных сценариев, так и синтетических тестов. Материал вызвал интерес и дискуссию: значит, он актуальный и полезный. Для кого-то факты стали убедительными, а кто-то усомнился в объективности результатов, поэтому, как и было обещано, я делюсь материалами сравнительного тестирования, выполненного по общепринятому стандарту TPC-DS. Сегодня вы узнаете, повлияла ли смена методики на результаты.

Читать далее

«IT-Планета 2025»: задачи второго этапа по PostgreSQL

Уровень сложностиПростой
Время на прочтение29 мин
Количество просмотров2.8K

Мы продолжаем свое участие в международной олимпиаде «IT-Планета».  Как и в прошлые годы, проводился конкурс по SQL, состоящий из трех этапов: теоретический и практический туры, проходящие онлайн, и финальный очный тур.

В первом туре участвовало свыше 4 500 человек, из которых 245 были отобраны во второй. В этом году я занимался разработкой задач и проведением первых двух туров. Предлагаю перейти к рассмотрению задач практического этапа.

Читать далее
1
23 ...

Вклад авторов