Гибкий поиск — от нуля до героя
Часть 1
Если вы попали на эту статью, скорее всего, вы недавно начали работать с гибким поиском и хотите узнать, как максимально эффективно использовать этот инструмент. Я поделюсь знаниями, которые накопила за время работы с ним.
И даже если вы опытный разработчик с опытом работы с этим замечательным инструментом, я надеюсь, что вы также найдете несколько маленьких золотых самородков, которые сделают вашу жизнь проще. Или освойте новый навык, чтобы совмещать работу в качестве мастера гибкого поиска. Ладно, приступим.
Во-первых, что такое гибкий поиск? Вкратце: это встроенный язык запросов на основе синтаксиса SQL, который поставляется вместе с Hybris. Это звучит как горстка, но что это на самом деле означает? И, что более важно, как он работает?
Краткая версия: это язык запросов, основанный на SQL. Его цель — повысить надежность, дать пользователям больше возможностей при работе с базой данных. Процесс разбит на две фазы:
- Hybris преобразует гибкий поисковый запрос в SQL-запрос.
- Hybris выполняет SQL-запрос.
Глава 1: Основы
1. ВЫБЕРИТЕ
Начнем с самого начала, простого выбора из определенной таблицы. Принцип работы Flexible Search аналогичен SQL. Структура:
SELECT {column1}, {column2} FROM {table}
Как видите, он выглядит так же, как и обычный оператор SQL, за одним исключением: фигурные скобки. Вам нужно использовать их вокруг каждого столбца и таблицы. Вы также можете использовать *, чтобы выбрать все столбцы для определенной таблицы. Пример:
SELECT * FROM {B2BCustomer}
Теперь одна интересная особенность выбора заключается в том, что он также извлекает подтипы запрошенной таблицы. Например, следующий запрос:
SELECT * FROM {Product}
Извлечет экземпляры Product, но также вернет его подтипы, объекты VariantProduct. И если у вас есть другие пользовательские подтипы, они также будут извлечены.
Если мы не хотим, чтобы они извлекались, нам нужно добавить «!» после таблицы. имя:
SELECT * FROM {Product!}
Таким образом будут возвращены только экземпляры Product.
2. ГДЕ
Пока все хорошо, верно? Теперь предположим, что нам нужно отфильтровать результаты. Чтобы не делать этого вручную, мы добавляем фильтры в сам запрос. Для этого нам нужны новые ключевые слова:
- ГДЕ (чтобы указать, что следующее выражение является условием)
- и компараторы: LIKE (или =), ›, ‹, ‹=, ›= …
Давайте продолжим на нашем примере. Допустим, нам нужны все клиенты из определенной компании или нам нужны клиенты, которые вошли в систему после Черной пятницы 2022:
SELECT * FROM {ç} WHERE {uid} LIKE '%@company.com'
SELECT * FROM {B2BCustomer} WHERE {lastlogin} > '2022-11-25 09:00:00.000'
3. AS
Мы также можем использовать псевдонимы для ссылки на имена таблиц, они пригодятся в будущем, когда мы доберемся до объединения таблиц, и нам нужно будет проще ссылаться на таблицы без необходимости писать полную таблицу. имя каждый раз, когда нам нужно ссылаться на него.
Чтобы создать псевдонимы, мы помещаем «AS» после имени таблицы, а затем строку, которую мы будем использовать в качестве псевдонима:
SELECT * FROM {B2BCustomer AS customer}
Теперь, когда мы используем несколько таблиц в одном запросе и хотим отфильтровать столбцы, нам нужно использовать имя таблицы (или псевдоним, если мы его установили) и имя столбца, которое мы хотим получить. Есть два способа сделать это с помощью «.» или ":" :
SELECT {customer:uid} FROM {B2BCustomer AS customer}
SELECT {customer.defaultb2bunit} FROM {B2BCustomer AS customer}
Глава 2: Объединение таблиц
Теперь, когда мы можем выполнять базовые запросы к любой таблице, запрашивая либо конкретные столбцы, либо все столбцы, и используя условия для фильтрации результатов таблицы, пришло время перейти к следующему шагу: Соединение таблиц. сильный>.
Теперь мы все слышали классику:
Why do frontend developers eat lunch alone? Because they don't know how to join tables
Frontend-разработчики, я получил от вас новости, после прочтения этого вы можете в конечном итоге научить, как правильно соединять таблицы. Обязательно продолжайте читать.
Давайте начнем с понимания того, что означает объединение таблиц.
Каждая строка может содержать ключи двух типов: первичный ключ (pk) или внешние ключи. В строке может быть только один pk, но строка может содержать несколько внешних ключей.
Закрытый ключ является уникальным идентификатором строки, а внешние ключи ссылаются на pks строк в других таблицах. Таким образом, у нас есть pk для каждой строки в таблице для клиентов, но у них также есть внешний ключ, который указывает на их B2B-модуль по умолчанию.
Если мы возьмем значение по умолчанию b2bunit в таблице B2BCustomer, оно укажет нам на строку в таблице B2BUnit, содержащую всю информацию, касающуюся конкретной единицы B2B. Таким образом, одно и то же значение, когда оно используется в своей собственной строке, является pk, но когда оно используется в другой таблице (а иногда даже в той же таблице, но в разных строках), оно считается внешним ключом.
Звучит запутанно? Давайте покажем несколько примеров того, как это должно работать:
B2BCustomer +----------+------------------+----------------+ | pk | uid | defaultb2bunit | +----------+------------------+----------------+ | 26355079 | [email protected] | 9104091412 | | 15527936 | [email protected] | 3022939124 | +----------+------------------+----------------+ B2BUnit +------------+--------------------------------+-------------------------+ | pk | name | createdTS | +------------+--------------------------------+-------------------------+ | 9104091412 | Made-up company | 2018-05-16 15:44:51.39 | | 3022939124 | Definitely not made-up company | 2018-10-04 12:37:56.531 | +------------+--------------------------------+-------------------------+
Как видно из таблицы B2BCustomer, значение в столбце defaultb2bunit совпадает со значением pk в таблице B2BUnit. Данные хранятся в разных таблицах в зависимости от того, где они принадлежат или к какому типу данных они относятся. Это означает, что в одну таблицу не помещается вся подробная информация, относящаяся к конкретному объекту, некоторая конкретная информация будет храниться в других таблицах. Вот где соединение пригодится, чтобы извлечь все данные, хорошо связанные вместе, поэтому нам не нужно вручную объединять их после извлечения из базы данных.
Теперь давайте посмотрим, как это сделать с помощью гибкого поиска.
Как мы уже видели, нам нужны клиенты и привязанные к ним b2b-единицы. Один из вариантов, как я упоминал ранее, состоит в получении обеих таблиц по отдельности, а затем в ручном объединении информации. Если вы пойдете по этому пути, убедитесь, что у вас есть психолог наготове на случай, если вы сойдете с ума, что с большой вероятностью произойдет…
Вместо этого правильный способ сделать это:
SELECT * FROM {B2BCustomer as customer
JOIN B2BUnit as unit
ON {customer:defaultb2bunit} = {unit:pk}}
Гибкий поиск действительно может показаться пугающим, пугающим и таинственным. Но со временем вы привыкнете к этому и сможете использовать его, чтобы рыскать в глубинах ваших баз данных по своему желанию, извлекая именно те данные, которые вам нужны. Не только при ручном просмотре базы данных, но и при создании собственных пользовательских DAO.
Теперь вы достаточно хорошо разобрались с основами гибкого поиска. Я говорю «основы», но это далеко не все. Благодаря этим знаниям вы сможете решить практически любую проблему с гибким поиском, с которой вы можете столкнуться.
Ты сделал это! Теперь вы можете понимать запросы гибкого поиска, теперь вы можете изменять существующие запросы, вы можете создавать свои собственные... Теперь вы можете с гордостью называть себя знатоком гибкого поиска.
Вскоре будет опубликована часть 2, в которой будут рассмотрены более сложные темы, такие как подзапросы, как вставить запрос в запрос… Увидимся во второй части!
