Как раз тут не про бизнес-пользователя, а про программиста: его не нужно заставлять делать неблагодарную, незаметную, не оплачиваемую отдельно работу, когда Интеграл почти всю её сделал за него.
Спасибо, коллега! Вы первый комментатор, кто вдумался о чем речь.
На самом деле, запатентовать можно что угодно, и в ходе патентного поиска я насмотрелся всякого. Гораздо сложнее добиться практической работоспособности, и я начинал именно с неё. Ссыль
Ваше хранилище выглядит как EAV и крякает как EAV.
Я зачесываю волосы налево. По-вашему, я такой же зверюга, как Гитлер. Я, правда, ещё и рыжий. Ну, наверняка комик, скажете вы. А если я крякну?
Ок, техническими словами EAV как таковой неработоспособен, если пытаться сделать приложение только средствами EAV. EAV — это способ хранить данные для определенных задач, и у него есть свои недостатки, не к каждой задаче он подходит.
Я же утверждаю, что это решение подходит для любых задач прикладной разработки. На небольших проектах подходит как есть, и я могу показать эти проекты. Для нормальных промышленных масштабов требует доработки, как и любая связка Язык программирования — База — Шаблонизатор — Хостинг. Но принципиально тоже подходит для выполнения проекта целиком.
Так, в начале читаем: «вся черновая, рутинная работа программиста вынесена “за скобки”». Но при этом далее: «адаптация этих средств под конкретный проект сопоставима с написанием их с нуля».
Первая часть предложения про программиста, а вторая — про администратора. У них совершенно разные задачи, и этот проект ориентирован больше на программиста, освобождая его от рутины.
В небольших проектах администратор вообще не нужен, что является как раз целью Интеграла (рабочее название этого проекта). Часто в любительской прикладной разработке при 100 тысячах записей в базе уже начинает всё тормозить и нужен админ.
Ещё: заявлено «повышение надёжности базы данных за счёт минимизации ошибок при добавлении новых данных», но при этом — нельзя задать CONSTRAINT'ы.
Речь идет о DDL — вы не можете ошибиться с размерностью данных, ключами и теми же CONSTRAINT'ами, если у вас нет доступа ко всему этому.
Ещё в работе с СУБД «лавинообразное» (читай квадратичное) снижение производительности обычно связано с отсутствием правильных индексов, добавлением которых проблема решается.
Заставьте программиста залезть в базу, найти ВСЕ тонкие места и починить. И починить правильно. Бизнес-пользователю такое удается редко, точнее, почти никогда.
В примере с «последовательностью выборки связанных сущностей» планопостроитель любой СУБД построит правильный запрос при нормальной реляционной структуре таблиц, здесь преимущества мне совершенно неочевидны.
СУБД построит правильный запрос при нормальной реляционной структуре таблиц и наличии нужных индексов. Эту проблему Интеграл и решает (см. предыдущий абзац).
Есть построитель запросов, аналог SQL, там тот же принцип: перечисляете нужные вам поля данных из разных таблиц, ядро их связывает в запрос и выводит результат. Если связать можно разными способами (например, заказчик и подрядчик у договора хранятся в одной таблице юр.лиц), то вы можете указать, по каким полям нужна связь.
Статье есть пара ссылок на примеры, как это делается: вот и вот.
Вы правы, пока у меня нет возможности написать собственный движок или выкинуть всё ненужное для моей задачи из существующего движка с открытым кодом, это работает в обычной РСУБД, неважно какой.
Эта идея про подход, а реализация может быть любая.
Насчет быстрее: я не говорю, что быстрее, чем обычная РСУБД. А говорю, что устраняю непродуктивные накладные расходы и риски за счет добавления некоторой избыточности. Чтобы админу не приходилось искать узкие места и «добавлять индексы» в работающей системе, а сделать эту работу за него (это только одна из задач).
Не KV, опять клише и притянутые автоматом недостатки.
Если бы это укладывалось в существующие приемы, то защитить решение патентом было бы нельзя.
Ошибки сокращаются за счет устранения рисков низкоуровневой работы с данными.
Шардинг проще опять же из-за предельно простой структуры данных.
Это не EAV, поэтому подразумеваемых вами недостатков тут нет.
Постарайтесь без клише обойтись и, если интересно, я расскажу по пунктам, что и как.
Статью старался не перегружать, потому что есть отдельные ссылки, где всё можно посмотреть и потрогать.
Можно. Но магазинов уже запилено очень много на любой вкус.
Это больше про персонально заточенный под заказчика сервис, интегрированный с магазином и в единственном экземпляре. Сейчас такое быстро и дешево недоступно широкому низкобюджетному заказчику.
Наконец, хотелось бы узнать ваше мнение или опыт крупномасштабного повторного использования. Когда оно работает, а когда терпит неудачу?
Есть мнение, что фреймворк-мейкерам не нужно отчаиваться в стремлении изготовить более высокоуровневое средство для задания логики С. Ну, то есть, когда логику C будет быстрее переписать заново со слов пользователя, чем кодить программистским языком с привлечением программистских же библиотек.
Опыт тоже есть в этом.
Ну вы же понимаете, что за 5 дней можно 10 раз убрать из интерфейса 1С-ки все лишнее, разграничить роли, обучить ведению простых бизнес-процессов сотрудников. В чем профит для конечного заказчика?
Вы преувеличиваете — за полдня не выйдет (10 раз за 5 дней).
А вот скопировать нужный функционал 1С с нуля за 5 дней — это совсем другое дело.
Профит заказчика в том, что он получает простую систему, в которую прикручивает нужный ему функционал CRM, KPI, долги физлиц и всё что угодно остальное без интеграции с дополнительными системами. Ровно в том виде, в каком нужно (и за ту же цену). Как раз со скоростью 1 система за полдня.
Размер дистрибутива, конечно, хорошо. Да и у современной УТ база будет под гиг в развернутом виде, даже пустая. Но в 2018 вряд ли для кого-то будет решающим фактором «зато у нас дистрибутив на дискету помещается».
Тут мы подходим вплотную к тому, ради чего создан Интеграл. Коллеги выше не верят мне про возможности создать самодокументирующуюся систему, о чем будет моя следующая статья. Так вот, Интеграл позволяет описывать и экспортировать только бизнес-данные, без привязки к чему-либо чужеродному*, поэтому позволяет создавать что-то вроде ТЗ, которое можно распечатать единым документом и оно сразу будет работать.
* Функции языка SQL, которые можно использовать в отчетах, нужно будет описать для бизнеса, да, есть такое ограничение. Функции SUM, MIN, MAX, да пусть даже CONCAT вряд ли кого сильно озадачат. Ориентир по сложности восприятия у нас — MS Excel.
Мне, конечно, любопытно, как вы это гарантируете, но все равно для реальных задач линейный рост — это слишком плохо.
Логарифмическая зависимость, говорят же вам.
Вот так выглядит, например, тайминг импорта 4+ млн объектов в Интеграл, начиная с пустой базы — ведется подсчет вставленных записей каждые 15 секунд:
Сервер попутно еще загружен чем-то, поэтому всплески на графике. Еще при загрузке идет поиск родителя записи, там до 6 уровней иерархии.
Можно прикрутить Server Side Events или WebSocket, но по сравнению с обращением к URL такая функциональность нужна на порядок-другой реже, и обычно оказывается, что «мне только спросить». Пока никто не хотел этого настолько, чтобы оплатить несколько часов соответствующей работы (день возни в ядре).
Кусками — возникает и используется.
В качестве самодостаточного работоспособного решения я такого нигде не видел и даже не слышал.
На самом деле, запатентовать можно что угодно, и в ходе патентного поиска я насмотрелся всякого. Гораздо сложнее добиться практической работоспособности, и я начинал именно с неё.
Ссыль
Я зачесываю волосы налево. По-вашему, я такой же зверюга, как Гитлер. Я, правда, ещё и рыжий. Ну, наверняка комик, скажете вы. А если я крякну?
Ок, техническими словами EAV как таковой неработоспособен, если пытаться сделать приложение только средствами EAV. EAV — это способ хранить данные для определенных задач, и у него есть свои недостатки, не к каждой задаче он подходит.
Я же утверждаю, что это решение подходит для любых задач прикладной разработки. На небольших проектах подходит как есть, и я могу показать эти проекты. Для нормальных промышленных масштабов требует доработки, как и любая связка Язык программирования — База — Шаблонизатор — Хостинг. Но принципиально тоже подходит для выполнения проекта целиком.
Первая часть предложения про программиста, а вторая — про администратора. У них совершенно разные задачи, и этот проект ориентирован больше на программиста, освобождая его от рутины.
В небольших проектах администратор вообще не нужен, что является как раз целью Интеграла (рабочее название этого проекта). Часто в любительской прикладной разработке при 100 тысячах записей в базе уже начинает всё тормозить и нужен админ.
Речь идет о DDL — вы не можете ошибиться с размерностью данных, ключами и теми же CONSTRAINT'ами, если у вас нет доступа ко всему этому.
Заставьте программиста залезть в базу, найти ВСЕ тонкие места и починить. И починить правильно. Бизнес-пользователю такое удается редко, точнее, почти никогда.
СУБД построит правильный запрос при нормальной реляционной структуре таблиц и наличии нужных индексов. Эту проблему Интеграл и решает (см. предыдущий абзац).
Статье есть пара ссылок на примеры, как это делается: вот и вот.
Что «это»?
Вы выдрали кусок данных из контекста и строите неверную теорию.
Я говорю про принципиально иную структуру и иные методы, нежели это сделано в EAV.
Я вам совсем другое показывал, и вот то — не EAV.
Сама книга будет выглядеть в редакторе так:
А в Словаре этак:
Эта идея про подход, а реализация может быть любая.
Насчет быстрее: я не говорю, что быстрее, чем обычная РСУБД. А говорю, что устраняю непродуктивные накладные расходы и риски за счет добавления некоторой избыточности. Чтобы админу не приходилось искать узкие места и «добавлять индексы» в работающей системе, а сделать эту работу за него (это только одна из задач).
Так выглядит добавленный объект:
А так имевшиеся ранее и новые строчки в базе:
Если бы это укладывалось в существующие приемы, то защитить решение патентом было бы нельзя.
Ошибки сокращаются за счет устранения рисков низкоуровневой работы с данными.
Шардинг проще опять же из-за предельно простой структуры данных.
Постарайтесь без клише обойтись и, если интересно, я расскажу по пунктам, что и как.
Статью старался не перегружать, потому что есть отдельные ссылки, где всё можно посмотреть и потрогать.
Это больше про персонально заточенный под заказчика сервис, интегрированный с магазином и в единственном экземпляре. Сейчас такое быстро и дешево недоступно широкому низкобюджетному заказчику.
Есть мнение, что фреймворк-мейкерам не нужно отчаиваться в стремлении изготовить более высокоуровневое средство для задания логики С. Ну, то есть, когда логику C будет быстрее переписать заново со слов пользователя, чем кодить программистским языком с привлечением программистских же библиотек.
Опыт тоже есть в этом.
Вы преувеличиваете — за полдня не выйдет (10 раз за 5 дней).
А вот скопировать нужный функционал 1С с нуля за 5 дней — это совсем другое дело.
Профит заказчика в том, что он получает простую систему, в которую прикручивает нужный ему функционал CRM, KPI, долги физлиц и всё что угодно остальное без интеграции с дополнительными системами. Ровно в том виде, в каком нужно (и за ту же цену). Как раз со скоростью 1 система за полдня.
Тут мы подходим вплотную к тому, ради чего создан Интеграл. Коллеги выше не верят мне про возможности создать самодокументирующуюся систему, о чем будет моя следующая статья. Так вот, Интеграл позволяет описывать и экспортировать только бизнес-данные, без привязки к чему-либо чужеродному*, поэтому позволяет создавать что-то вроде ТЗ, которое можно распечатать единым документом и оно сразу будет работать.
* Функции языка SQL, которые можно использовать в отчетах, нужно будет описать для бизнеса, да, есть такое ограничение. Функции SUM, MIN, MAX, да пусть даже CONCAT вряд ли кого сильно озадачат. Ориентир по сложности восприятия у нас — MS Excel.
Логарифмическая зависимость, говорят же вам.
Вот так выглядит, например, тайминг импорта 4+ млн объектов в Интеграл, начиная с пустой базы — ведется подсчет вставленных записей каждые 15 секунд:
Сервер попутно еще загружен чем-то, поэтому всплески на графике. Еще при загрузке идет поиск родителя записи, там до 6 уровней иерархии.