IT + Postgresql

AppWrite, SupaBase, Directus, Strapi - не понравились

AppWrite

Есть всё, кроме массового импорта. Мощнейшая вещь.

Но настройка его сложна для новичка, и жрет о 2-4гб оперативки на сервере.

SupaBase

Крутая штука, не допёр как сделать авторизацию 🤣

И тоже с настройкой были траблы.

Плюс мне не нравится HTTP Basic Авторизация по захардкоженным credentials в конфиге прокси сервера.

За то импорт и экспорт нормальный есть

Directus

Очень крутая штука, особенно его Flows.

Стал сильно продуманнее за прошедшие полгода с моей встречи с ним.

Но все так же документация меня вымораживает. Много не раскрытых тем, и скрытых, не упомянутых ограничений.

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

В остальном это комбайн для супер быстрого старта, толком даже без настроек, всё мышкой можно сделать.

Ограничения так же можно обойти, сделав простое расширение, я так пол логики в прошлом проекте сделал, но теряется весь шарм легкости и наглядности. 🥲

Думаю ребята в нужном направлении двигаются, и их время просто ещё не настало, держу звезду на гитзабе за них.

Strapi

HeadlessCMS, да. Крутая, да. Популярная? А вот хз-хз.

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

НО КАК? Как может не быть у такой популярной CMS функционала для импорта/экспорта, хотя бы банального!?

Он справделивости ради есть в официальном маркете расширений, но... На прошлую версию 😖 Не без обратной совместимости 😩

Ну я его тоже оставил откисать.

FilamentPHP

Тяжелая артилерия из TALL Stack компонентов и не то что целой системы, а уже целой ЭКОсистемы для любого рода панелей, да еще и на базе Laravel 😤

Ну это козырь был.

Я пытался, честно, вот даже описал что меня останавило, и на каждый из вариантов я потратил минимум 4 часа времени.

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

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

Меня просто удивляет продуманность этого Filament. Баги есть, не без них, конечно. Как оказалось без ошибок ни то, что люди, роботы не справятся 🙃 (Отсылка к нейросетям)

Тут я за пару дней уложился извернуться и не сорвать сроки, а сделано:

• Админка

• Бизнес логика

• Token Based Авторизация по API
  (пришлось потратить полдня, чтобы разобраться в этой теме, так как я её намеренно игнорировал последние 3 года)

• API c аутентификацией по токену

• Расширение для хрома на WXT + React (TanStack Router, Query, Store)

• Для расширения хромовского - я вообще только с WXT работал и голым React, чисто для верстки.

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

Но с TanStack я не работал. Как-то раз для крипто проекта пытался его настроить и за целый день - так и не вышло. Сейчас же скажу - это мастхэв! Очень крутая штука!

Ну и отказался от Tailwind и SCSS в пользу CSS Modules в паре с clsx. И я не сказал бы, что стили писать долго. В моем случае я заказы беру вообще без дизайна и предпочтений, так что 50-80% от них пишет нейросеть, а я просто не претендую на произведение искусства 😆

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

Продолжаю тему разборов задач с собеседований по SQL. В этот раз выложу полное содержание, чтобы пост не удалили.

Итак, в базе данных есть таблица CLIENTS, содержащая три строки:

И есть таблица INVOICES, в которой две строки:

И сама задача звучит так: какое количество строк вернёт указанный ниже запрос:

SELECT * FROM CLIENTS WHERE EXISTS (SELECT COUNT(*) FROM INVOICES WHERE ID_CLIENT = CLIENTS.ID)

Здесь нужно было заметить неправильное использование EXISTS.

Оператор EXISTS используют для проверки того, возвращается ли что-то подзапросом, указанным в скобках. Как правило, в скобках для оператора EXISTS/NOT EXISTS пишут:

SELECT *

или:

SELECT 1

В задаче выше нарочно допущена ошибка (в EXISTS нарочно написано SELECT COUNT).

SELECT COUNT всегда будет возвращать данные. Написанный в скобочках подзапрос всегда будет возвращать количество, хоть и иногда 0. Но данные-то есть. Ноль - это тоже данные. Поэтому EXISTS будет давать TRUE для каждой из трех строчек основного запроса.

Ещё больше интересных задач с собеседований я публикую в моем Телеграм-канале по SQL!

Здравствуй, уважаемый читатель!

Как насчёт очередной задачи с собеседования по SQL? Задача базового курса, поэтому поставил одну звезду уровня сложности из пяти.

Дана схема данных (рисунок выше). Необходимо создать представление (VIEW) с названием CLIENTS_INFO, содержащее следующую информацию о клиентах: INN, NAME, PHONE.

Какая ошибка допущена в следующей SQL команде?

CREATE VIEW CLIENTS_INFO
AS SELECT INN, NAME, PHONE
FROM CLIENTS, CLIENT_CONTACTS
WHERE CLIENTS.CLIENT_ID = CLIENT_CONTACTS.CLIENT_ID

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

Здравствуй, уважаемый читатель! Спасибо, что заходишь ко мне на канал и изучаешь SQL со мной!

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

В базе данных есть таблица анализов Analysis, имеющая следующие столбцы: an_id — ID анализа; an_name — название анализа; an_price — цена анализа; an_group — группа анализов. Есть, также, таблица заказов Orders: ord_id — ID заказа; ord_datetime — дата и время заказа; ord_an — ID анализа. Необходимо вывести название и цену для всех анализов, которые продавались 5 февраля 2020 и всю следующую неделю.

Тут сделай паузу и попробуй сначала сам решить задачу.

Итак, надеюсь, ты делал паузу и составил SQL-запрос. Далее будем решать вместе.

Напомню, что нужно было вывести список анализов и их цену, которые продавались 05.02.2022 и всю следующую неделю.

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

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

select  a.an_name, a.an_cost from  analysis a where  exists (select 1 from orders  where ord_an = a.an_id  and ord_datetime between to_date('05.02.2022', 'dd.mm.yyyy') and to_date('05.02.2022', 'dd.mm.yyyy') + 7)

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

а не:

В примере, что я нашёл в интернете (ссылка ниже), помимо названий анализов и их стоимостей, выведен ещё и столбец с датами заказов. По условиям задачи вывод этого столбца не запрашивался. Не требовался вывод никакой информации о заказах/продажах. Поэтому и надобности в соединении я не усмотрел. Наоборот, это и потенциально замножит вывод анализов, которые покупали в запрашиваемый период, и прибавит лишнюю работу СУБД.

Ссылка на источник: https://tproger.ru/articles/5-zadanij-po-sql-s-realnyh-sobesedovanij

Поддержи статью лайком или подпиской!

Ещё больше интересных практических задач по SQL и задач с собеседований в нашем Телеграмм-канале и в интернете :)