Виды JOIN в SQL
В SQL-джойнах скрыто больше, чем можно подумать. Давайте разберем их.
Будем использовать две простые таблицы: компании companies и их вакансии jobs .
Есть три вымышленные компании — Hoogle, Emazon и Neta — которые предлагают на удивление мало вакансий:
jobs companies ┌────────┬─────────┬──────────────┐ ┌─────────┬───────────┐ │ job_id │ comp_id │ job_name │ │ comp_id │ comp_name │ ├────────┼─────────┼──────────────┤ ├─────────┼───────────┤ │ 1 │ 10 │ Data Analyst │ │ 10 │ Hoogle │ │ 2 │ 20 │ Go Developer │ │ 20 │ Emazon │ │ 3 │ 20 │ ML Engineer │ │ 30 │ Neta │ │ 4 │ 99 │ UI Designer │ └─────────┴───────────┘ └────────┴─────────┴──────────────┘
(свайпайте влево, чтобы увидеть компании)
Hoogle интересуется аналитиками данных. Emazon нанимает Go-разработчиков и ML-инженеров. У Neta нет вакансий. А какая-то ноунейм-компания с идентификатором 99 отчаянно разыскивает UI-дизайнера.
- Квалифицированный JOIN
- Естественный JOIN
- Перекрестный JOIN
- Секционированный JOIN
- Латеральный JOIN
- Итого
Квалифицированный JOIN
Квалифицированный джойн (qualified join) — это общий термин, которым обозначают всем известные типы джойнов: inner , left , right и full . Если вы про них не слышали или подзабыли — посмотрите SQL-шпаргалку.
Квалифицированный джойн соединяет два набора данных в один по заданным правилам. Вот как он выглядит в общем случае:
table [join-type] JOIN table join-specification
Таблица ( table ) — не обязательно прямо вот таблица. Это может быть представление, подзапрос или любая табличная структура данных. Но для краткости будем называть ее таблицей.
Тип джойна ( join-type ) может быть таким:
- inner включает только совпадающие записи из обеих таблиц.
- left включает совпадающие записи из обеих таблиц и несовпадающие из левой таблицы.
- right включает совпадающие записи из обеих таблиц и несовпадающие из правой таблицы.
- full включает совпадающие и несовпадающие записи из обеих таблиц.
Для left , right и full можно использовать необязательное слово outer , которое ничего не меняет (как будто SQL недостаточно сложный):
LEFT OUTER = LEFT RIGHT OUTER = RIGHT FULL OUTER = FULL
Да и вообще join-type можно не писать. По умолчанию джойн считается внутренним ( inner ).
Спецификация джойна ( join-specification ) задает правила соответствия между таблицами. Она бывает двух сортов.

Первый вариант использует ключевое слово on , которое вы наверняка не раз встречали. Например, выберем вакансии вместе с соответствующими названиями компаний:
select job_name, comp_name from jobs join companies on jobs.comp_id = companies.comp_id;
Второй вариант более редкий. Он использует ключевое слово using и работает, только если целевой столбец в обеих таблицах называется одинаково:
select job_name, comp_name from jobs join companies using(comp_id);
С on можно использовать любые условия, а using проверяет только на равенство.
Естественный JOIN
Естественный джойн (natural join) — это как квалифицированный через using , только мы вообще не указываем столбцы, по которым соединяются таблицы:
select job_name, comp_name from jobs natural join companies;
Естественный джойн находит все пары столбцов с одинаковыми названиями и использует их для соединения.
Аналогично using , естественный джойн проверяет на равенство. Аналогично квалифицированному джойну, он может быть внутренним ( inner , по умолчанию) или внешним ( left , right или full ):
table NATURAL [join-type] JOIN table

Использовать естественный джойн — сомнительная идея. Допустим, у нас есть столбец name в обеих таблицах:
create table jobs ( job_id integer primary key, comp_id integer, name text ); create table if not exists companies ( comp_id integer primary key, name text );
Вполне нормальная структура. Но естественный джойн между jobs и companies вернет пустой результат, потому что неявно сравнивает по такому условию:
jobs.comp_id = companies.comp_id and jobs.name = companies.name
Так что лично я без раздумий выбираю using вместо естественного соединения.
Перекрестный JOIN
Третья и последняя разновидность — перекрестный джойн (cross join), также известный как «декартово соединение» (Cartesian join):
select job_name, comp_name from jobs cross join companies;
Перекрестный джойн игнорирует значения столбцов. Он берет каждую строку из левой таблицы (N строк) и соединяет с каждой строкой из правой таблицы (M строк), выдавая в результате N×M строк.

Перекрестный джойн полезен, чтобы получить все пары значений из двух таблиц. Например, комбинации «цвет-размер» по всем продуктам. В нашем примере с вакансиями толку от него немного.
Перекрестный джойн — то же самое, что внутренний джойн ( inner join , он же просто join ) без критерия совпадения:
select job_name, comp_name from jobs join companies on true;
Иногда перекрестный джойн записывают так:
select job_name, comp_name from jobs, companies;
Хотя в запрос вообще отсутствует слово join , это все то же самое перекрестное соединение.
Секционированный JOIN
Не я ли чуть выше говорил, что существует всего три вида джойнов — квалифицированный, естественный и перекрестный? Ну да.
Но тут вот какая штука. Помните определение квалифицированного джойна?
table [join-type] JOIN table join-specification
Согласно стандарту SQL, вместо table здесь можно использовать секционированную джойн-таблицу (partitioned join table):
select . from table_x partition by (col_1, col_2, . ) join table_y on . ;
Допустим у нас есть таблица продуктов ( products ) и продаж ( sales ) по дням:
sales products ┌────┬────────────┬────────────┬──────────┐ ┌────┬───────┐ │ id │ sale_dt │ product_id │ quantity │ │ id │ name │ ├────┼────────────┼────────────┼──────────┤ ├────┼───────┤ │ 1 │ 2023-06-01 │ 10 │ 30 │ │ 10 │ Alpha │ │ 2 │ 2023-06-01 │ 20 │ 60 │ │ 20 │ Beta │ │ 3 │ 2023-06-01 │ 30 │ 90 │ │ 30 │ Gamma │ │ 4 │ 2023-06-02 │ 20 │ 60 │ └────┴───────┘ │ 5 │ 2023-06-03 │ 10 │ 30 │ │ 6 │ 2023-06-03 │ 30 │ 90 │ └────┴────────────┴────────────┴──────────┘
(свайпайте влево, чтобы увидеть продукты)
Выберем продажи с соответствующими названиями продуктов:
select sale_dt, products.name, quantity from sales join products on sales.product_id = products.id order by sale_dt;
Пока все просто. Но что если я хочу увидеть продажи каждого продукта за каждый день? Включая дни, в которые не было продаж отдельных продуктов:
┌────────────┬───────┬──────────┐ │ sale_dt │ name │ quantity │ ├────────────┼───────┼──────────┤ │ 2023-06-01 │ Alpha │ 30 │ │ 2023-06-01 │ Beta │ 60 │ │ 2023-06-01 │ Gamma │ 90 │ │ 2023-06-02 │ Alpha │ 0 │ │ 2023-06-02 │ Beta │ 60 │ │ 2023-06-02 │ Gamma │ 0 │ │ 2023-06-03 │ Alpha │ 30 │ │ 2023-06-03 │ Beta │ 0 │ │ 2023-06-03 │ Gamma │ 90 │ └────────────┴───────┴──────────┘
Эту задачу никак не решить без дополнительных ухищрений. Разве что использовать секционированный джойн (partitioned join).

Секционированный джойн говорит движку СУБД выполнять соединение отдельно по каждой секции, которую мы задали для таблицы. Поэтому, если мы определим секции продаж по дате:
select sale_dt, name, quantity from sales partition by (sale_dt) right join products on sales.product_id = products.id order by sale_dt, name;
То движок независимо соединит продажи за 01.06 со всеми продуктами, затем продажи за 02.06 со всеми продуктами, затем продажи за 03.06 со всеми продуктами, и наконец объединит промежуточные результаты. В результате получим искомый набор данных (разве что вместо 0 здесь null ):
┌────────────┬───────┬──────────┐ │ sale_dt │ name │ quantity │ ├────────────┼───────┼──────────┤ │ 2023-06-01 │ Alpha │ 30 │ │ 2023-06-01 │ Beta │ 60 │ │ 2023-06-01 │ Gamma │ 90 │ │ 2023-06-02 │ Alpha │ (null) │ │ 2023-06-02 │ Beta │ 60 │ │ 2023-06-02 │ Gamma │ (null) │ │ 2023-06-03 │ Alpha │ 30 │ │ 2023-06-03 │ Beta │ (null) │ │ 2023-06-03 │ Gamma │ 90 │ └────────────┴───────┴──────────┘
Надо сказать, что странноватая фича. Я удивлен, что она вообще вошла в стандарт (подозрительно связано с тем, что она реализована в Oracle). Другие производители СУБД так никогда и не реализовали секционированный джойн. Не могу их за это осуждать.
В любом случае, теперь и вы знаете о существовании этого джойна. Не нести же мне бремя бесполезных SQL-знаний одному.
Если вам интересно, как решить задачу без секционированного джойна (знаю, что нет), то вот:
-- выбираем все даты with dates as ( select distinct sale_dt from sales ) -- перекрестный джойн дат с продуктами -- дает все пары «дата-продукт», -- а их уже соединяем с продажами select dates.sale_dt, name, quantity from dates cross join products left join sales on sales.sale_dt = dates.sale_dt and sales.product_id = products.id order by dates.sale_dt, name;
Латеральный JOIN
SQL — странная штука. Стандарт одновременно включает и секционированный джойн (который никто кроме Oracle не поддержал), и намного более мощную и распространенную разновидность — латеральный (lateral) джойн.
Латеральное соединение, в противоположность обычному, разрешает коррелированные подзапросы. Сейчас разберемся, что это.
Вернемся к примеру с продуктами и продажами:
sales products ┌────┬────────────┬────────────┬──────────┐ ┌────┬───────┐ │ id │ sale_dt │ product_id │ quantity │ │ id │ name │ ├────┼────────────┼────────────┼──────────┤ ├────┼───────┤ │ 1 │ 2023-06-01 │ 10 │ 30 │ │ 10 │ Alpha │ │ 2 │ 2023-06-01 │ 20 │ 60 │ │ 20 │ Beta │ │ 3 │ 2023-06-01 │ 30 │ 90 │ │ 30 │ Gamma │ │ 4 │ 2023-06-02 │ 20 │ 60 │ └────┴───────┘ │ 5 │ 2023-06-03 │ 10 │ 30 │ │ 6 │ 2023-06-03 │ 30 │ 90 │ └────┴────────────┴────────────┴──────────┘
(свайпайте влево, чтобы увидеть продукты)
Посмотрим, как каждый продукт продавался 2 июня:
select '2023-06-02' as sale_dt, name, sales.quantity from products left join sales on products.id = sales.product_id and sales.sale_dt = '2023-06-02';
А теперь посмотрим продажи каждого продукта за каждый день (как делали в примере с секционированным джойном). Было бы здорово выбрать даты отдельным подзапросом и соединить с подзапросом по конкретной дате из примера выше:

select d.sale_dt, ps.name, ps.quantity from (select distinct sale_dt from sales) as d join ( select d.sale_dt, name, sales.quantity from products left join sales on products.id = sales.product_id and sales.sale_dt = d.sale_dt ) as ps on true order by sale_dt, name;
Но нет. Нельзя использовать столбец sale_dt из подзапроса d в следующем за ним подзапросе ps . А вот если использовать латеральный джойн — можно:
select d.sale_dt, ps.name, ps.quantity from (select distinct sale_dt from sales) as d join lateral ( select d.sale_dt, name, sales.quantity from products left join sales on products.id = sales.product_id and sales.sale_dt = d.sale_dt ) as ps on true order by sale_dt, name;
Подзапрос d выбирает даты, а подзапрос ps соединяется с ним по столбцу sale_dt . Тем самым ps выбирает продажи каждого продукта для каждой конкретной даты. Все благодаря латеральному джойну. Удобно!
Может возникнут вопрос насчет условия on true . Дело в том, что фактически джойн по sale_dt уже произошел внутри подзапроса ps , поэтому повторять его снаружи не требуется. Можете поменять true на d.sale_dt = ps.sale_dt и убедиться, что ничего не изменилось.
Латеральные соединения поддерживаются в PostgreSQL, MySQL и Oracle. MS SQL Server не поддерживает синтаксис lateral , но предоставляет аналогичную функциональность с собственным синтаксисом cross apply (= join lateral ) и outer apply (= left join lateral ).
Итого
Стандарт SQL описывает три варианта JOIN:
- квалифицированный (соединение по указанным критериям);
- естественный (автоматически выбирает критерии);
- перекрестный (внутреннее соединение без критериев).

Квалифицированный джойн предусматривает четыре типа: inner , left , right и full .

Он разрешает задать критерии соединения через on или using .

Большинство производителей СУБД поддерживают все виды JOIN. Заметное исключение — MS SQL Server, который знать не знает о using и естественных джойнах.
Есть еще модификаторы, которые изменяют поведение джойна:
- lateral разрешает коррелированные подзапросы в join -части запроса. Поддерживается в PostgreSQL, MySQL и Oracle (и MS SQL Server с другим синтаксисом).
- partition by производит независимое соединение по каждой из заданных секций. Поддерживается только в Oracle.
И еще MySQL не поддерживает full -джойны. Просто чтобы жизнь сахаром не казалась.
P.S. Хотите освоить современный SQL? Обратите внимание на Оконные функции
Подписывайтесь на твитер, чтобы не пропустить новые заметки
Оператор JOIN в SQL
Оператор JOIN объединяет две таблицы на основе общего столбца и выбирает записи с совпадающими значениями в этих столбцах. Например:
SELECT Customers . customer_id , Customers . first_name , Orders . amount
FROM Customers
JOIN Orders
ON Customers . customer_id = Orders . customer ;
Вот как работает этот код:

Здесь мы выбираем столбцы customer_id и first_name (из таблицы Customers) и столбец amount (из таблицы Orders). В результате получаем те строки, в которых есть совпадение между customer_id (таблицы Customers) и customer (таблицы Orders).
Типы JOIN в SQL
Команда JOIN , которую мы выполнили выше, называется INNER JOIN . Существует 4 типа оператора JOIN :
Оператор JOIN и псевдонимы в SQL
Мы можем использовать псевдонимы (оператор AS) с именами таблиц, чтобы сделать код короче и чище. Например:
SQL JOIN
Предложение JOIN используется для объединения строк из двух или более таблиц на основе связанного столбца между ними.
Давайте рассмотрим выборку из таблицы «Orders»:
| OrderID | CustomerID | OrderDate |
|---|---|---|
| 10308 | 2 | 1996-09-18 |
| 10309 | 37 | 1996-09-19 |
| 10310 | 77 | 1996-09-20 |
Затем посмотрите на выборку из таблицы «Customers»:
| CustomerID | CustomerName | ContactName | Country |
|---|---|---|---|
| 1 | Alfreds Futterkiste | Maria Anders | Germany |
| 2 | Ana Trujillo Emparedados y helados | Ana Trujillo | Mexico |
| 3 | Antonio Moreno Taquería | Antonio Moreno | Mexico |
Обратите внимание, что столбец «CustomerID» в таблице «Orders» ссылается на «CustomerID» в таблице «Customers». Связь между двумя приведенными выше таблицами представляет собой столбец «CustomerID».
Затем мы можем создать следующий заявление SQL (содержащий внутреннее соединение), который выбирает записи, имеющие совпадающие значения в обеих таблицах:
Пример
SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
INNER JOIN Customers ON Orders.CustomerID=Customers.CustomerID;
и он будет производить что-то вроде этого:
| OrderID | CustomerName | OrderDate |
|---|---|---|
| 10308 | Ana Trujillo Emparedados y helados | 9/18/1996 |
| 10365 | Antonio Moreno Taquería | 11/27/1996 |
| 10383 | Around the Horn | 12/16/1996 |
| 10355 | Around the Horn | 11/15/1996 |
| 10278 | Berglunds snabbköp | 8/12/1996 |
Различные типы соединений SQL
Вот различные типы соединений в SQL:
- (INNER) JOIN: Возвращает записи, имеющие совпадающие значения в обеих таблицах
- LEFT (OUTER) JOIN: Возвращает все записи из левой таблицы и совпадающие записи из правой таблицы
- RIGHT (OUTER) JOIN: Возвращает все записи из правой таблицы и совпадающие записи из левой таблицы
- FULL (OUTER) JOIN: Возвращает все записи при наличии совпадения в левой или правой таблице
Мы только что запустили
SchoolsW3 видео
курс сегодня!
Сообщить об ошибке
Если вы хотите сообщить об ошибке или внести предложение, не стесняйтесь отправлять на электронное письмо:
Ваше предложение:
Спасибо Вам за то, что помогаете!
Ваше сообщение было отправлено в SchoolsW3.
Schoolsw3 оптимизирован для бесплатного обучения, проверки и подготовки знаний. Примеры в редакторе упрощают и улучшают чтение и базовое понимание. Учебники, ссылки, примеры постоянно пересматриваются, чтобы избежать ошибок, но не возможно гарантировать полную правильность всего содержания. Некоторые страницы сайта могут быть не переведены на РУССКИЙ язык, можно отправить страницу как ошибку, так же можете самостоятельно заняться переводом. Используя данный сайт, вы соглашаетесь прочитать и принять Условия к использованию, Cookies и политика конфиденциальности.
Как работает SQL Join: описание, методы, примеры

Поговорим о том, как работает Join в SQL-базах данных. Для чего нужна эта директива, какие возможности она открывает и как правильно ее использовать.
Что такое SQL Join?
SQL Join – одна из наиболее часто используемых команд в SQL-синтаксисе. Она используется для поиска информации в базах данных по заранее определенным критериям. В частности, Join отвечает за объединение нескольких групп данных в единый поток информации.
И это действительно необходимо, потому что в 100% случаев контент в реляционных базах данных с поддержкой SQL-синтаксиса делится на множество таблиц, фильтровать данные в которых можно с помощью специальных команд и запросом информации из общего пула таблиц.
SQL Join помогает настроить фильтр поиска в базе данных, опираясь на взаимосвязи между различными элементами БД и их отличительные черты (теги, ID, наименования и т.п.).
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
SQL Inner Join
Этот режим объединения результатов поиска в базах данных SQL включается автоматически. Если вы не укажете намеренно тип Join, то сработает именно Inner Join. С помощью него можно указать сразу два критерия (две таблицы) и по ним отсеять контент.
Достаточно прописать SQL-запрос в духе:
SELECT * FROM table-1 JOIN table-2 ON table-1.parameter=table-2.parameter WHERE table-1.parameter IS ‘myData’
Фактически мы пытаемся выудить данные из первой таблицы и объединить их с данными из второй таблицы, при этом фильтруя только те записи, в которых совпадает значение параметра. В первой таблице оно приравнивается к myData.
На практике это может использоваться на сайте с музыкальными инструментами, например. Можно запрашивать гитары конкретного бренда, при этом еще и выбирая дополнительное условие в духе количества струн.
SELECT * FROM SevenStringGuitars JOIN Ibanez ON SevenStringGuitar.brandId=Ibanez.brandId
Таким SQL-запросом мы можем отфильтровать все инструменты бренда Ibanez в категории «Гитары» с 7 струнами.
SQL Self Join
Запросы Self Join полезны в тех случаях, когда необходимо выполнить фильтрацию контента внутри одной таблицы. Например, у вас есть список товаров в базе данных. У каждого из них указан свой бренд, но есть и те, что поставляются одним производителем. Self Join можно использовать для объединения двух стеков информации из одной таблицы.
Например, можно запросить информацию о наименовании товара и параллельно обратиться к базе с названием бренда. Результатом работы функции станет появление нового списка товаров, соответствующего критериям.
SQL-команда в этом случае может выглядеть следующим образом:
SELECT * FROM products JOIN products ON table.product=table.brand
Такой сценарий полезен практически в любом виде баз данных, так как в одной таблице нередко может храниться информация о товарах или контенте, имеющим большое количество общих параметров.
SQL Cross Join
Самый специфичный вариант фильтрации данных. Он подразумевает сбор сразу всех комбинаций элементов из нескольких таблиц, без обращения к какой-либо дополнительной информации (не требуется указывать id или любую другую строку в таблице).
Стандартный SQL-запрос с Cross Join может выглядеть следующим образом:
SELECT * FROM table-1 CROSS JOIN table-2
Этого достаточно, чтобы создать новый список элементов, в котором будут собраны все строки из базы данных, отфильтрованные только по выбранным таблицам.
Полученный набор данных называют декартовым произведением. Схематично его часто изображают как большое количество перекрестий между двумя группами элементов.
Такой вид JOIN применяется в онлайн-магазинах для вывода всех возможных пар по выбранным характеристикам одежды (цвету и размеру или другим параметрам).
SQL Outer Join
Outer Join – это своего рода противоположность Inner Join. Как понятно из названия, Outer Join предоставляет информацию не только из внутренней части поиска, но и из внешней. То есть программа ищет не только точечные совпадения по выбранным ранее критериям, а позволяет немного ослабить «хватку» и предоставить более «свободные» результаты поиска, включающие в себя элементы из таблиц, которые хоть и совпадают с критериями в SQL-запросе, но не полностью.
Когда такой подход может понадобиться? Например, для скрупулезной фильтрации товаров. Если вы готовы покупать продукцию компании «Шестерочка» и не против, если среди нее окажется молоко, но при этом вы точно не хотите покупать молоко других производителей, то вам подойдет подобный фильтр. Он позволяет дать одному из критериев поиска что-то в духе привилегий.
Разновидности Outer Join
Внешние Join-запросы существуют не в единственном виде, а сразу в трех вариациях. Каждый вариант по-своему обрабатывает информацию и в итоге выдает разные результаты.
Left
Левое объединение подразумевает как раз выше описанный сценарий. Когда мы берем одну таблицу, подключаем вторую и при этом показываем не только точные совпадения, но еще и весь список строк, полученных из левой таблицы, для которых не нашлось пары в правой таблице.
На практике это может выглядеть так:
SELECT * FROM table1 LEFT JOIN table2 ON table1.parameter=table2.parameter
Теперь мы объединяем первую и вторую таблицу, доставая информацию как о совпадениях по заданным параметрам, так и по контенту без пары в левой таблице.
При желании, надстраивая подобный фильтр, можно вовсе исключить целую категорию строк:
SELECT * FROM table1 LEFT JOIN table2 ON table1.parameter=table2.parameter WHERE table2.parameter IS NULL
На живом примере фильтрация такого рода может выглядеть так:
SELECT * FROM Russian LEFT JOIN Rap ON Russian.genreId=Rap.genreId
Представим, что мы запустили продвинутый поиск на сайте с музыкальными альбомами. Мы хотим послушать что-то на русском языке. Причем готовы даже оценить качество отечественного рэпа. При этом в целом мы рэп не любим и не хотим, чтобы он попадался на каких-то других языках.
Right
Понятно, что правое объединение будет работать в обратную сторону и покажет элементы из правой таблицы, для которых не нашлось пары в левой.
Получится следующий SQL-запрос:
SELECT * FROM table1 RIGHT JOIN table2 ON table1.parameter=table2.parameter
Если взять пример из предыдущей главы, то в реальности можно обернуть ситуацию в противоположную сторону. Искать только рэп-музыку, исключив все русское, кроме хип-хопа. Получится что-то в духе:
SELECT * FROM Russian RIGHT JOIN Rap ON Russian.genreId=Rap.genreId
Full
Это вариант для тех, кто хочет использовать сразу два разных критерия для поиска какого-либо контента. Снова вернемся к примеру с музыкальным приложением. Join Full может пригодиться, если вы хотите послушать либо что-то на русском, либо любой рэп. Вам не важны какие-либо другие параметры. Вас волнуют исключительно две характеристики. При этом вам не так важно, будут ли они пересекаться. То есть вам все равно, будет рэп на русском или же на русском будет какой-то агрессивный металл.
![]()
SQL-запрос с таким Join мог бы выглядеть следующим образом:
SELECT * FROM table1 FULL OUTER JOIN table2 ON table1.parameter=table2.parameter
Можно исключить из результатов фильтрации все пары. То есть можно выбрать только рэп, но ни в коем случае не русский, и русскую музыку, но ни в коем случае не рэп (вполне могу понять такой выбор, кстати говоря).
Чтобы это сделать, необходимо написать следующий SQL-запрос.
SELECT * FROM Russian FULL OUTER JOIN Rap ON Russian.genreId=Rap.genreId WHERE Russian.genreId IS NULL OR Rap.genreId IS NULL
Теперь вы увидите в результатах поиска только непарные строки.
Вместо заключения
SQL Join – мощнейший инструмент для фильтрации строк в базах данных. Благодаря ему можно легко находить именно ту информацию, что нужна, а не возиться с недоделанными фильтрами, которые обычно предоставляют разработчики сайтов и приложений. Жаль, что такие мощные механизмы поиска доступны далеко не везде. Но, создавая собственные продукты, вы можете их реализовать. Power-пользователи точно останутся довольны.
