SQL *

При разработке приложений баз данных я использую очень простую мантру:

если можно, сделай это с помощью одного оператора SQL;
если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;
если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;
если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке C;
если это нельзя реализовать в виде внешней процедуры на языке C, надо серьезно подумать, зачем это вообще делать...

Привет!

Сегодня мы немного поговорим про EntityFramework. Совсем чуть-чуть. Да, я знаю что к нему можно относиться по-разному, многие от него плюются, но за неимением лучшей альтернативы — продолжают использовать.

Так вот. Часто ли вы используете в своём C#-проекте с настроенным ORM-ом прямые SQL-запросы в базу? Ой, да бросьте, не отнекивайтесь. Используете. Иначе как бы вы реализовывали удаление/обновление сущностей пачками и оставались живы…

Что мы больше всего любим в прямом SQL? Скорость и простоту. Там, где "в лучших традициях ORM" надо выгрузить в память вагончик объектов и всем сделать context.Remove (ну или поманипулировать Attach-ем), можнo обойтись одним мааааленьким SQL-запросом.
Что мы больше всего не любим в прямом SQL? Правильно. Отсутствие типизации и взрывоопасность. Прямой SQL обычно делается через DbContext.Database.ExecuteSqlCommand, а оно на вход принимает только строку. Следовательно, Find Usages в студии никогда не покажет вам какие поля каких сущностей ваш прямой SQL затронул, ну и помимо прочего вам приходится полагаться на свою память в вопросе точных имён всех таблиц/колонок которые вы щупаете. А ещё молиться, что никакой лоботряс не покопается в вашей модели и не переименует всё в ходе рефакторинга или средствами EntityFramework, пока вы будете спать.

Так ликуйте же, адепты маленьких raw SQL-запросов! В этой статье я покажу вам как совместить их с EF, не потерять в майнтайнабильности и не наплодить детонаторов. Ныряйте же под кат скорее!

Часть 1. Новая надежда

Предисловие

SELECT DISTINCT 
  process.name, 
  listening.port, 
  process.pid
FROM processes AS process
JOIN listening_ports AS listening
ON process.pid = listening.pid
WHERE listening.address = '0.0.0.0';

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

Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности?

В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.

Привет, Хабр! Когда-то я проверяла завещания и готовила доверенности, а теперь проверяю витрины данных, ищу дубли и считаю доходность по инвестиционным инструментам. Меня зовут Арина Шахтарина, и я — Data Quality-инженер в Сбере. Это история о том, как любовь к данным и таблицам превратилась в новую профессию, и почему SQL — лучший универсальный язык после русского. Тут будет про карьерные повороты, боли с форматами данных, проверки данных и немного про мечты, которые сбываются (даже если ты не в отпуске).

В мире управления базами данных от эффективного хранения больших объемов информации зависит оптимизация производительности и использования дискового пространства. В этой статье разберем основные методы сжатия данных в TOAST, их эволюцию, плюсы и минусы PGLZ и LZ4 и продемонстрируем базовую работу с TOAST в Postgres. В завершение обсудим, как данные с различными методами сжатия могут храниться в одной TOAST-таблице.

В прошлой статье я показал, как условие с парой однотипных неравенств, плохо поддающееся индексации с помощью btree, можно переделать на эффективно gist-индексируемое в PostgreSQL условие относительно диапазонных типов, а наш сервис анализа планов запросов explain.tensor.ru подскажет, как именно это сделать.

Но что делать, если неравенств у нас не два, а целых четыре, да еще и с разными типами участвующих полей? Например, для целей бизнеса это может быть задачей вроде "найди мне все продажи за декабрь на сумму 10-20K", что на SQL будет выглядеть примерно так:

dt >= '2023-12-01'::date AND dt <= '2023-12-31'::date AND

sum >= 10000::numeric AND sum <= 20000::numeric

Эта статья является переводом статьи Мигеля Гринберга.

Возможно, вы слышали, что основная версия SQLAlchemy 2.0, была выпущена в январе 2023 года. Или, может быть, вы пропустили объявление и это новость для вас. В любом случае, я подумал, что вам будет интересно узнать, что в нем нового, стоит ли его обновлять и насколько сложно это сделать.

Как и в предыдущих обзорах программного обеспечения, это будет субъективный обзор. Я давно использую SQLAlchemy ORM в веб-проектах, поэтому в этой статье я расскажу о функциях, которые влияют на мою собственную работу, как в положительную, так и в отрицательную сторону. Если вместо этого вам интересно увидеть список всех изменений, внесенных в этот новый релиз, то официальный журнал изменений — это то что вам нужно.

Периодически приходится разбирать случаи внезапного промаха запроса мимо "вроде бы подходящего" индекса - а все дело оказывается в чуть-чуть не той сортировке.

Признаюсь честно, у меня как у программиста, хоть и не настоящего, есть недоверие к «no-code» решениям. То есть тем, которые не требуют программирования, где всё можно делать через drag-and-drop и клики мышкой. Но после полугода разработки собственного «no-code» ETL сервиса с визуализацией данных я изменил отношение к этому классу продуктов, начал ими пользоваться и даже получать пользу, экономя время на рутинных операциях по анализу данных из логов, баз данных и файлов.

В этой заметке я предложу несколько вариантов загрузки и парсинга данных из сервисов и по URL с «материализацией» в SQL базу, покажу как за пару минут собрать свой информер с отправкой в Telegram, Slack или на email. И всё это произойдет без единой строчки кода (потому что в сервисе TABLUM.IO этот код уже кто-то написал ;-). «Алхимия данных» начинается под катом.

В среднем 24,1 ответа в день (если все 365 дней в году считать рабочими) на протяжении почти 10 лет.

Несколько дней назад на некоторых англоязычных ресурсах началось обсуждение одного очень необычного пользователя Stack Overflow. Его зовут Гордон Линофф (Gordon Linoff), он из Нью-Йорка, и за 9 лет и 8 месяцев своего присутствия на платформе он дал 85,201 ответов на различные вопросы, в основном связанные с SQL и дата-майнингом (цифра актуальна на 27.09.2021).

Что это за маг?