Чтобы управлять базами данных и находить нужную информацию, запросы к ним пишут на специальных языках. Самый популярный из них — SQL.
SQL в современном мире является наиважнейшим инструментом для разработчиков, аналитиков данных и для всех тех, кто работает с большими объемами данных.
В нашей сегодняшней статье мы расскажем об еще 5 ошибках в SQL.
1. Цикл с слишком многими курсорами
Курсоры, циклические структуры в языке SQL— это основа производительности базы данных. Они позволяют вам проходить через миллионы записей и запускать операторы для каждой из них в отдельности. Хотя это может показаться преимуществом, оно может снизить производительность базы данных. Циклы распространены в языках программирования, но они неэффективны в программировании SQL. Большинство администраторов баз данных отклоняют процедуры SQL с внедренными курсорами.
Лучше всего написать процедуру по-другому, чтобы избежать негативного влияния на производительность базы данных, если это возможно. Большинство курсоров можно заменить хорошо написанным оператором SQL. Если вы не можете избежать этого, то курсоры следует сохранить для запланированных заданий, которые выполняются в непиковые часы. Курсоры используются в отчетах о запросах и заданиях на преобразование данных, поэтому их не всегда можно избежать. Просто ограничьте их как можно больше в производственных базах данных, которые ежедневно выполняют запросы к вашей базе данных.
2. Несоответствия данных в процедурах назначения на местах
Когда вы объявляете столбцы таблицы, вы должны назначить каждому столбцу тип данных. Убедитесь, что этот тип данных охватывает все необходимые значения, которые необходимо сохранить. Определив тип данных, вы можете хранить только этот тип значения в столбце.
Например, вам, вероятно, нужна десятичная точность на 2-3 пункта в столбце, в котором хранится общая стоимость заказа. Если вы назначите этот столбец как целое число, ваша база данных сможет хранить только целые числа без десятичных значений. Что происходит с десятичными знаками зависит от вашей платформы базы данных. Он может автоматически обрезать значения или выдать ошибку. Любая альтернатива может создать серьезную ошибку в вашем приложении. Всегда учитывайте то, что вам нужно хранить при разработке ваших таблиц.
Это включает в себя написание запросов — когда вы пишете свои запросы и передаете значения параметров в хранимую процедуру, переменная должна быть объявлена с правильным типом данных. Переменные, которые не представляют тип данных столбца, также будут выдавать ошибки или обрезать данные в процессе.
3. Логические операции OR и AND
При написании ваших запросов легко упустить простой логический порядок. Операторы AND и OR могут значительно изменить набор данных. Вы можете избежать распространенных ошибок SQL, используя круглые скобки или организовав свои операторы для представления логики, которая должна применяться.
Давайте посмотрим на оператор SQL, который смешивает операторы AND и OR.
SELECT CustomerId
FROM Customer
WHERE FirstName = 'AndreyEx' AND LastName = 'Destroyer' OR CustomerId > 0
Цель приведенного выше утверждения состоит в том, чтобы получить любых клиентов с именем и фамилией «AndreyEx» и «Destroyer», а идентификатор клиента больше нуля. Однако, поскольку мы смешали оператор AND с OR, возвращаются все записи, в которых идентификатор клиента больше нуля. Мы можем преодолеть это логическое препятствие, используя круглые скобки. Давайте добавим их к приведенному выше утверждению.
SELECT CustomerId
FROM Customer
WHERE (FirstName = 'AndreyEx' OR LastName = 'Destroyer') AND CustomerId > 0
Мы изменили логику для этого утверждения. Теперь первый набор скобок возвращает все записи, в которых имя клиента — AndreyEx или фамилия Destroyer. С помощью этого фильтра мы сообщаем SQL, чтобы он возвращал только те значения, где CustomerId больше нуля.
Эти типы логических утверждений должны быть хорошо проверены перед выпуском их в производство.
4. Подзапросы должны возвращать одну запись
Подзапросы не являются оптимальным способом написания операторов SQL, но иногда их невозможно избежать. Когда вы используете подзапросы, они всегда должны возвращать одну запись, иначе ваш запрос не будет выполнен.
Давайте посмотрим на пример.
SELECT CustomerId,
(SELECT OrderId FROM Order o WHERE c.CustomerId = o.CustomerId)
FROM Customer c
В приведенном выше запросе мы получаем список идентификаторов клиентов из таблицы Customer. Обратите внимание, что мы получаем идентификатор заказа из таблицы заказов, где совпадает идентификатор клиента. Если есть только один заказ, этот запрос работает нормально. Однако, если для клиента существует более одного заказа, подзапрос возвращает более одной записи, и запрос не выполняется. Вы можете избежать этой проблемы, используя оператор «Top 1».
Давайте изменим запрос на следующий.
SELECT CustomerId,
(SELECT Top 1 OrderId FROM Order o WHERE c.CustomerId = o.CustomerId ORDER BY OrderDate)
FROM Customer c
В приведенном выше запросе мы извлекаем только одну запись и упорядочиваем записи по дате. Этот запрос получает первый заказ, размещенный клиентом.
5. JOIN к индексам
Таблица всегда должна быть хорошо проиндексирована, и вы можете воспользоваться этими улучшениями производительности, используя оператор JOIN для столбцов, присвоенных индексу. В предыдущих примерах мы использовали первичный и внешний ключи таблицы. Столбец первичного ключа всегда является индексом, поэтому вам не нужно беспокоиться о производительности. Однако внешний ключ также должен иметь индекс.
Любые операторы JOIN, которые вы используете, должны иметь индекс для столбца. Если индекса нет, рассмотрите возможность добавления его в таблицу.
Заключение
Реляционная СУБД – это тип БД, который специализируется на связях (отношениях) между элементами данных. В большинстве реляционных БД используется структурированный язык запросов -— SQL (Structured Query Language) для создания и поддержки данных. При работе с реляционными базами данных необходимо правильно создавать и использовать операторы SQL, оптимизировать таблицы и запросы для достижения максимальной производительности.
Итак, самые распространенные ошибки при работе с СУБД:
- Забытые первичные ключи
- Присутствие избыточности данных
- Работа с операторами NOT IN или IN
- Забытые значения NULL и пустые строковые значения
- Символ звездочки в операторах SELECT
- Наличие цикла с слишком многими курсорами
- Несоответствие данных в процедурах назначения на местах
- Логические операции OR и AND
- Подзапросы должны возвращать одну запись
- JOIN к индексам