Есть построитель запросов, аналог 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 такая функциональность нужна на порядок-другой реже, и обычно оказывается, что «мне только спросить». Пока никто не хотел этого настолько, чтобы оплатить несколько часов соответствующей работы (день возни в ядре).
Ответить на вопрос можно только сравнив приложения, написанные во всех этих решениях.
Не «Hello, world!» и «table1 — table2», а что-то используемое людьми. За деньги.
Давайте попробуем разобрать на примере. Часто встречается: пользователю нужны 2 жалких журнала: приходы и продажи. И сумма в кассе. (Онлайн-касса маячит на горизонте, но пока мало кто чешется)
Дистрибутив 1С для этой несложной задачи (Торговля и склад) весит 180МБ, потребует компьютер и настройки под себя руками специалиста. В результате, гипотетически, будет решен любой набор задач, если знаешь когда какую кнопку нажимать (а их в меню больше сотни). Практически же люди так и сидят с бумажками. Сложно им.
Простейший аналог в Интеграле не потребует ничего, кроме планшета или мобилы.
Выгрузка конфигурации — схема данных, отчеты, справочники — занимает меньше 15 КБ (так, к слову). Само программирование заготовки этого кустарного аналога заняло около 5 дней, и он точь-в-точь может воплотить требования среднего пользователя еще за 4-8 часов.
За 40 минут (мы пробовали) можно сделать импорт номенклатуры откуда угодно.
Интерактив клиентской части делается вне Интеграла (как хотите), а его шаблоны подгружаются в сервис.
Там написано в первом же абзаце, для чего этот сервис:
Я расскажу о технологической платформе, пригодной для создания информационного ядра системы или приложения. Платформа содержит простой высокоуровневый конструктор модели данных и базовый интерфейс для работы с ней, поддерживает ролевую модель доступа, эмулятор запросов SQL (CRUD), API, а также дает возможность загружать произвольные рабочие места — элементы UI — и наполнять их данными.
Вы перечислили не проблемы, а задачи. Git вам нравится? Так и грузите всё в Git, никто не мешает.
Всё, что создано в Интеграле, можно задокументировать бесконечным количеством способов, потому что вся информация хранится в базе или файлах (шаблонах) интерфейса.
В целях версионирования можно выгрузить все запросы и статические справочники во внутреннем формате Интеграла (по умолчанию) или преобразовать их в человеческий или машинный язык (да, придется пилить самому). Это такая фича — данные, метаданные и «код» хранятся в одной базе, могут быть преобразованы в нужный вид, модифицированы, сгенерированы автоматически или визардом (как выше описано про составные типы), загружены обратно и т.д.
Пока же наработок немного, поэтому я и не говорю, что матёрые программисты найдут здесь готовые решения. Но я аккуратно записываю всё, что мне здесь говорят, на будущее.
Сейчас это, в основном, сервис для «самых маленьких», кто работает в экселях, в одиночку, пока не имеет понятия о версионности и хочет сделать всё быстро и «на живую».
В 1С, если не ошибаюсь, используются регистры для хранения данных об остатках товаров, поэтому отчет время построения отчета слабо зависит от количества движений. В Интеграле можно сделать точно так же, точную функциональную копию нужных возможностей, включая логику работы базы.
Да, к сервису также прикручен очень примитивный интерфейс, позволяющий сделать всё остальное. Он такой топорный, потому что задумка про архитектуру и подход, повторюсь.
Статье есть пара ссылок на примеры, как это делается: вот и вот.
Что «это»?
Вы выдрали кусок данных из контекста и строите неверную теорию.
Я говорю про принципиально иную структуру и иные методы, нежели это сделано в EAV.
Я вам совсем другое показывал, и вот то — не EAV.
Сама книга будет выглядеть в редакторе так:
А в Словаре этак:
Эта идея про подход, а реализация может быть любая.
Насчет быстрее: я не говорю, что быстрее, чем обычная РСУБД. А говорю, что устраняю непродуктивные накладные расходы и риски за счет добавления некоторой избыточности. Чтобы админу не приходилось искать узкие места и «добавлять индексы» в работающей системе, а сделать эту работу за него (это только одна из задач).
Так выглядит добавленный объект:
А так имевшиеся ранее и новые строчки в базе:
Если бы это укладывалось в существующие приемы, то защитить решение патентом было бы нельзя.
Ошибки сокращаются за счет устранения рисков низкоуровневой работы с данными.
Шардинг проще опять же из-за предельно простой структуры данных.
Постарайтесь без клише обойтись и, если интересно, я расскажу по пунктам, что и как.
Статью старался не перегружать, потому что есть отдельные ссылки, где всё можно посмотреть и потрогать.
Это больше про персонально заточенный под заказчика сервис, интегрированный с магазином и в единственном экземпляре. Сейчас такое быстро и дешево недоступно широкому низкобюджетному заказчику.
Есть мнение, что фреймворк-мейкерам не нужно отчаиваться в стремлении изготовить более высокоуровневое средство для задания логики С. Ну, то есть, когда логику C будет быстрее переписать заново со слов пользователя, чем кодить программистским языком с привлечением программистских же библиотек.
Опыт тоже есть в этом.
Вы преувеличиваете — за полдня не выйдет (10 раз за 5 дней).
А вот скопировать нужный функционал 1С с нуля за 5 дней — это совсем другое дело.
Профит заказчика в том, что он получает простую систему, в которую прикручивает нужный ему функционал CRM, KPI, долги физлиц и всё что угодно остальное без интеграции с дополнительными системами. Ровно в том виде, в каком нужно (и за ту же цену). Как раз со скоростью 1 система за полдня.
Тут мы подходим вплотную к тому, ради чего создан Интеграл. Коллеги выше не верят мне про возможности создать самодокументирующуюся систему, о чем будет моя следующая статья. Так вот, Интеграл позволяет описывать и экспортировать только бизнес-данные, без привязки к чему-либо чужеродному*, поэтому позволяет создавать что-то вроде ТЗ, которое можно распечатать единым документом и оно сразу будет работать.
* Функции языка SQL, которые можно использовать в отчетах, нужно будет описать для бизнеса, да, есть такое ограничение. Функции SUM, MIN, MAX, да пусть даже CONCAT вряд ли кого сильно озадачат. Ориентир по сложности восприятия у нас — MS Excel.
Логарифмическая зависимость, говорят же вам.
Вот так выглядит, например, тайминг импорта 4+ млн объектов в Интеграл, начиная с пустой базы — ведется подсчет вставленных записей каждые 15 секунд:
Сервер попутно еще загружен чем-то, поэтому всплески на графике. Еще при загрузке идет поиск родителя записи, там до 6 уровней иерархии.
Не «Hello, world!» и «table1 — table2», а что-то используемое людьми. За деньги.
Дистрибутив 1С для этой несложной задачи (Торговля и склад) весит 180МБ, потребует компьютер и настройки под себя руками специалиста. В результате, гипотетически, будет решен любой набор задач, если знаешь когда какую кнопку нажимать (а их в меню больше сотни). Практически же люди так и сидят с бумажками. Сложно им.
Простейший аналог в Интеграле не потребует ничего, кроме планшета или мобилы.
Выгрузка конфигурации — схема данных, отчеты, справочники — занимает меньше 15 КБ (так, к слову). Само программирование заготовки этого кустарного аналога заняло около 5 дней, и он точь-в-точь может воплотить требования среднего пользователя еще за 4-8 часов.
За 40 минут (мы пробовали) можно сделать импорт номенклатуры откуда угодно.
Интерактив клиентской части делается вне Интеграла (как хотите), а его шаблоны подгружаются в сервис.
Там написано в первом же абзаце, для чего этот сервис:
Всё, что создано в Интеграле, можно задокументировать бесконечным количеством способов, потому что вся информация хранится в базе или файлах (шаблонах) интерфейса.
В целях версионирования можно выгрузить все запросы и статические справочники во внутреннем формате Интеграла (по умолчанию) или преобразовать их в человеческий или машинный язык (да, придется пилить самому). Это такая фича — данные, метаданные и «код» хранятся в одной базе, могут быть преобразованы в нужный вид, модифицированы, сгенерированы автоматически или визардом (как выше описано про составные типы), загружены обратно и т.д.
Пока же наработок немного, поэтому я и не говорю, что матёрые программисты найдут здесь готовые решения. Но я аккуратно записываю всё, что мне здесь говорят, на будущее.
Сейчас это, в основном, сервис для «самых маленьких», кто работает в экселях, в одиночку, пока не имеет понятия о версионности и хочет сделать всё быстро и «на живую».
А интерактивные вещи быстрее и красивее делать руками нормальных дизайнера, верстальщика и программиста. Не конструктором же.
Про UI не совсем понятно, о чем. Вот так выглядит построение простых отчетов в приложении, без кода, но в некоторых случаях с применением арифметических формул:
www.youtube.com/watch?v=F_w5KvfmqzA&feature=youtu.be&t=210
Если сформулируете задачу про остатки, могу сделать тестовый стенд, как этот.
Да, к сервису также прикручен очень примитивный интерфейс, позволяющий сделать всё остальное. Он такой топорный, потому что задумка про архитектуру и подход, повторюсь.