SQL-Ex blog

Пересказ статьи Prakash K. Unlocking Power with Updatable Views in SQL Server

Реляционные системы управления базами данных (РСУБД) основаны на структурированном языке запросов (SQL) в плане управления и манипуляции данными. Представления в SQL Server предоставляют эффективный способ абстрагироваться от лежащих в основании сложных структур данных. В то время как многие представления доступны только на чтение, обновляемые представления открывают дверь к динамической манипуляции данными с помощью операций INSERT, UPDATE и DELETE. В этом руководстве мы познакомимся с понятием обновляемых представлений в SQL Server, исследуем операции с ними и дадим полезный пример.

Понятие обновляемого представления

Обновляемое представление в SQL Server - это представление, которое допускает модификацию, т.е. применение таких операторов, как INSERT, UPDATE или DELETE к таблицам через представление. Чтобы сделать представление обновляемым, оно должно удовлетворять нижеприведенным критериям.
Продолжить чтение "Раскройте силу обновляемых представлений в SQL Server"

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 89 (SELECT)		6		6
 31 (DML)		5		7
 780 (SELECT)		2		10

§ Авторы недели на форуме

Автор		Сообщений
 JavidanLi	7
 _Bkmz_  	4
 qwrqwr  	3
 selber  	2
 Sa1avat  	2

Продолжить чтение "Новости за 2025-03-15 - 2025-03-21"

В SQL Server 2022 появилась функция генерации числовой последовательности, GENERATE_SERIES. Подобная функция имеется в некоторых других СУБД, в частности, в PostgreSQL. Вот, например, как с помощью этой функции решалась следующая задача из учебника.

Вывести последовательность дат между датами первого и последнего полета пассажира с id_psg = 5.

Решение:

SELECT generate_series(MIN(date), MAX(date), '1 day')

FROM pass_in_trip 

WHERE id_psg = 5;

Продолжить чтение "GENERATE_SERIES в SQL Server"

Пересказ статьи Yasin Sari. LATERAL as an Advanced SQL Feature

Я всегда представляю себе аналитика данных человеком, который имеет правильный инструмент для решения реальных проблем, во многом подобный швейцарскому армейскому ножу. Lateral - это одна из функций стандарта ANSI SQL, которая вам может пригодиться в некоторых случаях, поскольку она помогает легко решать проблемы. Я хочу продемонстрировать ее на нескольких примерах, чтобы показать, как она может улучшить анализ данных, обеспечив большую гибкость, скорость, сократить время и так далее.

Тематика

• SQL


• PIVOT


• PostgreSQL


• LATERAL JOIN


• Коррелирующие подзапросы

Продолжить чтение "LATERAL как расширенная функция SQL"

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 190 (Learn)		3		4
 126 (SELECT)		3		6

§ Авторы недели на форуме

Автор		Сообщений
 JavidanLi	6
 lutik	5
 Nitrinos	2
 selber  	2
 zigmund1  	2

Продолжить чтение "Новости за 2025-03-08 - 2025-03-14"

Пересказ статьи MyFaduGame. Mastering FastAPI CRUD Operations with Async SqlAlchemy and PostgreSQL

В этом подробном руководстве мы познакомимся с построением надежных операций CRUD (Create, Read, Update, Delete) с помощью FastAPI, используя мощь Async SqlAlchemy и интеграцию с PostgreSQL для высокопроизводительного асинхронного взаимодействия с базой данных.

Мы разделим наш проект Fruit Full на несколько этапов:

1. Введение в FastAPI и Async SqlAlchemy: Мы начнем с введения в FastAPI, современный, высокопроизводительный фреймворк Python для построения API, и Async SqlAlchemy, асинхронную версию SqlAlchemy, которая допускает неблокирующие операции с базой данных.


2. Установка проекта: Мы проведем вас через установку проекта FastAPI с помощью SqlAlchemy и PostgreSQL. Это включает создание модели, конфигурирование соединения с базой данных и определение асинхронных операций CRUD.


3. Асинхронные операции CRUD: Изучение выполнения асинхронных операций CRUD, используя FastAPI и Async SqlAlchemy. Мы обсудим асинхронное создание, чтение, обновление и удаление записей в базе данных.


4. Обработка связей: Изучение асинхронной обработки связей между таблицами базы данных с использованием Async SqlAlchemy. Мы обсудим подробно связи один-к-одному, один-ко-многим и многие-ко-многим.


5. Обработка ошибок и проверка: Изучение методов обработки ошибок и проверки данных в FastAPI, гарантирующих целостность и безопасность ваших конечных точек API. Мы обсудим проверку входа, ответы об ошибках и обработку исключений.

Продолжить чтение "Освоение операций FastAPI CRUD с помощью Async SqlAlchemy и PostgreSQL"

Пересказ статьи Lorenzo Uriel. The SQL Week: Data Modeling

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

Одним из наиболее любимых мной процессов является моделирование данных.

Итак, из чего состоит процесс моделирования?

Можно упомянуть:

1. Анализ требований
2. Концептуальная модель (ERD - ERM)
3. Логическая модель (таблицы и связи)
4. Физическая модель (создание таблиц в базе данных)

Это будут пункты этой части, в результате которой я хочу построить с вами реальный пример с нуля.
Продолжить чтение "Неделя SQL: моделирование данных"

Прекрасную половину сайта SQL-EX поздравляем с праздником 8 Марта и желаем здоровья и счастья!

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 239 (SELECT)		4		2
 82 (Learn)		3		7
 87 (Learn)		3		9
 4 (SELECT)		3		7
 235 (SELECT)		2		4

§ Авторы недели на форуме

Автор		Сообщений
 Nividimka	4
 JavidanLi	4
 pegoopik  	4
 morozhenka	4
 Gambit87	3

Продолжить чтение "Новости за 2025-03-01 - 2025-03-07"

Пересказ статьи Python Code Nemesis. Understanding returning in SQLAlchemy with Python

Предложение RETURNING, имеющееся во многих диалектах SQL, например, PostgreSQL, MariaDB и SQL Server, позволяет возвращать значения из строк, к которым применялся оператор UPDATE или DELETE, при выполнении самого оператора. Это может быть особенно полезно, когда вам необходимо:

• Получить значения после их обновления и использовать их затем в коде.


• Получить информацию об удаленных строках для журнализации и аудита.

Давайте начнем.

Продолжить чтение "Понимание RETURNING в SQLAlchemy с Python"

Пересказ статьи Andy Brownsword. Solving Parameter Sniffing with Multiple Execution Plans

Динамический SQL имеет много вариантов использования, и один из них может помочь нам разрешить проблемы прослушивания параметра (Parameter Sniffing). Здесь мы рассмотрим как он может использоваться для генерации нескольких планов выполнения для одного и того же запроса.

Прослушивание параметра является общеизвестной проблемой. Даже для простых запросов мы можем столкнуться с получением неоптимального плана. Имеется несколько способов с применением динамического SQL, которые мы можем использовать для решения этой проблемы. Тут мы продемонстрируем один из них: инъекция комментария.

Давайте начнем с процедуры и индекса в базе данных StackOverflow:

CREATE OR ALTER PROCEDURE dbo.GetPopularUsers (

    @MinimumViews INT

) AS

BEGIN

    SELECT Id, DisplayName

    FROM dbo.Users

    WHERE [Views] >= @MinimumViews;

END

GO

CREATE INDEX [Views]

ON dbo.Users ([Views]);

Продолжить чтение "Решение проблемы прослушивания параметра при помощи нескольких планов выполнения"

Пересказ статьи Erik Darling. The How To Write SQL Server Queries Correctly Cheat Sheet: Cross Apply And Outer Apply

Ситуации

В конечном счете я преобразую множество производных соединений, особенно тех, которые используют оконные функции, к использованию синтаксиса APPLY. Иногда для этого существуют хорошие индексы, в других случаях необходимо их создавать, чтобы избежать "Жадного спула индексов".

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

Короткий ответ заключается в том, что я начинаю мысленно представлять себе, как синтаксис apply может быть полезен, когда:

• Имеется небольшая внешняя таблица (FROM) и большая внутренняя таблица (APPLY).


• Мне требуется выполнить значительный объем работы на внутренней стороне соединения.


• Целью запроса является получение top N на группу или что-то подобное.


• Я пытаюсь получить параллельные вложенные циклы вместо выбора некоторого альтернативного плана.


• Чтобы заменить скалярную UDF в списке select на встроенную (inline) UDF.


• Чтобы использовать конструкцию VALUES необычным способом.

Большинство этого ситуативно и требует немного опыта и знакомства, чтобы быстро это заметить.
Продолжить чтение "Шпаргалка по правильному написанию запросов к SQL Server: Cross Apply и Outer Apply"

§ selber уточнил формулировку задачи 143 (SELECT, рейтинг).

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 17 (SELECT)		4		3
 303 (SELECT)		3		6
 Guest's book		2		17

§ Авторы недели на форуме

Автор		Сообщений
 Nividimka	2
 pegoopik  	2
 Gambit87	2

Продолжить чтение "Новости за 2025-02-22 - 2025-02-28"

Пересказ статьи Andrea Gnemmi. PostgreSQL Create Database Options and Settings

Первое, что нужно сделать администратору базы данных на новом экземпляре РСУБД, - это создать базу данных. Давайте узнаем, как это делается в PostgreSQL, включая синтаксис, особенности и отличия от других РСУБД.

Здесь будут рассмотрены все особенности и варианты синтаксиса команды CREATE DATABASE в PostgreSQL.

CREATE DATABASE в PostgreSQL

Базовый синтаксис команды CREATE DATABASE весьма прост и незатейлив: напечатайте CREATE DATABASE и имя базы данных, это все. Однако при этом вы должны иметь необходимые привилегии как суперпользователь (superuser) или иметь разрешение CREATEDB.

Краткое отступление о суперпользователе: в PostgreSQL это роль, довольно близкая к sa в SQL Server, и суперпользователь postgres создается по умолчанию при установке PostgreSQL. Мы вернемся к этой теме, когда я напишу более подробную статью о ролях. Так или иначе, эта тема вкратце раскрыта в следующих двух статьях:

Продолжить чтение "Параметры и настройки создания базы данных в PostgreSQL"

Пересказ статьи Erik Darling. The How To Write SQL Server Queries Correctly Cheat Sheet: EXISTS and NOT EXISTS

Замечательная вещь, связанная с SQL, состоит в том, что имеется много директив, которые довольно легко понять и использовать по назначению.

Ужасная вещь, относящаяся к SQL, заключается в том, что в нем столько же правил, которые применяются избирательно, как и в самом английском языке.

У меня, конечно, есть свои жалобы и недовольство относительно выбора некоторых из них, и вы тоже в этом убедитесь, когда глубже вникните в язык. Типичным примером этого типа является мое желание использовать в SQL GET вместо SELECT для извлечения данных.

Очень немного людей идут в магазин выбирать (select) молоко, яйца, масло, соль, перец и виски. Большинство из нас просто идет взять (get) их. Но хватит о завтраке.

Давайте поговорим о двух наиболее часто упускаемых из виду и недооцененных возможностях в языке SQL: EXISTS и NOT EXISTS. Возможно, они бы больше привлекали внимание, если бы назывались THERE and NOT THERE, но тогда была бы опасность начального затруднения с предложениями WHERE и THERE.

Часто очерняемые теми, кто читал статью в 1998 о "подзапросах в MySQL, которые медленнее, чем соединения", эти предикаты являются двумя наиболее полезными вещами, которые вы можете освоить и использовать регулярно.

Хотя они несколько напоминают подзапросы, столбцы, которые вы выбираете в подзапросе EXISTS или NOT EXISTS не могут использоваться во внешнем запросе. Вы можете поместить что угодно в список SELECT, от * или 1 до COUNT или 1/0, или всего содержимого Библии короля Якова, и это никогда не приведет ни к каким даже самым незначительным изменениям в мире. Аналогично, добавление DISTINCT, TOP или любого другого ограничителя числа строк не сделает ничего такого, чтобы изменить план запроса или его производительность.

Преодолейте себя.

И EXISTS, и NOT EXISTS уже установили число строк в 1, поскольку все, что нужно сделать каждому из них, это определить, существует хотя бы одна строка или нет, и наоборот.
Продолжить чтение "Шпаргалка по правильному написанию запросов к SQL server: EXISTS и NOT EXISTS"

Пересказ статьи Semab Tariq. PostgreSQL Internals Part 2: Understanding Page Structure

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

Во второй части мы изучим внутреннюю структуру страницы в PostgreSQL. Первую часть вы можете найти здесь.

Обзор макета страницы в PostgreSQL

При создании таблицы генерируется соответствующий файл данных. Внутри этого файла данные размещаются на страницах фиксированной длины, обычно 8-килобайтных, что принимается по умолчанию. Каждой странице присваивается последовательный номер, начиная с 0, который называется номером блока. PostgreSQL добавляет новую пустую страницу к концу файла, когда он заполняется. Тем самым увеличивается размер файла данных.
Продолжить чтение "PostgreSQL изнутри. Часть 2: понимание структуры страницы"