Операция присоединения к вложенному запросу в СУБД

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

Для получения информации из нескольких таблиц нам необходимо извлечь выбранные данные из разных записей, используя операции, называемые объединением (внутреннее соединение, внешнее соединение и, что наиболее важно, естественное соединение). Рассмотрим 2 схемы таблиц сотрудников (имя сотрудника, улица, город) с n строками и работы (имя сотрудника, имя филиала, зарплата) с m строками. Декартово произведение этих двух таблиц создает таблицу с n * m строками. Естественное соединение выбирает из этих n * m строк все строки с одинаковыми значениями для employee_name. Чтобы избежать потери информации (некоторые кортежи в employee не имеют соответствующих кортежей в работе), мы используем левое внешнее соединение или правое внешнее соединение.

Соединение или вложенный запрос лучше при соблюдении условий:

• Предположим, что наши 2 таблицы хранятся в локальной системе. Выполнение соединения или вложенного запроса мало что изменит. Теперь позвольте таблицам храниться в распределенных базах данных. Для вложенного запроса мы извлекаем только релевантную информацию из каждой таблицы, расположенной на разных компьютерах, а затем объединяем полученные кортежи для получения результата. Для соединения нам потребуется получить всю таблицу с каждого сайта и создать большую таблицу, из которой будет выполняться фильтрация, следовательно, потребуется больше времени. Так что для распределенных баз данных лучше использовать вложенные запросы.

• Оптимизатор РСУБД заботится о производительности, связанной с подзапросом или соединением, написанным программистом. Объединения понятны всем, поэтому проблем с оптимизацией возникнуть не может. Если требуется переносимость между несколькими платформами, избегайте подзапросов, поскольку они могут столкнуться с ошибками (SQL-сервер более приспособлен к объединениям, поскольку он обычно используется с графическими редакторами запросов Microsoft, которые используют объединения).

• Конкретная реализация: предположим, что у нас есть запросы, в которых несколько вложенных запросов являются постоянными. В MySQL каждый константный подзапрос будет оцениваться столько раз, сколько встречается, при отсутствии возможности кэширования. Это очевидная проблема, если подзапрос констант включает большие кортежи. Подзапросы возвращают набор данных. Объединения возвращают набор данных, который обязательно проиндексирован. Работа с индексированными данными выполняется быстрее, поэтому, если набор данных, возвращаемый подзапросами, велик, соединения - лучшая идея.

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

Ссылка - операция соединения по сравнению с вложенным запросом

Вниманию читателя! Не прекращайте учиться сейчас. Освойте все важные концепции DSA с помощью самостоятельного курса DSA по приемлемой для студентов цене и будьте готовы к работе в отрасли. Чтобы завершить подготовку от изучения языка к DS Algo и многому другому, см. Полный курс подготовки к собеседованию . Если вы готовы, проверьте свои навыки с помощью серий тестов TCS, Wipro, Amazon и Microsoft.