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

Его деятельность - расчет закупок для E-commerce компаний.

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

Как это работает сейчас

- У него было есть несколько Excel таблиц-инструментов - для прогнозирования закупок, для отображения аналитики и финансов, для экспорта данных клиенту.

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

- Для каждой компании он заводит отдельный набор табличек.

- В текущем виде это невозможно продавать как продукт для сторонних пользователей.

Что он хочет

- Упаковать этот набор табличек в полноценный удобный диджитал продукт.

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

Scope проекта

Я проанализировал его таблицы и текущий процесс и вместе с ним составил ТЗ с основными требованиями.

Загрузка данных

- Расчеты строятся на различных данных, которые нужно будет загружать в систему как CSV файлы (а в будущем через API интеграцию).

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

- Средний объем данных по компании - 100-300 товаров, по каждому из которых около может быть около 50 записей в БД в разных таблицах.

- Данные могут обновляться пользователем каждую неделю и должны полностью перезаписывать существующие данные.

Расчеты

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

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

- В интерфейсе есть 1 изменяемый параметр - сколько будет закуплено товара в конкретный месяц. Он может быть изменен пользователем в интерфейсе для любого месяца и влияет на расчеты для последующих месяцев. Перерасчет параметров должен отображаться в интерфейсе моментально.

Версионирование

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

- Изменять данные в сохраненном сценарии нельзя - это просто слепок расчетов.

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

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

• Расскажи мне о своем бизнесе, чем ты занимаешься? (ваша презентация в лифте)
• Каково ваше «ПОЧЕМУ»?
• Кто ваш конкурент?
• Что отличает вас от конкурентов?
• 3 причины, почему клиент должен выбрать именно вас?
• Каково ваше видение бизнеса?
• Какова ваша цель на этот год?
• За что вы хотели бы быть узнаваемым?
• Опишите ваш продукт/услуги/продукты
• Есть ли что-нибудь еще, что мне следует знать о вашем продукте?

• Кто ваш клиент? Расскажите мне больше о ней/нем.
• Какова самая большая проблема, с которой сейчас сталкивается ваш клиент?
• Что им от вас нужно, когда они обращаются к вам? Что они говорят, когда им нужна ваша помощь?
• Какой злодей у ​​вашего клиента? С чем она/он борется?
• Чего стыдится ваш клиент, когда его проблема не решается? Почему она/он чувствует себя плохо?
• Что расстраивает вашего клиента, когда он не может решить свою проблему? Что она/он чувствует?
• Как вы можете помочь своим клиентам решить их проблему?
• Как ваша услуга/продукт облегчит жизнь вашим клиентам?
• Как изменится жизнь вашего клиента после покупки вашего предложения?
• От чего вы спасаете своих клиентов?
• С чем ваш клиент НЕ должен бороться в идеальном мире?
• Что самое худшее может случиться, если их проблема не будет решена?

Я успел потыкать ее и сделать несколько скриншотов. Я собирался сделать полноценную прожарку и проверить разные сценарии и промпты, но она испарилась.

Давайте посмотрим, что я успел понять об этой фиче.

Процесс создания

Процесс создания состоит всего из двух шагов - выбора шаблона и написания промпта.

Я занимаюсь разработкой кастомных CRM, поэтому мой выбор пал на Dashboard. Он также наиболее интересен, тем что включает в себя несколько сложных компонентов - графики, метрики, таблицы.

На втором шаге нужно написать промпт.

Мой промпт был таким:

I want to have admin page to manage main entities - products, clients, orders. It should be single page application. Each subpage should have the same - table with data and ability open details of item in popup to edit/delete it, create new record button and 3 filters - 1 search and 2 dropdowns.

Идея была в том, чтобы проверить, насколько AI сможет детально проработать требования и соответствовать им.

Дизайн

После нескольких секунд раздумий Bubble создал новую страницу с вот таким интерфейсом:

На Linkedin я видел скриншот другого пользователя и его сгенерированный сайт выглядел примерно также, поэтому вариативность пока что оставляет желать лучшего.

К удивлению весь дашборд включая таблицы и меню оказался адаптивным:

Функциональность

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

В рамках Single Page Application хотелось бы увидеть несколько рабочих экранов с возможностью переключения. Или хотя бы готовые кнопки с привязкой к Option set.

Стили

Не буду врать, я подзабыл, но вроде AI создал ряд классов и точно (это я помню) создал ряд кастомных цветов вкладке Styles с четким описанием.

На шаге написания промпта можно выбрать использование существующих стилей - интересно будет посмотреть, как он будет выбирать из нескольких стилей для одного компонента (возможно возьмет дефолтные)

Итог

Мое мнение - это будет хорошо работать быстрого создания демо для клиентов и создания простых компонентов/лендингов.

Так как подходы к разработке зависят от стэка (БД может быть на Airtable, SQL и тд) и требуемого функционала на конкретном проекте, то сложно прописать логику и дизайн создаваемых элементов, которые подойдут всем.

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

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

Ставьте лайк и подписывайтесь, чтобы прокачиваться в no-code вместе со мной

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

Первая часть про клиентов с идеями

Клиенты с болями

1. Чем сильнее боль - тем лучше

- Клиент быстро отвечает на все вопросы, предоставляет нужные ресурсы и идет на компромиссы ради решения боли.

2. Все детали известны

- Боль располагается в определенном месте существующего процесса и у этого процесса есть свои ответственные, с которых нужно лишь собрать информацию.

3. Боль либо решена, либо болит

- Ни вы, ни клиент не сможете бесконечно растягивать решение боли - клиенту нужно решить эту боль и он не будет ждать вас - просто обратится к другому специалисту.

4. Решение боли отрывают с руками

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

5. Актуально пока болит

- Пока боль актуальна, будет актуально ее решение, а также поддержка этого решения.

6. Максимальный бюджет равен убыткам от боли

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

Чем это для вас закончится

1. Построите долгосрочные отношения

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

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

2. Дадите старт чему-то большему

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

Что с ними делать

1. Выкладываться по полной

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

- Поэтому следует заботиться о решениях для них - делать их более качественными, продумывать возможные проблемы наперед, следить за безопасностью, экспериментировать в попытках сделать еще лучше/быстрее/красивее, писать документацию и тд.

2. Расширять свою ответственность

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

Проекты, базирующиеся на болях, в которых я участвовал:

1. Touzicapital - инвестиционный фонд

- Мой самый большой и интересный проект для фонда из США, который я нашел на Upwork - за время работы через мои автоматизации прошло $14 млн.

- Клиентский портал, админ-панель для распределения дивидендов, интеграция с платежной системой.

- Я получал месячную зп $5к, проработал с клиентом около 9 месяцев и сделал c ним еще один небольшой проект, где собрал свою команду с бюджетом в $20к.

2. Optport - оптовый магазин товаров

- Проект для моих знакомых, через который прошло уже сделок на 7 млн. руб.

- Mobile-first магазин для пользователей, админ-панель для управления заказами и продуктами, интеграция с Telegram.

- После реализации данного проекта я сделал еще 2 подобных проекта, используя созданные наработки, и заработал суммарно $15к.

3. Nurture - благотворительная организация для обучения предпринимателей, работающих с детьми

- Моя работа с агентством из Сан-Франциско, которые реализовали для организации мобильное приложение на FF.

- Админ панель на Retool для управления контентом курса, пользователями и отдельный портал для партнеров (которые жертвуют деньги на обучение).

- После успешной реализации основного портала клиенты продолжают добавлять фичи и суммарная стоимость этих изменений перевалила за $9к.

Итог

Старайтесь искать клиентов с болями и помогайте им.
Не возлагайте больших надежд на клиентов с идеями, но и не пренебрегайте ими.

Ставьте лайк и подписывайтесь, в следующем посте посмотрим, что способна генерировать новая AI фича от Bubble

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

Большая часть успеха фрилансера заключается в умении распознать клиента с болью и оседлать клиента с идеей.

Клиенты с идеями

1. Чем сильнее одержимость идеей - тем хуже

- Клиент будет влезать во все процессы и отказываться идти на компромиссы (которые важны в ноукоде).

2. Детали идеи не известны

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

- Вариант хуже - у клиента есть десять тысяч деталей про все фичи от первой до той, когда он продает свою долю на IPO.

3. У идей нет конца

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

4. Идейное решение всегда требует продаж

- Продукт не решающий проблему не вызывает вау эффекта и пользователей нужно уговаривать его попробовать.

5. Актуально, пока есть мотивация

- Реализация проекта будет актуальна до тех пор, пока есть внутренняя мотивация у клиента, которая может кончится по среди проекта.

6. Максимальный бюджет равен текущим средствам клиента

- У клиента нет четкого понимания выгод, которые он получит от реализации проекта, а значит и бюджет его ограничен тем, что ему не жалко потратить в моменте.

Чем это для вас закончится

1. Кончится мотивация клиента

- Проект умрет сразу после разработки, так как клиент сменил приоритет или понял, что он все таки не стартапер.

2. Кончатся ваши нервы

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

- Если у клиента нет денег, то он будет жаловаться, что вы не сделали ему Youtube за $1550, просить довести фичи до уровня гигантских корпораций, а в конце оставит плохой отзыв.

Что с ними делать

1. Отказываться

- Серьезно, просто откажитесь, оно того не стоит.

- Работать с такими клиентами следует только новичкам, чтобы набраться опыта и заработать начальный капитал.

2. Пытаться перевести в боль

- Вы можете оседлать такого клиента и вести проект в то русло, где есть хотя бы малая надежда на успех. Вам нужно стать родителем этого проекта (и клиента).

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

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

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

Проекты, базирующиеся на идее, которые я делал/видел:

1. Psybercare - сервис психологической помощи

- Проект моего друга, сделанный через WLNC для японских студентов из Лондона.

- Сложный дизайн лендинга, внутри миллион фичей - аудио и видео звонки, система рейтинга, метчинг по параметрам, чаты, каталоги и тд.

- Стоил >$10k и был похоронен сразу после окончания разработки, так как делался скорее для учебных целей (?).

2. Jetdeux - метчинг пассажиров для частных полетов

- Клиент с опытом в частных перелетах захотел сделать свой сервис, как у конкурентов.

- Внутри система поиска полетов под paywall'ом, интеграция с внешним сервисом поиска полетов. Разбор кейса

- Стоил около $3.5к и потихоньку умер на моменте привлечения пользователей - оказалось, что развивать продукты гораздо сложнее, чем придумывать.

3. Reinterpay - white label SaaS сервис для платежей

- Клиент - богатый предприниматель со смутным финансовым проектом из Австралии и хорошим чеком, который он получил продав его

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

- Стоил $2.5к и клиент пропал на последнем этапе проекта - видимо нашел более прибыльные темы.

Ставьте лайк и подписывайтесь, в следующем посте разберем клиентов с болями.

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

Сегодня я хотел бы сделать небольшое ретро и рассказать, с какими 4 проблемами мы столкнулись после запуска приложения и как решили их.

Проблемы с логином менеджеров

Вы когда-нибудь вводили пароль 5 раз неправильно и на 6-ой раз, введя тоже самое, наконец-то попадали внутрь?

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

Решением стало простое добавление плагина Reveal & Hide password - жалобы прекратились, а значит проблема была не в процессе аутентификации.

Массовая рассылка сообщений от бота

Чтобы отправлять через бота новости и акции, в админке был реализован специальный раздел, где можно загрузить фото/видео с текстом и отправить всем подписчикам бота (коих несколько тысяч).

Первая же отправка вышла комом - видео в сообщении отобразилось в виде файла для скачивания, хотя и было отправлено через специальный модуль в Make. Оказалось, что для отображения в полном виде видео должно быть в формате MP4.

Решением проблемы стала кнопка отправки тестового сообщения в отдельный чат, а также добавление алерта для менеджера на случай формата отличного от MP4 с ссылкой на конвертер.

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

Карточки VS Строки

Прошлый каталог был расположен в excel и был удобен для быстрого просмотра десятка различных товаров.

Каталог в приложении же представляет из себя галерею карточек с фото и описанием, что позволяет просматривать лишь 3 товара за раз. Такая галерея плохо прижилась у старых клиентов, но понравилась новым.

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

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

Невидимый инпут

Основная часть заказов в магазине является мелким оптом, а значит зачастую клиентам требуется 5-10 единиц товара.

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

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

Ставьте лайк и подписывайтесь, чтобы не пропустить следующий кейс

Поэтому, они остановились на идее бота-калькулятора в ТГ для расчета стоимости на основе ссылки на товар.

Я изучил Poizon и предложил им сделать полноценный магазин с прямой интеграцией к их внутреннему API.

Сегодня узнаем, что из этого получилось и сколько это стоило...

Техническое решение

Само приложение создано на Bubble и состоит из пользовательской части, которая встроена в Telegram Web App, и админки для управления заказами. База данных сделана на Supabase, как и во всех моих последних проектах.

Telegram

Для общения Web App с сайтом я доработал плагин Жени и добавил ряд дополнительных функций.

С помощью плагина я могу:

• показывать/скрывать нативную кнопку "Назад"
• отлавливать событие нажатия кнопки и производить навигацию по сайту
• открывать ссылки с Instant view, не закрывая приложения
• получать информацию о пользователе (id, username, name) - id используется для аутентификации
• получать параметры запуска приложения - позволяет создавать диплинк на определенный товар

Единственная вещь, которая не получилась, это получение фото пользователя - ссылка на фото просто не отдается Telegram'ом. Решением было создание отдельного сценария для бота с получением фото через кастомный API call getUserProfilePhotos в Make.

Также через Telegram группы осуществляется уведомление менеджеров о новых сообщениях и заказах.

ChatApp

Для общения с пользователями через бота в режиме одного окна я выбрал сервис Chatapp.

Его особенности:

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

Poizon

Самой сложной частью оказалась интеграция с Poizon. Poizon имеет два отдельных продукта - сайт для США и мобильное приложение в Китае.

Ни один из продуктов не имеет публичного API, но использует внутренний.

Изначально, я нашел человека с готовым API для США и думал строить решение на его основе. Но в процессе человек слился и я решил попробовать расковырять API сам.

К сожалению, детали решения являются своего рода конкурентным преимуществом, поэтому ограничусь только тем, что мне это удалось 😉

Продукт менеджмент

Несмотря на технически реализованное решение, в продукте самое главное пользователи и их фидбек.

Для успешного развития продукта я добавил запись пользовательских сессий через Hotjar и логи для основных событий. Эти данные позволяют анализировать продвижения пользователей по воронке и улучшать их пользовательский опыт.

Эпилог

На данный момент проект потихоньку развивается и на этой неделе я добавлю ту самую фичу с расчетом цены по ссылке на товар, которую изначально хотели мои знакомые, но уже в приложение с каталогом на сотни тысяч товаров 😏

Стоимость проекта составила $4к, что на самом деле является очень маленькой ценой за такое решение, но зато я получил отличный опыт и приобрел полезные знакомства.

Ставьте лайк и подписывайтесь, чтобы прокачиваться в no-code вместе со мной

Я помогаю им делать админки на Retool для мобильных приложений и наше сотрудничество уже принесло мне $8k.

Вчера у нас был совместный звонок с потенциальным клиентом на Bubble. Клиент хочет сложное решение по генерации лендосов с AI и публикацией их под доменами пользователей.  👀

Сначала я думал отказаться, потому что это невозможно и клиент витает в облаках.

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

Успокоившись на счет клиента, я поразмыслил и понял, что технически проект вполне реализуем.

У нас были другие варианты, но мы остановились на вас, потому что вы задаете вопросы

Вот так звучит фраза, после которой с вами подписывают контракт на $20к+, запомните ее.

Как же услышать ее? Задавайте вопросы.

Почему важно задавать вопросы?

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

А также:

• узнаете больше о клиенте
• находите проблемные/сложные места до начала разработки
• точнее оцениваете проект во времени/деньгах

Что будет, если не задавать вопросы

• клиент может оказаться невменяемым - запросить кучу фич без бюджета, угрожать плохим отзывом, не принимать результат/не платить
• скоуп задач останется не проработанным - вы столкнетесь с проблемой реализации сложных фич, количество задач увеличится вдвое без увеличения бюджета
• ожидания клиента не совпадут с реальностью - проект может занять больше времени/денег, чем ожидалось; некоторые фичи не будут реализованы/будут реализованы в другом виде

Какие вопросы задавать? (Неудобные)

• про текущее состояние - какая цель проекта? почему он хочет реализовывать эти фичи/использовать этот сервис? кто им будет пользоваться?
• про развитие продукта в будущем - как будет выглядеть запуск MVP/внедрение решения в текущий бизнес процесс? кто и на какие средства будет поддерживать проект после запуска?
• про проектные риски - что если реализация данной фичи невозможна/ограничена? что если мы не уложимся в сроки?
• про продукт (наиболее непонятные места) - что если… клиент захочет изменить сгенерированный лендинг? опишите… как будет выглядить генерация лендинга в деталях с точки зрения пользователя?

Мой опыт

• Я задаю вопросы сразу в отклике - это подчеркивает, что вы читали описание, и сразу задает тему для продолжения разговора
• Я не работаю с теми, кто не может ответить на базовые вопросы - со временем образовывается чеклист/список вопросов, который помогает отсеивать заведомо проблемные проекты
• Я задаю вопросы и делаю исследование, пока не пойму, что технически все возможно - лучше потратить свое время до проекта и сделать работающее демо, которое можно будет перенести в проект, чем понять через неделю, что реализация невозможна, а бюджет ты уже потратил 😢

Люди хотят, чтобы вы задавали им вопросы

Ставьте лайк и подписывайтесь, чтобы прокачиваться в no-code вместе со мной

AS

Но начнем мы с более простого понятия алиас - эта функция позволяет переименовывать таблицы и поля.

Вы можете делать это с помощью ключевого слова as или без него, просто указав алиас через пробел -

Пример - SELECT name as user_names FROM users - вернет список имен пользователей в поле user_names

Альтернативный вариант - SELECT name user_names FROM users

Давайте перейдем к JOIN и попрактикуем работу с алиасами.

JOIN

Перед тем как приступить к разбору этого раздела добавим новую таблицу Orders. В ней будут хранится данные о заказах наших пользователей - сумма и название продукта (пусть будут кроссовки).

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

Мы связали заказы с таблицей пользователей через первичный ключ таблицы Users - id и назвали его user_id. Как видим Jack приобрел 2 пары кроссовок, Max одну, а John решил остаться при своих.

Представим, что вам нужно вывести в интерфейсе список заказов с именами покупателей - здесь то и выходит на сцену раздел JOIN.

JOIN - позволяет объединить записи из двух или более таблиц на основе указанного условия.

Примечания - Вы указываете таблицы, которые нужно объединить, используя ключевые слова JOIN, и условие объединения после ключевого слова ON.

Пример - SELECT * FROM orders JOIN users ON users.id = orders.user_id

Перепишем пример с алиасами - SELECT * FROM users u JOIN orders o ON u.id = o.user_id

С помощью этого запроса мы получили список, где для каждого заказа, используя user_id, мы нашли в таблице Users пользователя и его данные.

Одна проблема - поля id и name слепились. Они существует в обоих таблицах, но мы видим только одно поле и не можем однозначно определить, к какой таблице она относится. Чтобы не было такой путаницы, давайте однозначно укажем в запросе поля с алиасами.

Пример - SELECT u.id as users_table_id, o.id as orders_table_id, o.user_id as orders_table_user_id, u.name as users_table_name, u.age, o.value, o.name as orders_name FROM orders o JOIN users u ON u.id = o.user_id

Теперь мы видим, что поле id "разлепилось" на 2 поля - одно из таблицы Users и другое из таблицы Orders.

Но это еще не все, ведь на самом деле JOIN является краткой формой INNER JOIN и существует еще 3 разновидности соединения.

INNER / LEFT / RIGHT / FULL OUTER

Суть раздела JOIN - соединить два множества по какому-то признаку. Это можно сделать несколькими способами:

• LEFT JOIN (левое соединение) - возвращает все записи из левой таблицы и соответствующие (подходящие по признаку) записи из правой таблицы.
• RIGHT JOIN (правое соединение) - возвращает все записи из правой таблицы и соответствующие записи из левой таблицы.
• (INNER) JOIN (внутреннее соединение) - возвращает только те записи, которые имеют совпадающие значения в обеих таблицах.
• FULL OUTER JOIN (полное внешнее соединение) - возвращает все записи из обеих таблиц, независимо от того, есть ли совпадающие записи в другой таблице.

Чаще всего вы будете пользоваться (INNER) JOIN и LEFT JOIN.

В нашем примере при использовании (INNER) JOIN заказы, которые не имеют связи с пользователем, отражены не будут.

Нашей целью является только обогащение таблицы заказов данными о клиентах, поэтому нам нужно использовать LEFT JOIN

Пример - SELECT u.id as users_table_id, o.id as orders_table_id, o.user_id as orders_table_user_id, u.name as users_table_name, u.age, o.value, o.name as orders_name FROM orders o LEFT JOIN users u ON u.id = o.user_id

Как видите, теперь у нас есть список всех заказов с данными по пользователю, если он существует.

На этом на сегодня все! На следующем уроке мы будем разбирать разделы GROUP BY и HAVING BY.

Предыдущие уроки:

• Урок 1
• Урок 2
• Урок 3

Ставьте лайк и подписывайтесь, чтобы прокачиваться в no-code вместе со мной

Первичный ключ

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

Первичный ключ может быть числом, текстом, уникальным идентификатором - uuid или композитным ключом, состоящим из комбинирования двух других полей (“Max”+”17” - в таблице может быть другой Max, но не может быть двух Max’ов, которым 17 лет)

Добавим первичный ключ в нашу таблицу:

Теперь рассмотрим другие разделы оператора SELECT.

Разделы оператора SELECT

WHERE - позволяет фильтровать записи в таблице на основе указанного условия.

Примечания - Вы указываете условие после ключевого слова WHERE, чтобы определить, какие записи будут включены в результат. Условие может содержать операторы сравнения, логические операторы и различные функции.

Пример - SELECT * FROM users WHERE age > 18

ORDER BY - позволяет отсортировать записи в таблице по указанным столбцам.

Примечания - Вы указываете один или несколько столбцов после ключевого слова ORDER BY, чтобы определить порядок сортировки. По умолчанию сортировка происходит по возрастанию ASC, но вы можете указать DESC для сортировки по убыванию.

Пример - SELECT * FROM users ORDER BY age DESC

LIMIT - позволяет ограничить количество записей, возвращаемых в результате запроса.

Примечания - Вы указываете максимальное количество записей после ключевого слова LIMIT. Это полезно для разбиения результатов на страницы или получения только части результатов.

Пример - SELECT * FROM users LIMIT 10

OFFSET - позволяет пропустить указанное количество записей перед началом выборки результатов.

Примечания - Вы указываете количество записей, которые нужно пропустить, после ключевого слова OFFSET. Часто используется вместе с LIMIT для реализации пагинации результатов.

Пример - SELECT * FROM users LIMIT 10 OFFSET 20

Ссылка на следующий урок про раздел JOIN

Ставьте лайк и подписывайтесь, чтобы прокачиваться в no-code вместе со мной