ГлавнаяРазноеSql или

Использовать SQL-представление или SQL-запрос? Sql или


sql - В чем разница между SQL, PL-SQL и T-SQL?

SQL

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

Подробнее Язык структурированных запросов - это специальный язык программирования, предназначенный для управления данными, хранящимися в системе управления реляционными базами данных (RDBMS), или для обработки потока в системе управления реляционными потоками данных (RDSMS).

Первоначально, основываясь на реляционной алгебре и реляционном исчислении кортежей, SQL состоит из языка определения данных и языка обработки данных. Объем SQL включает в себя вставку данных, запрос, обновление и удаление, создание и изменение схемы и контроль доступа к данным. Хотя SQL часто описывается как, и в значительной степени это декларативный язык (4GL), он также включает процедурные элементы.

PL/SQL

PL/SQL представляет собой комбинацию SQL наряду с процедурной характеристикой языков программирования. Она была разработана корпорацией Oracle

Особенности PL/SQL

  • полностью портативная высокопроизводительная обработка транзакций язык.
  • предоставляет встроенное интерпретируемое и независимое от ОС программирование окружающая среда.
  • напрямую вызывается из интерфейса командной строки SQL * Plus.
  • Прямой вызов также может быть сделан из внешних вызовов языка программирования к базе данных.
  • общий синтаксис основан на программировании ADA и Pascal язык.
  • Помимо Oracle, он доступен в базе данных TimesTen in-memory и IBM DB2.

T-SQL

Short для Transaction-SQL, расширенная форма SQL, которая добавляет объявленные переменные, управление транзакциями, обработку ошибок и обработки исключений и обработку строк в SQL

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

T-SQL добавляет ряд функций, недоступных в SQL.

Это включает в себя процедурные элементы программирования и локальную переменную, чтобы обеспечить более гибкое управление потоком приложения. В T-SQL был добавлен ряд функций, чтобы сделать его более мощным; функции для математических операций, строковых операций, обработки даты и времени и т.п. Эти дополнения делают T-SQL совместимым с тестом на полноту Turing, который определяет универсальность языка вычислений. SQL не является полным Turing и очень ограничен в рамках того, что он может сделать.

Еще одна существенная разница между T-SQL и SQL - это изменения, сделанные для команд DELETE и UPDATE, которые уже доступны в SQL. С помощью T-SQL команды DELETE и UPDATE позволяют включить предложение FROM, которое позволяет использовать JOIN. Это упрощает фильтрацию записей, чтобы легко выбирать записи, соответствующие определенным критериям, в отличие от SQL, где это может быть немного сложнее.

Выбор между T-SQL и SQL зависит от пользователя. Тем не менее, использование T-SQL по-прежнему лучше, когда вы имеете дело с установками Microsoft SQL Server. Это связано с тем, что T-SQL также принадлежит Microsoft, и использование двух вместе максимизирует совместимость. SQL предпочитают люди, у которых есть несколько бэкэндов.

Ссылки , Википедия , Учебные очки : Www.differencebetween.com

qaru.site

Разница между SQL и MySQL

Вы здесь: Главная - MySQL - MySQL Основы - Разница между SQL и MySQL

Прежде, чем приступить к статье, объяснющей разницу между SQL и MySQL, я поздравлю Вас с Новым годом, годом кролика. Желаю в Новом году Вам побольше удачи, побольше целеустремлённости и побольше упорства. Ведь главное в жизни - это достигать своих целей, а они достигаются только упорными людьми. Будьте упорны и настойчивы, и тогда в Новом году Вы будете победителем в любой сфере! А теперь вернёмся к делу.

Я достаточно часто встречаю вопрос: "Какая разница между SQL и MySQL", и я решил ответить на этот вопрос, несмотря на всю его абсурдность. Ведь с тем же успехом можно спросить: "Какая разница между сервером Apache и PHP", но это почему-то никто не спрашивает.

В общем, отвечаю на вопрос. SQL - это язык запросов для управления СУБД (система управления базами данных). А MySQL - это одна из таких СУБД. В частности, помимо MySQL существуют и другие СУБД: Oracle, MS SQL Server, PostgreSQL и много других. И чтобы работать (сделать выборку, вставить новую запись, добавить новую таблицу и так далее) с любой из этих СУБД необходим язык запросов, и таким языком и является SQL.

Резюме:

  • SQL - язык запросов для управления СУБД.
  • MySQL - это одна из множества других СУБД.

Надеюсь, я ответил на этот один из самых популярных вопросов среди новичков, которые только начинают заниматься базами данных. Хотя нет, Вы не новички, Вы молодцы! Как показывает практика, люди не двигаются дальше HTML и CSS (редко JavaScript). И если Вы решили заниматься базами данных, то Вы уже герой! Так что Вы не новички, а просто начинающие познавать действительно важные и, в общем-то, сложные вещи. Удачи Вам в этом!

Удачи и успеха в Новом году!

Ваш покорный слуга, Михаил Русаков!

  • Создано 31.12.2010 16:01:29
  • Михаил Русаков
Следующая статья

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

  1. Кнопка: <a href="https://myrusakov.ru" target="_blank"><img src="https://myrusakov.ru//images/button.gif" alt="Как создать свой сайт" /></a>

    Она выглядит вот так:

  2. Текстовая ссылка:<a href="https://myrusakov.ru" target="_blank">Как создать свой сайт</a>

    Она выглядит вот так: Как создать свой сайт

  3. BB-код ссылки для форумов (например, можете поставить её в подписи): [URL="https://myrusakov.ru"]Как создать свой сайт[/URL]

myrusakov.ru

SQL или NoSQL — вот в чём вопрос / Блог компании RUVDS.com / Хабрахабр

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

Реляционные БД хранят структурированные данные, которые обычно представляют объекты реального мира. Скажем, это могут быть сведения о человеке, или о содержимом корзины для товаров в магазине, сгруппированные в таблицах, формат которых задан на этапе проектирования хранилища.

Нереляционные БД устроены иначе. Например, документо-ориентированные базы хранят информацию в виде иерархических структур данных. Речь может идти об объектах с произвольным набором атрибутов. То, что в реляционной БД будет разбито на несколько взаимосвязанных таблиц, в нереляционной может храниться в виде целостной сущности.

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

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

О выборе SQL-баз данных

Не существует баз данных, которые подойдут абсолютно всем. Именно поэтому многие компании используют и реляционные, и нереляционные БД для решения различных задач. Хотя NoSQL-базы стали популярными благодаря быстродействию и хорошей масштабируемости, в некоторых ситуациях предпочтительными могут оказаться структурированные SQL-хранилища. Вот две причины, которые могут послужить поводом для выбора SQL-базы:
  1. Необходимость соответствия базы данных требованиям ACID (Atomicity, Consistency, Isolation, Durability — атомарность, непротиворечивость, изолированность, долговечность). Это позволяет уменьшить вероятность неожиданного поведения системы и обеспечить целостность базы данных. Достигается подобное путём жёсткого определения того, как именно транзакции взаимодействуют с базой данных. Это отличается от подхода, используемого в NoSQL-базах, которые ставят во главу угла гибкость и скорость, а не 100% целостность данных.
  2. Данные, с которыми вы работаете, структурированы, при этом структура не подвержена частым изменением. Если ваша организация не находится в стадии экспоненциального роста, вероятно, не найдётся убедительных причин использовать БД, которая позволяет достаточно вольно обращаться с типами данных и нацелена на обработку огромных объёмов информации.

О выборе NoSQL-баз данных

Если есть подозрения, что база данных может стать узким местом некоего проекта, основанного на работе с большими объёмами информации, стоит посмотреть в сторону NoSQL-баз, которые позволяют то, чего не умеют реляционные БД.

Вот возможности, которые стали причиной популярности таких NoSQL баз данных, как MongoDB, CouchDB, Cassandra, HBase:

  1. Хранение больших объёмов неструктурированной информации. База данных NoSQL не накладывает ограничений на типы хранимых данных. Более того, при необходимости в процессе работы можно добавлять новые типы данных.
  2. Использование облачных вычислений и хранилищ. Облачные хранилища — отличное решение, но они требуют, чтобы данные можно было легко распределить между несколькими серверами для обеспечения масштабирования. Использование, для тестирования и разработки, локального оборудования, а затем перенос системы в облако, где она и работает — это именно то, для чего созданы NoSQL базы данных.
  3. Быстрая разработка. Если вы разрабатываете систему, используя agile-методы, применение реляционной БД способно замедлить работу. NoSQL базы данных не нуждаются в том же объёме подготовительных действий, которые обычно нужны для реляционных баз.
В следующем разделе рассмотрим некоторые различия между технологиями SQL и NoSQL. А именно, сначала взглянем на простой пример, показывающий фундаментальное различие двух подходов к организации баз данных, потом поговорим о масштабируемости и индексации данных. А в итоге остановимся на примере большой CRM-системы, нуждающейся в высокой производительности хранилища данных.

SQL и NoSQL

Начнём с некоторых ключевых концепций реляционных и нереляционных баз данных. Ниже показана база данных, содержащая сведения о взаимоотношениях людей. Вариант a — это бессхемная структура, построенная в виде графа, характерная для NoSQL-решений. Вариант b показывает, как те же данные можно представить в структурированном виде, типичном для SQL.
Два варианта представления данных

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

var cars = [ { Model: "BMW", Color: "Red", Manufactured: 2016 }, { Model: "Mercedes", Type: "Coupe", Color: "Black", Manufactured: "1-1-2017" } ]; При реляционном подходе данные надо хранить в заранее спроектированной структуре, из которой эти данные потом можно извлекать. Например, используя оператор JOINпри выборке из двух таблиц:SELECT Orders.OrderID, Customers.Name, Orders.Date FROM Orders INNER JOIN Customers ON Orders.CustID = Customers.CustID Как более продвинутый пример, для демонстрации того, когда SQL предпочтительнее NoSQL, рассмотрим особенности применения в NoSQL-базах алгоритмов уплотнения. Проблема заключается в том, что в некоторых NoSQL-базах (например, в CouchDB и HBase) постоянно приходится формировать так называемые sstables — строковые таблицы в формате ключ-значение, отсортированные по ключу. В такие таблицы, которые сохраняются на диск, данные попадают из таблиц, хранящихся в памяти, при их переполнении и в других ситуациях. При интенсивной работе с базой создание таблиц, со временем, приводит к тому, что подсистема ввода-вывода устройства хранения данных становится узким местом для операций чтения данных. Как результат, чтение в NoSQL-базе происходит медленнее, чем запись, что сводит на нет одно из главных преимуществ нереляционных баз данных. Именно для того, чтобы уменьшить этот эффект, системы NoSQL используют, в фоновом режиме, алгоритмы уплотнения данных, пытаясь объединить множество таблиц в одну. Но и сама по себе эта операция весьма ресурсоёмка, система работает под повышенной нагрузкой.

Масштабируемость

Одно из основных различий рассматриваемых технологий заключается в том, что NoSQL-базы лучше поддаются масштабированию. Например, в MongoDB имеется встроенная поддержка репликации и шардинга (горизонтального разделения данных) для обеспечения масштабируемости. Хотя масштабирование поддерживается и в SQL-базах, это требует гораздо больших затрат человеческих и аппаратных ресурсов.
Тип хранилища данных Сценарий использования Пример Рекомендации
Хранилище типа ключ-значение Подходит для простых приложений, с одним типом объектов, в ситуациях, когда поиск объектов выполняют лишь по одному атрибуту. Интерактивное обновление домашней страницы пользователя в Facebook. Рекомендовано знакомство с технологией memcached. Если приходится искать объекты по нескольким атрибутам, рассмотрите вариант перехода к хранилищу, ориентированному на документы.
Хранилище, ориентированное на документы Подходит для хранения объектов различных типов. Транспортное приложение, оперирующее данными о водителях и автомобилях, работая с которым надо искать объекты по разным полям, например — имя или дата рождения водителя, номер прав, транспортное средство, которым он владеет. Подходит для приложений, в ходе работы с которыми допускается реализация принципа «согласованность в конечном счёте» с ограниченными атомарностью и изоляцией. Рекомендуется применять механизм кворумного чтения для обеспечения своевременной атомарной непротиворечивости.
Система хранения данных с расширяемыми записями Более высокая пропускная способность и лучшие возможности параллельной обработки данных ценой слегка более высокой сложности, нежели у хранилищ, ориентированных на документы. Приложения, похожие на eBay. Вертикальное и горизонтальное разделение данных для хранения информации клиентов. Для упрощения разделения данных используются HBase или Hypertable.
Масштабируемая RDBMS Использование семантики ACID освобождает программистов от необходимости работать на достаточно низком уровне, а именно, отвечать за блокировки и непротиворечивость данных, обрабатывать устаревшие данные, коллизии. Приложения, которым не требуются обновления или слияния данных, охватывающие множество узлов. Стоит обратить внимание на такие системы, как MySQL Cluster, VoltDB, Clustrix, ориентированные на улучшенное масштабирование.
Более подробное сравнение SQL и NoSQL можно найти в этом материале. Вот его основные положения. А именно, были проведены испытания трёх основных характеристик систем: параллельная обработка данных, работа с хранилищами информации, репликация данных. Возможности параллельной обработки оценивались путём анализа механизмов блокировки, управления параллельным доступом на основе многоверсионности, и ACID. Тестирование хранилищ охватывало и физические носители, и хранилища использующие оперативную память. Репликацию испытывали в синхронном и асинхронном режимах.

Используя данные, полученные в ходе испытаний, авторы делают выводы о том, что SQL-базы с возможностью кластеризации показали многообещающие результаты производительности в расчёте на один узел, и, кроме того, обладают способностью масштабируемости, что даёт системам RDBMS преимущество перед NoSQL за счёт полного соответствия принципам ACID.

Индексация

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

И в SQL, и в NoSQL-базах индексы служат одной и той же цели — ускорить и оптимизировать извлечение данных. Но то, как именно они работают — различается из-за разных архитектур баз данных и особенностей хранения информации в базе. В то время, как SQL-индексы представлены в виде B-деревьев, которые отражают иерархическую структуру реляционных данных, в NoSQL базах данных они указывают на документы, или на части документов, между которыми, в основном, нет никаких отношений. Вот подробный материал на эту тему.

CRM-системы

CRM-приложения — это один из лучших примеров систем, для которых характерны огромные объёмы ежедневно обрабатываемых данных и очень большое количество транзакций. Все разработчики таких приложений используют и SQL, и NoSQL базы данных. И, хотя большая часть данных транзакций всё ещё хранится в SQL-базах, применение находят общедоступные системы класса DBaaS (data-base-as-a-service, база данных как сервис), наподобие AWS DynamoDB и Azure DocumentDB, в результате, серьёзная нагрузка по обработке данных может быть перенесена в облачные NoSQL-базы.

В то время, как использование подобных служб освобождает разработчика от решения задач по обслуживанию хранилищ, это, кроме того, область, где NoSQL базы применяются для того, для чего они, в основном, и были созданы, например, для глубинного анализа данных. Объёмы информации, хранимой в огромных CRM-системах финансовых и телекоммуникационных компаний, было бы практически невозможно проанализировать, используя инструменты вроде SAS или R. Это потребовало бы огромных аппаратных ресурсов.

Главное преимущество таких систем — использование неструктурированных данных, похожих на документы. Такие данные могут подаваться на вход статистических моделей, которые дают компаниям возможность выполнять различные виды анализа. CRM-приложения, кроме того, являются весьма удачным примером, в котором две системы баз данных выступают не конкурентами, а существуют в гармонии, играя каждая свою роль в большой архитектуре управления данными.

Итоги

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

Вот признаки проектов, для которых идеально подойдут SQL-базы:

  • Имеются логические требования к данным, которые могут быть определены заранее.
  • Очень важна целостность данных.
  • Нужна основанная на устоявшихся стандартах, хорошо зарекомендовавшая себя технология, используя которую можно рассчитывать на большой опыт разработчиков и техническую поддержку.
А вот свойства проектов, для которых подойдёт что-то из сферы NoSQL:
  • Требования к данным нечёткие, неопределённые, или развивающиеся с развитием проекта.
  • Цель проекта может корректироваться со временем, при этом важна возможность немедленного начала разработки.
  • Одни из основных требований к базе данных — скорость обработки данных и масштабируемость.
В итоге хочется сказать, что в современном мире нет противостояния между реляционными и нереляционными базами данных. Вместо этого стоит говорить об их совместном использовании для решения задач, на которых та или иная технология показывает себя лучше всего. Кроме того, всё сильнее наблюдается интеграция этих технологий друг в друга. Например, Microsoft, Oracle и Teradata сейчас предлагают некоторые формы интеграции с Hadoop для подключения аналитических инструментов, основанных на SQL, к миру неструктурированных больших данных.

Уважаемые читатели, а вам приходилось выбирать системы управления базами данных для собственных проектов? Если да — поделитесь пожалуйста опытом, расскажите, что и почему вы в итоге выбрали.

habr.com

sql - Псевдонимы SQL-таблицы - хорошие или плохие?

Я единственный человек, который действительно их ненавидит?

Как правило, я не использую их, если только не должен. Мне просто очень нравится читать что-то вроде

select a.id, a.region, a.firstname, a.blah, b.yadda, b.huminahumina, c.crap from table toys as a inner join prices as b on a.blah = b.yadda inner join customers as c on c.crap = something else etc

Когда я читаю SQL, мне нравится точно знать, что я выбираю, когда я его читаю; псевдонимы на самом деле путают меня больше, потому что я должен прокручивать строки столбцов, прежде чем я на самом деле получаю имя таблицы, которое обычно представляет информацию о данных, которые нет в псевдониме. Возможно, это нормально, если вы сделали псевдонимы, но я часто читаю вопросы по StackOverflow с кодом, который, по-видимому, использует псевдонимы без уважительной причины. (Кроме того, иногда кто-то создает псевдоним в заявлении и просто не использует его. Почему?)

Я думаю, что псевдонимы таблиц используются так, потому что многие люди не склонны печатать. Впрочем, я не считаю это хорошим оправданием. Это оправдание - причина, по которой мы заканчиваем ужасное переименование имен, ужасные аббревиатуры функций, плохой код... Я бы нашел время, чтобы набрать полное имя. Тем не менее, я быстр, поэтому, возможно, это имеет какое-то отношение к этому. (Может быть, в будущем, когда у меня будет туннель с запястью, я передумаю свое мнение по псевдонимам: P) Я особенно ненавижу работать в псевдонимах таблицы в PHP-коде, где, я считаю, нет абсолютно никаких оснований для этого - вам нужно только ввести его один раз!

Я всегда использую разделители столбцов в своих операторах, но я не прошу набрать много, поэтому я с удовольствием наберу полное имя несколько раз. (Конечно, я действительно нарушаю вкладку базы данных MySQL.) Если это не ситуация, когда мне нужно использовать псевдоним (как описано в других ответах), я нахожу дополнительный слой абстракции громоздким и ненужным.

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

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

qaru.site

c# - Использовать SQL-представление или SQL-запрос?

Я бы создал VIEW по нескольким причинам.

A) Хорошо построенный вид имеет тенденцию работать быстрее, чем запрос, хотя при оптимизации запросов вы можете не заметить большой разницы.

B) Он сохраняет знание структуры базы данных в самой базе данных - добавление хорошего уровня абстракции (как побочная заметка, рассмотрите возможность использования хранимой процедуры, а не встроенного запроса - это также сохраняет знания базы данных в самой базе данных)

C) Если вам нужно внести структурные изменения в базу данных, вы можете сохранить представление согласованным, не перестраивая свой код.

ПОПРАВКА Я собираюсь изменить этот ответ в свете некоторых комментариев, чтобы уточнить некоторые моменты...

Абсолютно верно, что стандартное представление не обеспечивает реального прироста производительности по запросу. Стандартное представление материализуется во время выполнения, что существенно отличает его от удобного способа выполнения запроса той же структуры. Однако представление в индексе материализуется немедленно, и результаты сохраняются в физическом хранилище. Как и при любом дизайнерском решении, следует внимательно изучить использование индексированного представления. Нет бесплатного обеда; штраф, который вы платите за использование индексированных просмотров, возникает в виде дополнительных требований к хранению и накладных расходов, связанных с сохранением представления при наличии каких-либо изменений в базовой базе данных. Они лучше всего используются в случаях часто используемого сложного объединения и агрегирования данных из нескольких таблиц и в случаях, когда доступ к данным происходит гораздо чаще, чем он изменяется.

Я также согласен с комментариями относительно структурных изменений - добавление новых столбцов не повлияет на представление. Если, однако, данные перемещаются, нормализуются, архивируются и т.д., Это может быть хорошим способом изолировать такие изменения от приложения. Эти ситуации RARE, и одни и те же результаты могут быть достигнуты с помощью хранимых процедур, а не вида.

qaru.site

10 потенциальных SQL ошибок, которые делают программисты / Хабрахабр

Оригинал статьи носит название «10 SQL ошибок, которые делают Java разработчики», но, по большому счёту, приведённые в ней принципы можно отнести к любому языку.

Java программисты мешают объектно-ориентированное и императивное мышление в зависимости от их уровня: — мастерства (каждый может программировать императивно) — догмы (шаблон для применения шаблонов где-либо и их именование) — настроения (применять истинный объектный подход немного сложнее чем императивный)

Но всё меняется, когда Java разработчики пишут SQL код.SQL — это декларативный язык, который не имеет ничего общего с объектно-ориентированным или императивным мышлением. Очень легко выразить запрос в SQ, но довольно трудно выразить его корректно и оптимально. Разработчикам не только необходимо переосмыслить их парадигму программирования, им нужно ещё и думать в рамках теории множеств (set theory).

Ниже перечислены общие ошибки, которые делают Java разработчики, использующие SQL в JDBC или jOOQ (без определённого порядка). Для других 10 ошибок, смотрите эту статью.

1. Забыл о NULL
Непонимание NULL — это скорее всего самая большая ошибка, которую Java разработчик может сделать, когда пишет SQL. Это может быть потому, что NULL ещё называется UNKNOWN. Если бы он назывался просто UNKNOWN, его было бы проще понять. Другая причина в том, что при получении данных и связывании переменных JDBC отражает SQL NULL в Java null. Это может привести к тому, что NULL = NULL (SQL) будет вести себя так же, как и null == null (JAVA).

Один из самых ярких примеров заблуждения о NULL — это когда NULL предикаты используются со строковым выражением (row value expression).

Другая, более специфическая проблема появляется при отсутствии понимания значения NULL в NOT IN anti-joins.

Лекарство: Тренируй себя. Ничего сложного — во время написания SQL всегда думай о NULL: — Этот предикат корректен относительно NULL? — Влияет ли NULL на результат этой функции?

2. Обработка данных в памяти Java
Не многие Java программисты знают SQL очень хорошо. Случайный JOIN, странный UNION и ладно. А оконные функции? Группирующие наборы? Многие Java разработчики загружают SQL данные в память, трансформируют их в какую-нибудь подходящую коллекцию и выполняют нужные вычисления на этих коллекциях с многословными циклическими структурами (по-крайней мере до улучшения коллекций в JAVA 8).

Но некоторые SQL базы данных поддерживают дополнительные (SQL стандарт!) OLAP функции, которые подходят для этого лучше и являются более простыми в написании. Один из примеров (не стандарт) — это отличный оператор MODEL от Oracle. Просто позволь БД сделать обработку и вытащить результаты в память Java. Потому что, в конце концов, какой-то умный парень уже оптимизировал эти дорогие продукты. Итак, используя OLAP в БД, ты получаешь две вещи: — Простоту. Скорее всего, проще писать правильно на SQL, чем на Java. — Производительность. БД скорее всего будут быстрее чем твой алгоритм. И, что важнее, тебе не придётся тянуть миллионы записей по проводам.

Лекарство: Каждый раз когда ты пишешь ориентированный на данные алгоритм с помощью Java, спрашивай себя: «Есть ли возможность переложить эту работу на базу данных?»

3. Использование UNION вместо UNION ALL
Позор тому, что UNION ALL требует дополнительного слова относительно UNION. Было бы намного лучше, если бы SQL стандарт был определён поддерживать: — UNION (позволяет дублирование) — UNION DISTINCT (убирает дублирование)

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

Помни, что даже если SQL стандарт определяет INTERSECT ALL и EXCEPT ALL, не каждая БД может реализовывать эти мало используемые наборы операций.

Лекарство: Думай, хотел ли ты написать UNION ALL каждый раз, когда пишешь UNION.

4. Использование JDBC для постраничной разбивки большой выборки
Большинство БД поддерживают какие-то средства для постраничной разбивки через LIMIT… OFFSET, TOP… START AT, OFFSET… FETCH операторов. В отсутствии поддержки этих операторов всё ещё есть возможность наличия ROWNUM (Oracle) или ROW_NUMBER() OVER() фильтрации (DB2, SQL Server 2008 и другие), которые намного быстрее разбивки в памяти. Это относится преимущественно к большим смещениям!

Лекарство: Просто используйте эти операторы, или инструмент(такой, как jOOQ), который может имитировать эти операторы за вас.

5. Соединение данных в памяти Java
С ранних дней SQL и до сих пор некоторые Java программисты с тяжелым сердцем пишут JOINы. У них есть устаревший страх того, что JOINы выполняются медленно. Это может быть так, если оптимизатор накладных расходов выбирает сделать вложенный цикл, загружая целые таблицы в память перед созданием ячеек присоединённой таблицы. Но это случается редко. С нормальными предикатами, ограничениями, индексами, MERGE JOIN или HASH JOIN операции выполняются очень быстро — всё зависит от корректных метаданных (Tom Kyte хорошо написал об этом). Тем не менее, наверняка ещё остались немногие Java разработчики, которые загружают две таблицы двумя отдельными запросами и соединяют их в памяти Java тем или иным способом.

Лекарство: Если бы выбираете из разных таблиц на различных этапах, подумайте ещё раз, вдруг вы можете выразить ваши запросы одним.

6. Использование DISTINCT или UNION для удаления дубликатов из случайного декартова произведения
Из-за сложных соединений (JOIN) любой разработчик может потерять след в значащих связях SQL запроса. Если конкретнее, то при использовании связи с составными внешними ключами можно забыть добавить значащие предикаты в JOIN… ON утверждения. Это может привести к дублированию строк всегда или только в исключительных ситуациях. Тогда некоторые разработчики могут добавить оператор DISTINCT для прекращения дублирования данных. Это не правильно по трём причинам: — Это может излечить последствия, но не причину. А ещё это может не решить последствия при граничных условиях. — Это медленно для больших выборок. DISTINCT выполняет ORDER BY операцию для удаления дублирования. — Это медленно для больших декартовых произведений которые всё равно будут загружены в память.

Лекарство: Как правило, если Вы получаете нежелательные дубликаты, пересмотрите свои JOIN предикаты. Вероятно там где-то образовалось небольшое декартово произведение.

7. Избегание оператора MERGE
На самом деле это не ошибка, но, возможно, это отсутствие знаний или страхи мощного оператора MERGE. Некоторые БД знают другие формы UPSERT оператора, например MySQL ON DUPLICATE KEY UPDATE. На самом деле MERGE очень мощен, особенно в БД, которые сильно расширяют SQL стандарт, таких как SQL Server.

Лекарство: Если Вы делаете UPSERT, выстраивая цепочку из INSERT и UPDATE или SELECT… FOR UPDATE и INSERT/UPDATE, задумайтесь ещё раз. Вместо риска гонки за ресурсами, вы можете написать более простое MERGE запрос.

8. Использование агрегатных функций вместо оконных функций
Перед появлением оконных функций, единственным средством для агрегации данных в SQL было использование GROUP BY вместе с агрегатными функциями в проекции. Это хорошо работает в большинстве случаев, и если агрегированные данные должны быть наполнены обычными данными, то сгруппированный запрос может быть написан в присоединённом под запросе. Но SQL:2003 определяет оконные функции, которые реализованы многими поставщиками БД. Оконные функции могут агрегировать данные на не группированных выборках. По факту, каждая оконная функция поддерживает свою собственную, независимую PARTITION BY операцию, которая является отличным инструментом для построения отчётов.

Использование оконных функций позволит: — Построить более читаемый SQL (меньше выделенных GROUP BY выражений в под запросах) — Улучшить производительность т.к. RDBMS может легче оптимизировать оконные функции

Лекарство: Когда вы пишите GROUP BY выражение в под запросе, задумайтесь, может ли он быть выражен оконной функцией?

9. Использование сортировки в памяти при разных параметрах
Оператор ORDER BY поддерживает множество типов выражений, включая CASE, который может быть очень полезен при определении параметра сортировки. Вам никогда не следует сортировать данные в памяти Java только потому, что: — SQL сортировка слишком медленная. — SQL сортировка не может сделать этого.

Лекарство: Если вы сортируете какие-либо SQL данные в памяти Java, задумайтесь, возможно ли перенести эту сортировку в БД? Это отлично сочетается со страничной разбивкой в БД.

10. Поочерёдная вставка множества записей
JDBC знает, что такое пакет (batch), и Вам следует использовать это. Не делайте INSERT тысяч записей одной за другой, создавая новый PreparedStatement каждый раз. Если все ваши записи идут в одну таблицу, создайте партию INSERT запросов с одним SQL запросом и несколькими связываемыми наборами данных. В зависимости от вашей БД и её конфигурации, что бы сохранить UNDO лог чистым, Вам может потребоваться делать commit спустя какое-то количество вставленных записей.

Лекарство: Всегда используйте пакетную вставку больших наборов данных.

Несколько интересных книг на тему
— SQL Antipatterns by Bill Karwin — SQL Performance Explained by Markus Winand

habr.com