Comments 66
Ага, лоукод. Это чтобы приложения делать.
Есть очень простой способ проверить, чем Интеграм лучше (или, вдруг, хуже). Попробуйте в АПЕКСе повторить вот этот путь создания простого приложения, где есть все популярные аспекты разработки (структура БД, бэкенд, запросы, отчеты, формы, управление доступом). В видосе это делается за 15 минут. Управитесь хотя бы за час? Я оплачу ваше время, мне это интересно.
https://rutube.ru/video/c85b3e7e11dc9f96f0f091d308968126/
По сути ваша статья является наглядным примером использования на практике одного из основных принципов проектирования который впервые озвучил Грэди Буч (Grady Booch)
"Любая нетривиальная информационная система в конечном счете стремится к модели, которая отражает сущности, отношения и поведение предметной области (реального мира), которую она предназначена обслуживать."
О, я даже не знал про такого, спасибо!
Подобные идеи много кто озвучивал и пытался воплотить, а масштабируемое решение появилось только с IDEAV.
Кстати, можно покликать самому (https://integram.io) или посмотреть, как это выгладит со стороны.
Осталось рассказать как миллиарды переборов по ЕВА модели ускорят бизнес и дело в шляпе
Там не миллиарды, а необходимый минимум, потому что IDEAV индексирован и выборка идет оптимизировано. При точечных выборках (1-10000 записей) из множества таблиц обычно работает быстрее, чем в обычной реляционной БД.
Даже если в той БД сотни миллионов записей:
https://rutube.ru/video/5b6775b31ed772ebbdc53818f9155a96/
Ага, прям в аналитическом отчёте будет 10к записей, чего нибудь с заказами на месяц при продажах условных батареек тысячами в день. Все эти манямечты рассыпаются о джойны в ЕВА моделях, которые коматозят все больше и больше
Вовсе нет. Пример: у нас у клиента биллинговая система по стримам на музыкальных площадках, и там больше 20 млн записей статистики о стримах, взаиморсчетах и прочем.
Ведется биллинг и считаются агрегаты: по ним или общая отчетность считается, которая в пределах 10000 записей обрабатывает (тысячи треков, альбомов, артистов), или статистика по конкретному артисту, что может составлять 10-50 тысяч записей, поэтому запрашивается страницами по 5000 записей и не дает фронту тормозить.
Так я и говорю - нормального энтерпрайза и не видели, где с одной стороны десятки тысяч товаров с 2000-3000 поставщиков, с другой товарная метрика километр на километр и надо посчитать закуп, себестоимость и всякое интересное попутно
Видел, поверьте. Это обычная реляционная БД, там все стандартные приемы работают: шардрование и прочее. Опыт есть в известном всем зеленом энтерпрайзе, всё будет работать. Да вот хотя бы в соседней статье посмотрите тесты:
https://habr.com/ru/articles/900308/
Вот здесь есть с таймингом и планами запросов:
https://habr.com/ru/articles/414255/
Согласитесь, удобно заходить в базу данных и вместо панели с
tbl_cust_ordиusr_acnt_statвидите таблицы Клиент, Заказ, Счёт, Статус. Точно те же слова, которыми вы оперируете в рабочих совещаниях и в мыслях. Вы формулируете задачу — «покажи все счета клиента “Иванов”» — и система понимает это буквально, потому что в её основе лежит не технический сленг, а чистый язык вашего бизнеса. Это и есть предельная унификация — стирание грани между тем, как говорит бизнес, и тем, как устроены данные.
Т.е. вы "изобрели" одни из принципов SOLID - Interface Segregation Principle (ISP): Принцип разделения интерфейсов – клиенты не должны зависеть от интерфейсов, которые они не используют. В этом и есть суть статьи?
Суть изобретения в преодолении предела работоспособности EAV по размеру данных и унификации хранения структур данных для того, чтобы использовать это всё в визуальном конструкторе баз данных и приложений.
Задача заметки — рассказать про возможность, которую дает подход IDEAV, на самом очевидном и популярном примере: удобство исследования баз данных аналитиком или пользователем.
SQL тоже задумывали максимально близким к естественному языку...
Из того, что мне встречалось, самый удобный мостик между языком бизнеса и разработки предоставляет платформа 1С. Не все идеально, но тот подход выглядит гораздо более жизнеспособным, чем описанный в данной статье. Впрочем, ИМХО.
Хорошо бы сравнить жизнеспособность на конкретных примерах. Вот один из них: проводка документа как в 1С руками ноукодера — и эти экселеподобные, но более крутые, приемы доступны для обычного аналитики, не требуют познавания парадигмы 1С.
https://rutube.ru/video/31caa1f7183a4b0ed028c3f6102b3ccf/
Например, расскажите о реализации блокировок в Ideav. Классическая ситуация: 2 клиента одновременно видят один последнее яблоко на товарных остатках и хотят его купить. Кому из них достанется яблоко? Если только одному, то за счёт чего это будет реализовано?
Также интересно узнать, что приходит на замену сложным join'ам в аналитических отчётах.
Это будет реализовано как в обычной базе: ограничения, триггеры и прочее.
JOIN'ы доступны любые, равно как вложенные запросы и рекурсия.
Если я правильно понял идею, то она заключается в следующем. Например, есть сущность "клиент" с полями: Название, ИНН, КПП. В классическом sql это будет 1 запись в таблице с 3 колонками (плюс четвертая - id). В Ideav это будет 3 строки в таблице с колонками: entity-key-value.
Если так, то как будет выглядеть, например, запрос вида "покажи все остатки товаров на складе в разрезе партий,по которым они пришли"? Или "дай список товаров, которые не продавались более трёх месяцев"?
Возможно, я просто не так понял вашу идею.
Запрос будет примерно такого плана:
SELECT a299.val 'Date',a299.id i1,a585.val 'Номер',a1003.val 'Приход',a286_val 'Договор', i5,a278_val 'Контрагент', i6,a303_val 'К-во', i7,a282_val 'Номенклатура', i8,a332_val 'Цена',a829_val 'НДС',a354_val 'Ставка НДС', i11,a3572_val 'Сумма',a336.val 'Пользователь',a301.val 'Создано'
FROM misa a299
LEFT JOIN misa a2891 ON a2891.up=a299.id AND a2891.t=2891
LEFT JOIN misa a585 ON a585.up=a299.id AND a585.t=585
LEFT JOIN misa a1003 ON a1003.up=a299.id AND a1003.t=1003
LEFT JOIN (misa r336 CROSS JOIN misa a336 USE INDEX (PRIMARY)) ON r336.up=a299.id AND a336.id=r336.t AND a336.t=18 AND r336.val='336'
LEFT JOIN misa a301 ON a301.up=a299.id AND a301.t=301
LEFT JOIN (SELECT r286.up,a286.val a286_val,a286.id i5,a286.id a286_id
FROM misa r286,misa a286 USE INDEX (PRIMARY)
WHERE a286.id=r286.t AND a286.t=286
) a286 ON a286.up=a299.id
LEFT JOIN (SELECT r278.up,a278.val a278_val,a278.id i6
FROM misa r278,misa a278 USE INDEX (PRIMARY)
WHERE a278.id=r278.t AND a278.t=278
) a278 ON a278.up=a286_id
LEFT JOIN (SELECT a303.up,a303.val a303_val,a303.id i7,a303.id a303_id,a332.val a332_val,a829.val a829_val,a3572.val a3572_val
FROM misa a303 /* We are an Array */
LEFT JOIN misa a332 ON a332.up=a303.id AND a332.t=332
LEFT JOIN misa a829 ON a829.up=a303.id AND a829.t=829
LEFT JOIN misa a3572 ON a3572.up=a303.id AND a3572.t=3572
WHERE a303.t=303
) a303 ON a303.up=a299.id
LEFT JOIN (SELECT r282.up,a282.val a282_val,a282.id i8
FROM misa r282,misa a282 USE INDEX (PRIMARY)
WHERE a282.id=r282.t AND a282.t=282
) a282 ON a282.up=a303_id
LEFT JOIN (SELECT r354.up,a354.val a354_val,a354.id i11
FROM misa r354,misa a354 USE INDEX (PRIMARY)
WHERE a354.id=r354.t AND a354.t=354
) a354 ON a354.up=a303_id
WHERE a299.up!=0 AND length(a299.val)!=0 AND a299.t=299 AND a299.val='20251231' AND (a2891.val IS NULL OR a2891.val IS NULL)
ORDER BY a299.val,a301.val LIMIT 25Вот здесь описана система, откуда этот запрос:
https://habr.com/ru/articles/545684/
А тут её можно покликать живьём (это старая версия сервиса, ей лет 5 уже):
https://ideav.pro/misa
Прямо сейчас всё просто - в случае с яблоками делается бронь, а в случае успеха - покупка. Кто первый оставил бронь, тот и купит. Бронь делается с фронта.
Хорошо, оба с фронта одновременно начали делать бронь и у обоих это удалось. Такое возможно? Если нет, то за счёт чего, какая там механика под капотом?
У обоих не удастся - только один получит успешный ответ, если применять транзакции.
Я к этому и веду. Какой уровень изоляции в транзакции?
Предполагаю, исходя из строения таблиц, что транзакции будут блокировать таблицу практически целиком. Т.е. система рассчитана на очень небольшое количество транзакций, что соответствует скорее малому бизнесу или прототипу. С повышением нагрузок на запись могут начаться проблемы. Исследовали ли вы уже этот вопрос? Может, у вас уже есть решение.
Если состав бизнесовых сущностей до конца не определен, то один из классических способов - использовать NoSql БД. Ну или тот же самый постгрес с JSONB. Там и индексы можно накидывать в том числе, и транзакции более явные делать. Смотрели ли в эту сторону?
Кстати, авторы платформы Интеграм (как раз на IDEAV) ставят амбициозную цель: чтобы следующая версия 1С была написана на IDEAV вместо существующей ORM 1С. 1С Lite.
Да, все так, и не только 1С :-)
За те 15 лет, что я работал с 1С, примерно каждые год-два появлялись все новые и новые "убийцы 1С".
Вообще я за то, чтобы в этом сегменте было больше одного крупного игрока. Чтобы была честная конкуренция и более динамичное развитие.
Но, увы, этого до сих пор не произошло, по разным причинам. 1С действительно хороша для своих задач. Я сомневаюсь, что предложенное решение в части хранения данных способно составить конкуренцию хотя бы по техническим параметрам (лёгкость поддержки, скорость работы).
Визуальная работа с сущностями, которую вы описываете - это классная вещь, тут плюсую. Но когда дело доходит до чуть более сложных бизнес-правил, то всегда в конце концов приходится писать код. И выигрывает здесь тот, кто сделает эту часть максимально лаконичной и близкой к бизнес-задаче, чем к техническим деталям вроде индексов БД и выбору между массивом и хэш-таблицей.
В 1С ведь есть подобные визуальные конструкторы, вроде конструктора проводок или конструктора отчётов. Но они годятся только для прототипа либо демонстрации возможностей на учебном курсе.
Так что цель и правда выглядит амбициозной, но для ее достижения, на мой взгляд, нужны другие технические решения.
Так что цель и правда выглядит амбициозной, но для ее достижения, на мой взгляд, нужны другие технические решения.
Вот это и есть такое решение, и мы делаем уже сейчас вполне жизнеспособные вещи в конструкторе Интеграм, годные для 95% МСБ и 80% корпов.
Сейчас это для тех, кто вырос из экселя и не знает, что с этим экселем делать. И эти люди есть и среди ИП, и в корпорациях.
Поздравляю, вы изобрели Prolog.
Это принципы domain driven design. Унифицированный язык в частности. Если ещё не читали то посмотрите может там ещё какие нибудь идеи покажуться интересными. Активно применяем их в разработке своих продуктов.
Да, суть та же, и мы стараемся упростить работу с сущностями, связями и методами, а в идеале так, чтобы и про программирование не надо было заморачиваться: только бизнес смысл снаружи, я вся техника под капотом.
Сейчас большая часть нашего сообщества - это аналитики и конечные пользователи и мы делаем всё достаточно по-ламерски и бессистемно (зато быстро и эффективно), поэтому хочется привлечь больше технарей, кто тоже, чуть меньше чем все, шел путем упрощения рутинной работы.
Да, суть та же, и мы стараемся упростить работу с сущностями, связями и методами, а в идеале так, чтобы и про программирование не надо было заморачиваться: только бизнес смысл снаружи, я вся техника под капотом.
Для этого SQL давно уже придумали. Он достаточно хорош. Сделать лучше у вас точно не получится.
Мы сделали No-code SQL - вы выбираете сущности и их поля, а конструктор сам связывает таблицы, формируя нативный SQL для БД. Это ускоряет написание запросов, сохраняя их мощь, включая вложенные запросы и рекурсию.
Конструкторов для SQL море. Еще один сделать можно. Но чем он лучше всех существующих конструкторов? Чем хуже понятно. У них история, опыт использования и все такое.
Давайте в каком-то из конструкторов повторим вот это и тогда сравним, где получилось лучше/быстрее/нагляднее и, вообще, получилось:
https://rutube.ru/video/31caa1f7183a4b0ed028c3f6102b3ccf/
Давайте начнем с классики https://www.oracle.com/apex/
Чувствуете уровень?
Ага, мы их копию делали.
https://rutube.ru/video/48a558802247d326e97ba57c9920a4ca/
Как раз к нам пришли по двум причинам:
1. Сильно тормозит
2. Нужно импортозамещение
Копию? Вы вот это вот серьезно? Хотя бы процентов 10 фичей повторили? Про 95 процентов фичей когда можно говорить о копии я даже не говорю.
Хорошее дело импортозамещением не назовут.
Смотрите, к нам приходят люди за 100% кастомизацией, и мы делаем ровно те фичи, что им нужно. Обычно это 2-3%, которые им нужны от функционала больших уважаемых систем, например лютый и непостижимый комбайн Битрикс24 или тот же Апекс.
Так вот, мы делаем простую копию того, что нужно, плюс несколько дополнительных функциональностей, которые пользователь не может сделать в оригинальной системе или это безумно дорого.
Никому нафиг не нужна полная копия Апекса, а нужно свести в дэшборд несколько табличек, которые обновляются из разных систем по расписанию.
И эти несколько формочек нормальный бизнес сделает на Битриксе и что там нынче еще популярно из конструкторов. Тильда? Просто потому что они известные и людей умеющих с ними работать море. Основные баги там вычищены, проблемы известны и вообще есть история и уверенность что через 5 лет оно будет работать. И стоят эти люди недорого.
Систем решающих минимальную проблему море. Они хороши и развиты. Еще одна не нужна. Она не принесет ничего нового.
Давайте начнем с классики
Что-то есть показать из построения запросов?
Не выборку разрезов по преднастроенным ОЛАП-кубам, а создание связанных таблиц и конструктор SQL по ним. Я-то знаю конкурентов :-)
В смысле? Весь APEX это лоукод платформа для приложенек. Запросы сами по себе никому не нужны.
Ага, лоукод. Это чтобы приложения делать.
Есть очень простой способ проверить, чем Интеграм лучше (или, вдруг, хуже). Попробуйте в АПЕКСе повторить вот этот путь создания простого приложения, где есть все популярные аспекты разработки (структура БД, бэкенд, запросы, отчеты, формы, управление доступом). В видосе это делается за 15 минут. Управитесь хотя бы за час? Я оплачу ваше время, мне это интересно.
https://rutube.ru/video/c85b3e7e11dc9f96f0f091d308968126/
Табличка с фильтрами это буквально один APEX контрол. Графики поверх таблички это второй контрол. Они там еще и выглядят нормально, а не здравствуй 90е или куда CSS пропали?
Ну несерьезно.
Табличка с фильтрами — это не приложение. Табличку надо создать, связи сделать и прочее. Ну, UI да, колхозный.
Сделаете по примеру или слив засчитан?
Конечно не приложение, поэтому в Битриксе или Апексе есть море разных возможностей. То что бизнесу обычно и нужно.
Я не вижу смысла делать табличку с простенькими фильтрами и графиками. Это не имеет смысла.
Ллмка кстати такое сгенерит на любых технологиях. Это как раз их уровень.
Конечно не приложение, поэтому в Битриксе или Апексе есть море разных возможностей. То что бизнесу обычно и нужно.
Обычно бизнесу нужны стандартные вещи, которые и правда есть в Битриксе. Шаг влево-вправо — и вот вам уже поможет только заказная разработка. Иначе её бы не было, а она — есть и стоит больших денег.
Лоукод платформы все такие. Десятилетия уже.
Как только нужно что-то нестандартное вперед программировать. Ничто кроме языка программирования не позволяет описать нестандартные штуки.
Вы тут ничего не измените. А программировать все предпочтут на массовом языке. Его знают, его поддерживают, на него можно нанять и все как обычно.
Ничто кроме языка программирования не позволяет описать нестандартные штуки.
Вы не правы, и я могу доказать это на практике, в отличие о вас (я предлагал, вы не видите смысла, ну, ок).
Фронт пишет LLM, бэкенд делается в конструкторе, без языков программирования (если не считать формулы и функции типа SUM, MIN, CONCAT языком).
LLM не способен на креатив, у него нет архитектурного видения, чтобы построить промышленное решение, поэтому мы сделали инструмент, где бэкенд делается руками в конструкторе с применением только бизнес-терминологии и формул, как в экселе.
Кстати, зачем бы это делать с LLM, если всё есть в битриксах?
Ллмка кстати такое сгенерит на любых технологиях. Это как раз их уровень.
Да, мы так теперь делаем фронт для приложений, а бэкенд — в Интеграме. Из альтернатив всё-в-одном для создания приложений на рынке крайне мало. Есть пара зарубежных — Bubble и Coda. Ну, у нас есть 1С ещё. И всё!
Модно же. Вон вайбкодеров уже половина Хабра.
Лоукод так не работает. В таких проектах все вместе делается в одном конструкторе. С миллионами стандартных скинов. Или с кастомным скином разработанным за небольшой бюджет.
И это неспроста. Когда все просто не надо усложнять и придумывать слои. Их наоборот надо скрыть от пользователя. Пусть один человек все делает, это дешевле.
И это все рынок не только понял, но и сделал продакшен решения.
Когда все просто не надо усложнять и придумывать слои. Их наоборот надо скрыть от пользователя. Пусть один человек все делает, это дешевле.
Так мы это и делаем. Серийно, за деньги.
В районе vc обычно пишут про бизнес успехи и успешные внедрения. Есть что почитать?
Тут можно полистать кейсы
https://integram.io/#results
Я такого ллмкой нагенерю сотню за день. Vc обеспечивает хоть какой-то контроль реальности кейсов, там люди понимающие.
Я такого ллмкой нагенерю сотню за день
Угу, верю, почему нет.
Что за Vc?
Оно, комментарии очень показательны. Там тоже не верят и задают такие же вопросы. А ведь это прямо потенциальные клиенты. Там малый бизнес тусит.
Что показательно 4 года назад оно выглядело так же. То есть даже дефолтный скин поприличнее не прикрутили. И фичи такие же. Одна табличка непонятно зачем нужная.
Как вас задело-то. Аж со всех своих аккаунтов в моей карме отметились.
Что показательно 4 года назад оно выглядело так же. То есть даже дефолтный скин поприличнее не прикрутили. И фичи такие же. Одна табличка непонятно зачем нужная.
Ага, за скины люди не платят. К нам приходят клиенты, кто перерос эксель и им некуда деваться, они платят как раз за защищенные таблички и отчеты, поэтому мы развиваем то, что под капотом, кирпичики бэкенда.
Часть клиентов пришло с той статьи, и с этой придут люди, только не клиенты, а адепты. Так всегда бывает.
Предельная унификация: программируем на языке бизнеса