Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 34
По сути ваша статья является наглядным примером использования на практике одного из основных принципов проектирования который впервые озвучил Грэди Буч (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.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Предельная унификация: программируем на языке бизнеса