Comments 29
Почему нельзя было обойтись настроенными представлениями (views) в базах данных, вместо файлов?.
Здравствуйте!
А в 1С Вы смотрели «Систему компоновки данных»?
А в 1С Вы смотрели «Систему компоновки данных»?
Здравствуйте!
Да, конечно. Я про 1С не могу ничего плохого сказать. У них хорошая система отчетов. Но для неподготовленного пользователя она сложна. У них нет различия, простой отчет или сложный, в любом случае пользователю придется иметь дело с конструктором запросов.
Смысл как раз в том, чтобы конструирования запросов избежать в простых случаях. А в сложных, простой пользователь все равно не сделает и придется программиста привлекать.
Да, конечно. Я про 1С не могу ничего плохого сказать. У них хорошая система отчетов. Но для неподготовленного пользователя она сложна. У них нет различия, простой отчет или сложный, в любом случае пользователю придется иметь дело с конструктором запросов.
Смысл как раз в том, чтобы конструирования запросов избежать в простых случаях. А в сложных, простой пользователь все равно не сделает и придется программиста привлекать.
Да, Вы правы, в сложных случаях без программиста все равно не обойтись.
Мне кажется это хорошая практика, изучать опыт других систем.
В 1С ERP (Это типовая конфигурация 1С, не бухгалтерия), в отчетах можно выделить 3 уровня:
Уровень разработчика это чистая система компоновки данных (СКД) где пользователю ничего не понятно.
На этом уровне задаются:
- Таблицы и связи этих таблиц между собой
- Поля, которые пользователь сможет использовать в отчетах
- Способы агрегации данных
- Дефолтные настройки и их варианты
- и много чего еще
Это рамки, которые задаются разработчиком отчета и за которые пользователь не сможет выйти при использовании отчета.
Уровень неопытного пользователя (простой режим)
На этом уровне пользователь может управлять только самым простым набором настроек, которые предусмотрел разработчик в одном из дефолтных вариантов. Как правило, это фильтры и сортировка, возможно еще включение выключение колонок отчета или простая настройка диаграммы
- Уровень опытного пользователя (расширенный режим)
В этом режиме пользователю доступны все возможности настроек СКД, но при этом в рамках тех таблиц и их связей, которые заданы на уровне разработчика.
Пользователь может произвольно переключаться между уровнями опытного и неопытного пользователя. Конечно неопытный пользователь в "расширенном режиме" может испортить себе отчет, но это легко исправляется наличием дефолтных настроек, к которым можно откатиться.
Я так понимаю, Ваш подход близок к 1С-ному?
Забавно, что Вы тоже к такому пришли.
Наверное да. Видимо схожие технические задачи находят схожие и технические решения. У них наверное тоже когда-то вставала такая проблема.
Только скорее у нас есть п.1 и п.2 из Вашего списка. Или простой редактор, или PL\SQL конфигуратор.
Увидел недавно, что в 1С есть «виртуальные таблицы» состоящие из нескольких реальных. Очень хорошая идея, которая решит некоторые проблемы. Думаю тоже такое сделаем.
Вообще у них все немного концептологически по другому устроено. Насколько я понимаю они в БД хранят только данные, а вся обработка данных выполняется в самой программе.
У нас несколько по другому. В базе хранятся не только данные, но и задается обработка этих данных, путем написания процедур и триггеров на PL\SQL. Благодаря такому решению, мы можем обрабатывать массивы информации на уровне БД, а не на уровне ПО. И думаю у нас благодаря этому проще получился сам компилятор. По сути, нам надо провести преобразование конфигурации пользователя в последовательность SQL команд. У них же (есть у меня подозрение) что переводится в сишные команды, а потом компилируется. Но я не знаю на самом деле как у них, это мои догадки. Может у них просто свой интерпретатор, который исполняет команды их внутреннего языка, но мне кажется это неэффективно будет с точки зрения быстродействия.
Есть у нас кое что и на уровне ПО конечно, например постройка интерфейса, проверка прав доступа и т.п. Но далеко не все.
Видимо поэтому им проще разработать сложный конфигуратор отчетов. А нам проще встроить в конфигуратор отчетов PL\SQL редактор и сразу же предоставить механизмы уровня разработчкика.
Вообще если есть здесь специалисты такого уровня по 1С, было бы интересно узнать как в 1С устроен язык программирования на машинном уровне. Это свой интерпритатор, или конфигурация во что-то компилируется.
Только скорее у нас есть п.1 и п.2 из Вашего списка. Или простой редактор, или PL\SQL конфигуратор.
Увидел недавно, что в 1С есть «виртуальные таблицы» состоящие из нескольких реальных. Очень хорошая идея, которая решит некоторые проблемы. Думаю тоже такое сделаем.
Вообще у них все немного концептологически по другому устроено. Насколько я понимаю они в БД хранят только данные, а вся обработка данных выполняется в самой программе.
У нас несколько по другому. В базе хранятся не только данные, но и задается обработка этих данных, путем написания процедур и триггеров на PL\SQL. Благодаря такому решению, мы можем обрабатывать массивы информации на уровне БД, а не на уровне ПО. И думаю у нас благодаря этому проще получился сам компилятор. По сути, нам надо провести преобразование конфигурации пользователя в последовательность SQL команд. У них же (есть у меня подозрение) что переводится в сишные команды, а потом компилируется. Но я не знаю на самом деле как у них, это мои догадки. Может у них просто свой интерпретатор, который исполняет команды их внутреннего языка, но мне кажется это неэффективно будет с точки зрения быстродействия.
Есть у нас кое что и на уровне ПО конечно, например постройка интерфейса, проверка прав доступа и т.п. Но далеко не все.
Видимо поэтому им проще разработать сложный конфигуратор отчетов. А нам проще встроить в конфигуратор отчетов PL\SQL редактор и сразу же предоставить механизмы уровня разработчкика.
Вообще если есть здесь специалисты такого уровня по 1С, было бы интересно узнать как в 1С устроен язык программирования на машинном уровне. Это свой интерпритатор, или конфигурация во что-то компилируется.
Вот я не знаю, работа вроде проведена большая… но исключительно по-моему мнению
ошиблись вектором.
Постоянно бродит по ИТ сообществу «призрак конструктора отчёта для неИТшника».
-А может не будем давать возможность водителю делать автомобиль, пусть просто рулит.
-Или пилоту конструировать самолёт.(Помимо знаний аэродинамики и механики, много ещё чего надо)
Так же как и нам… индексы план разбора… оптимизация sql.
Закончится тем, что Вы будите постоянно усложнять Ваш конструктор отчётов… увеличивая сложность вхождения в него.
Запаритесь консультировать «криворуких менеджеров».Сетуя на то, что быстрее сами бы сделали)
Потом добавите в свой конструктор sql(Ибо иначе не справится со всеми требованиями)… И будет это уже Ваш внутренний инструмент.
Тем более, что в каждой отрасти так или иначе существует отчётное насыщение.Вы просто будите подключать по требованию нужный отчёт из вашего отчётного репозитория кода.
ошиблись вектором.
Постоянно бродит по ИТ сообществу «призрак конструктора отчёта для неИТшника».
-А может не будем давать возможность водителю делать автомобиль, пусть просто рулит.
-Или пилоту конструировать самолёт.(Помимо знаний аэродинамики и механики, много ещё чего надо)
Так же как и нам… индексы план разбора… оптимизация sql.
Закончится тем, что Вы будите постоянно усложнять Ваш конструктор отчётов… увеличивая сложность вхождения в него.
Запаритесь консультировать «криворуких менеджеров».Сетуя на то, что быстрее сами бы сделали)
Потом добавите в свой конструктор sql(Ибо иначе не справится со всеми требованиями)… И будет это уже Ваш внутренний инструмент.
Тем более, что в каждой отрасти так или иначе существует отчётное насыщение.Вы просто будите подключать по требованию нужный отчёт из вашего отчётного репозитория кода.
Потом добавите в свой конструктор sql(Ибо иначе не справится со всеми требованиями)… И будет это уже Ваш внутренний инструмент.
В этом нет необходимости, у нас в отчеты можно встраивать процедуры, а для процедур уже есть редактор PL\SQL. Интерфейс отчетов сам по себе остается простым.
Я читал статью и помню про встраивание pl/sql, просто как только это произошло Ваш конструктор потерял формат «генератор отчётов для неИТшника».
Ну и вдогонку… не знаю какие у Вас отчёты просили менеджеры -аналитики… У меня… и со знаниеми sql просто «вынос мозга»… это и lag,lead это rollup,cube order dense rank… И конечно же «поворот» pivot(Причём надо ещё решить pivot делать на уровне СУБД(в частности oracle) позволяет или в генераторе отчётов… а ещё (есть поддержка js) сделать его интерактивным… по нажатию… что там раскрывалось…
К чему это всё я… просто отчёты, а особенно аналитические должны делать специально обученные люди.А «генератор отчётов для неИТшника»… это просто маркетинговый концепт.
Ну и вдогонку… не знаю какие у Вас отчёты просили менеджеры -аналитики… У меня… и со знаниеми sql просто «вынос мозга»… это и lag,lead это rollup,cube order dense rank… И конечно же «поворот» pivot(Причём надо ещё решить pivot делать на уровне СУБД(в частности oracle) позволяет или в генераторе отчётов… а ещё (есть поддержка js) сделать его интерактивным… по нажатию… что там раскрывалось…
К чему это всё я… просто отчёты, а особенно аналитические должны делать специально обученные люди.А «генератор отчётов для неИТшника»… это просто маркетинговый концепт.
SQL появился как язык запросов для не программистов...
Возможно не по теме, но у себя в конторе мы внедрили Jasper Reports
У коммерсантов радость полные штаны =)
У коммерсантов радость полные штаны =)
UFO just landed and posted this here
В 1С есть «Универсальный отчет», конечно там не все можно сделать, но в целом если человек с ним не смог разобраться, то ему уже ничего не поможет.
В итоге у вас получился довольно громоздкий и не особо прозрачный уникальный генератор отчетов.
С заметным порогом вхождения. Но почти вся реальная гибкость — в возможности привязать plsql процедуру.
При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
И все равно программизм прорывается (Параметр №2 Varchar_250).
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например). Продуманные, испытанные временем, с документацией, по котором есть чего погуглить.
С заметным порогом вхождения. Но почти вся реальная гибкость — в возможности привязать plsql процедуру.
При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
И все равно программизм прорывается (Параметр №2 Varchar_250).
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например). Продуманные, испытанные временем, с документацией, по котором есть чего погуглить.
При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
Согласен, это не совсем ясно, но к сожалению ширина экрана ограничена, хочется чтобы все влазило.
«COU» — сокращение от count. Вместо этого можно написать «количество элементов». Вместо «COU_D» можно написать «Количество уникальных элементов». Но вместо 5 букв будет 30 букв. Не удобно. Расползется все в ширь.
Для пояснения есть приписки, если навести мышку на заголовок столбца, то выскакивает пояснение.
Аналогично с сортировкой. Можно написать «Поле 2 сортировка обратная», а можно кратко «2 desc» и соотвественно пояснение что есть что.
В общем из-за экономии ширины экрана пришлось сделать так.
Посмотрим. Если будет прямо массовое непонимание — переименуем в длинное но более читаемое, это не проблема, 5 секунд.
И все равно программизм прорывается (Параметр №2 Varchar_250).
Да, вы правы тут. Давно очень делалось, когда конфигураторами отчетов еще и не пахло. Переименовал в более человеческое.
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например).
Не подойдет. Мы не можем пускать абы кого из интернета к исходникам наших баз. Плюс вы заставите писать пользователей SQL запросы в оригинальную базу, которой они не знают. Jasper Reports — хорошо для индивидуальной разработки в локальной сети.
а вы слышали вообще про Qlik, про Tableau? да хотя бы про DreamReport?
это разве не то? оно всё как раз для этого.
(я изумился вашему обращению к 1С в первую очередь — оно-то здесь каким вообще боком? какие там отчёты? там они ровно так же, как и в delphi и в прочих RAD)
это разве не то? оно всё как раз для этого.
(я изумился вашему обращению к 1С в первую очередь — оно-то здесь каким вообще боком? какие там отчёты? там они ровно так же, как и в delphi и в прочих RAD)
Не то.
Можно без проблем выгружать данные в Excel или в упомянутый Вами Tableau и анализировать как угодно. Надо только сначала эти данные получить. Вот получить можно при помощи конфигуратора отчетов и довольно удобным образом. Щелкнули «Ecxel» и пожалуйста, или откроете в экселе, или сохранить как csv и дальше этот же файл можно в Tableau загрузить.
Никто повторить функциональность Tableau не будет в здравом уме (если конечно нет цели войти именно в этот бизнес).
Далее вы не осознаете технических реалий конфигурируемых систем, тем более облачных.
Напрямую дать доступ к базе пользователя из BI системы просто бессмысленно. В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров. Пользователь просто не поймет что есть что, конфигурация системы знает что Задачи это таблица 49, а номер задачи поле в этой таблице с именем 568 и т.п. В общем не вариант. Вы видели когда-нибудь БД 1С?
В ERP-Платформе сырая база еще сложнее, т.к. там помимо хранения данных еще и обработка эти данных, автоматически созданные конфигурацией процедуры, триггеры, системы записи логов и передачи данных и т.п. Это будет как на ассемблере пытаться что-то анализировать… Пользователь общается со всем этим удобным образом через конфигурацию которая знает что есть что на машинном уровне. Пользователю выдает красивые названия и красивый интерфейс. Какие за этим стоят машинные телодвижения — пользователю фиолетово.
Попробуйте в Tableau подключить демо БД от 1С например?
Да и с точки зрения безопасности в облаке никто пускать к себе кого угодно напрямую не будет. В локальной версии еще можно, если это крупная компания и жесткие договорные рамки, но в облачной это просто небезопасно. Работать и выгружать-загружать данные можно только через интерфейс.
Tableau — для тех кто в рамках своей компании занимается разработкой своего продукта, есть своя БД и можно сделать аккаунт на Tableau и анализировать данные из своей БД.
В облачных версиях и в конфигурируемых пользователем системах такое не подходит.
Можно без проблем выгружать данные в Excel или в упомянутый Вами Tableau и анализировать как угодно. Надо только сначала эти данные получить. Вот получить можно при помощи конфигуратора отчетов и довольно удобным образом. Щелкнули «Ecxel» и пожалуйста, или откроете в экселе, или сохранить как csv и дальше этот же файл можно в Tableau загрузить.
Никто повторить функциональность Tableau не будет в здравом уме (если конечно нет цели войти именно в этот бизнес).
Далее вы не осознаете технических реалий конфигурируемых систем, тем более облачных.
Напрямую дать доступ к базе пользователя из BI системы просто бессмысленно. В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров. Пользователь просто не поймет что есть что, конфигурация системы знает что Задачи это таблица 49, а номер задачи поле в этой таблице с именем 568 и т.п. В общем не вариант. Вы видели когда-нибудь БД 1С?
В ERP-Платформе сырая база еще сложнее, т.к. там помимо хранения данных еще и обработка эти данных, автоматически созданные конфигурацией процедуры, триггеры, системы записи логов и передачи данных и т.п. Это будет как на ассемблере пытаться что-то анализировать… Пользователь общается со всем этим удобным образом через конфигурацию которая знает что есть что на машинном уровне. Пользователю выдает красивые названия и красивый интерфейс. Какие за этим стоят машинные телодвижения — пользователю фиолетово.
Попробуйте в Tableau подключить демо БД от 1С например?
Да и с точки зрения безопасности в облаке никто пускать к себе кого угодно напрямую не будет. В локальной версии еще можно, если это крупная компания и жесткие договорные рамки, но в облачной это просто небезопасно. Работать и выгружать-загружать данные можно только через интерфейс.
Tableau — для тех кто в рамках своей компании занимается разработкой своего продукта, есть своя БД и можно сделать аккаунт на Tableau и анализировать данные из своей БД.
В облачных версиях и в конфигурируемых пользователем системах такое не подходит.
Далее вы не осознаете
дальше всё бессмысленно.
Ну я например и вправду не осознавал, что всё так наворочено(и был ли смысл идти по пути одинэф… хотя это уже оффтоп)… и тогда и вправду Вы не имеете общего репозитория отчётов… или же их переброска затруднительна… тогда и вправду отпадают отчёты с поворотами, rollup и т.д… Тогда и вправду надо получить просто «сырые» данные и их уже загружать в другой отчётный инструментарий(Вот сомнительно для громкого имени ERP… такой «костылёчек»..)…
На самом деле путем 1С никто не шел. Я например базу 1С увидел постфактум и осознал что на самом деле схожие технические задачи просто находят схожие решения. Хотя системы по структуре на самом деле очень сильно отличаются. Чисто визуально базы схожи.
Я не очень люблю на эту тему дискутировать, пробовал уже, но сколько людей — столько и мнений и далеко не все с моим мнением согласны. Но тут как говорится жизнь покажет кто прав а кто нет. Надо просто молча работать над совершенствованием перспективных технологий, пока другие занимаются красивостью виджетов. А далее клиенты уже будут голосовать предпочтением.
У существующих облачных crm на мой взгляд есть очень существенный недостаток. Они не имеют гибкости. Бизнес-процессы они всегда специфичны и глупо всех подгонять под один интерфейс.
Так в целом у всех. Битрикс и КлиентскаяБаза попробовали сделать некую гибкость, предоставив возможность добавлять новые поля, но этого крайне мало. Нужно полностью иметь возможность менять любые элементы интерфейса, создавать любые таблицы, делать любые обработки данных. Причем индивидуально в каждом аккаунте, а не для всех. Только тогда crm система сможет удовлетворить компанию.
Но гибкая система это сложный путь. Надо сначала ее структурировать до мельчайших элементов. Сделать для нее внутренний язык программрования, на котором можно из этих элементов собрать конфигурацию. Обязательное условие, что вся конфигурация системы полность должна быть написана на этом внутреннем языке. Только тогда crm система сможет дать пользователю менять любой из кирпичиков из которых она состоит, или создавать новые конструкции из кирпичиков. Т.е. дать возможность менять интерфейсы, создавать новые структуры хранения данных, новые логики обработки данных.
В ERP-Платформе это в свое время было сделано, и не из соображений что вот есть гибкая 1С и мы тоже так хотим, а именно из соображений описанных выше. На 1С никто даже не смотрел, а смотрели на конкурентов и пытались сделать лучше их.
Сейчас в итоге во первых система может подстраиваться под любого пользователя, во вторых разработка нового идет намного быстрей ибо вместо php можно просто в конструкторе составлять систему.
Благодаря структуризации появился вот тот же конфигуратор отчетов. В обычной статичной crm такого просто не сделают, или сделают опять же статичный, и его надо будет допиливать при каждом изменении системы. А у нас система может меняться, при этом тот же конфигуратор отчетов менять не надо, он все поддерживает.
То же относится и к остальным модулям. На статичной системе где-то изменение сделал, во всех модулях системы это надо менять. У нас же можно сосредоточится на разработке отдельного модуля без заморочек на остальное, оно автоматически все изменения подхватит.
В общем сделать сложно, но в итоге вы увеличите скорость разработки, качество своих сервисов и если клиент попросит что-то подрегулировать под него, вы можете сказать: "Да, мы это можем. Без проблем!".
Да и концепция подтверждена смой жизнью. Как бы кто 1С не любил, но они непоколебимый мастадонт не просто так. По факту ими все пользуются. Каждая компания которую я знаю пользуется 1С. Их не любят из-за фактически монопольного положения, но при этом все равно пользуются и тратят на них деньги. Это потому что у них есть технология, которая позволяет делать индивидуальную подгонку под каждую компанию. Это решающий фактор.
Оглянитесь вокруг, такова жизнь. Кто владеет технологией легкой индивидуальной доработки — тот в будущем будет на коне.
Но это мое мнение. Я не претендую на то что я единственный тут вижу истину, может это не так. Но я думаю жизнь дальнейшая покажет, что выберут клиенты. Пока вот жизнь показывает что выбирают 1С.
Мы кстати с 1С не пытаемся конкурировать, они ушли очень далеко и это непоколебимая скала. Бухгалтерией нет планов заниматься. Но цель вписаться в нишу облачных crm — вполне посильная задача.
Я не думаю что простым менеджерам нужны отчеты с поворотами ) это скорее для продвинутых аналитиков надо. Но если прямо вот понадобится и будет востребовано — реализуем. Может быть сами реализуем, а может придумаем способ оптимальной передачи данных в систему которая это умеет. Но пока это не повестка дня.
Я не очень люблю на эту тему дискутировать, пробовал уже, но сколько людей — столько и мнений и далеко не все с моим мнением согласны. Но тут как говорится жизнь покажет кто прав а кто нет. Надо просто молча работать над совершенствованием перспективных технологий, пока другие занимаются красивостью виджетов. А далее клиенты уже будут голосовать предпочтением.
У существующих облачных crm на мой взгляд есть очень существенный недостаток. Они не имеют гибкости. Бизнес-процессы они всегда специфичны и глупо всех подгонять под один интерфейс.
Так в целом у всех. Битрикс и КлиентскаяБаза попробовали сделать некую гибкость, предоставив возможность добавлять новые поля, но этого крайне мало. Нужно полностью иметь возможность менять любые элементы интерфейса, создавать любые таблицы, делать любые обработки данных. Причем индивидуально в каждом аккаунте, а не для всех. Только тогда crm система сможет удовлетворить компанию.
Но гибкая система это сложный путь. Надо сначала ее структурировать до мельчайших элементов. Сделать для нее внутренний язык программрования, на котором можно из этих элементов собрать конфигурацию. Обязательное условие, что вся конфигурация системы полность должна быть написана на этом внутреннем языке. Только тогда crm система сможет дать пользователю менять любой из кирпичиков из которых она состоит, или создавать новые конструкции из кирпичиков. Т.е. дать возможность менять интерфейсы, создавать новые структуры хранения данных, новые логики обработки данных.
В ERP-Платформе это в свое время было сделано, и не из соображений что вот есть гибкая 1С и мы тоже так хотим, а именно из соображений описанных выше. На 1С никто даже не смотрел, а смотрели на конкурентов и пытались сделать лучше их.
Сейчас в итоге во первых система может подстраиваться под любого пользователя, во вторых разработка нового идет намного быстрей ибо вместо php можно просто в конструкторе составлять систему.
Благодаря структуризации появился вот тот же конфигуратор отчетов. В обычной статичной crm такого просто не сделают, или сделают опять же статичный, и его надо будет допиливать при каждом изменении системы. А у нас система может меняться, при этом тот же конфигуратор отчетов менять не надо, он все поддерживает.
То же относится и к остальным модулям. На статичной системе где-то изменение сделал, во всех модулях системы это надо менять. У нас же можно сосредоточится на разработке отдельного модуля без заморочек на остальное, оно автоматически все изменения подхватит.
В общем сделать сложно, но в итоге вы увеличите скорость разработки, качество своих сервисов и если клиент попросит что-то подрегулировать под него, вы можете сказать: "Да, мы это можем. Без проблем!".
Да и концепция подтверждена смой жизнью. Как бы кто 1С не любил, но они непоколебимый мастадонт не просто так. По факту ими все пользуются. Каждая компания которую я знаю пользуется 1С. Их не любят из-за фактически монопольного положения, но при этом все равно пользуются и тратят на них деньги. Это потому что у них есть технология, которая позволяет делать индивидуальную подгонку под каждую компанию. Это решающий фактор.
Оглянитесь вокруг, такова жизнь. Кто владеет технологией легкой индивидуальной доработки — тот в будущем будет на коне.
Но это мое мнение. Я не претендую на то что я единственный тут вижу истину, может это не так. Но я думаю жизнь дальнейшая покажет, что выберут клиенты. Пока вот жизнь показывает что выбирают 1С.
Мы кстати с 1С не пытаемся конкурировать, они ушли очень далеко и это непоколебимая скала. Бухгалтерией нет планов заниматься. Но цель вписаться в нишу облачных crm — вполне посильная задача.
тогда и вправду отпадают отчёты с поворотами, rollup и т.д
Я не думаю что простым менеджерам нужны отчеты с поворотами ) это скорее для продвинутых аналитиков надо. Но если прямо вот понадобится и будет востребовано — реализуем. Может быть сами реализуем, а может придумаем способ оптимальной передачи данных в систему которая это умеет. Но пока это не повестка дня.
«В конфигурируемых системах база данных не как обычно, а имена таблиц и полей состоят из номеров.»
Вот прям таки во всех без исключения? :)))
А статья хорошая — сразу понятен уровень «ERP-Платформы».
Вот прям таки во всех без исключения? :)))
А статья хорошая — сразу понятен уровень «ERP-Платформы».
Знаете, технологии обязывают.
Если в качестве уникальных идентификаторов вместо чисел будете использовать читаемые наименования — флаг вам в руки )
Поделитесь примером где это не так. Интересно.
Если в качестве уникальных идентификаторов вместо чисел будете использовать читаемые наименования — флаг вам в руки )
Поделитесь примером где это не так. Интересно.
Ну вот пример из навика:
Уровень конфигурируемости не скажу что высокий, но много простых задач можно сделать на уровне настроек.
CREATE TABLE [dbo].[Item Ledger Entry]( -----название таблицы осмысленное
[timestamp] [timestamp] NOT NULL,
[Entry No_] [int] NOT NULL, ----названия полей тоже понятные
[Item No_] [nvarchar](20) NOT NULL,
[Posting Date] [datetime] NOT NULL,
[Entry Type] [int] NOT NULL,
[Source No_] [nvarchar](20) NOT NULL,
[Document No_] [nvarchar](20) NOT NULL,
[Description] [nvarchar](50) NOT NULL,
[Location Code] [nvarchar](10) NOT NULL,
[Quantity] [decimal](38, 20) NOT NULL,
[Remaining Quantity] [decimal](38, 20) NOT NULL,
[Invoiced Quantity] [decimal](38, 20) NOT NULL,
[Applies-to Entry] [int] NOT NULL,
[Open] [tinyint] NOT NULL,
[Global Dimension 1 Code] [nvarchar](20) NOT NULL,
[Global Dimension 2 Code] [nvarchar](20) NOT NULL,
[Positive] [tinyint] NOT NULL,
[Source Type] [int] NOT NULL,
[Drop Shipment] [tinyint] NOT NULL,
[Transaction Type] [nvarchar](10) NOT NULL,
[Transport Method] [nvarchar](10) NOT NULL,
[Country_Region Code] [nvarchar](10) NOT NULL,
[Entry_Exit Point] [nvarchar](10) NOT NULL,
[Document Date] [datetime] NOT NULL,
[External Document No_] [nvarchar](35) NOT NULL,
[Area] [nvarchar](10) NOT NULL,
[Transaction Specification] [nvarchar](10) NOT NULL,
[No_ Series] [nvarchar](10) NOT NULL,
[Document Type] [int] NOT NULL,
[Document Line No_] [int] NOT NULL,
[Order Type] [int] NOT NULL,
[Order No_] [nvarchar](20) NOT NULL,
[Order Line No_] [int] NOT NULL,
[Dimension Set ID] [int] NOT NULL,
[Assemble to Order] [tinyint] NOT NULL,
[Job No_] [nvarchar](20) NOT NULL,
[Job Task No_] [nvarchar](20) NOT NULL,
-----пропущено много других полей
CONSTRAINT [Item Ledger Entry$0] PRIMARY KEY CLUSTERED
(
[Entry No_] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
Уровень конфигурируемости не скажу что высокий, но много простых задач можно сделать на уровне настроек.
Что такое «навик»? Не знаю такого.
Судя по тому что я вижу, это система с заложенной конфигурацией, а не произвольной. Т.е. можно менять только в рамках настроек существующих полей. Или вы можете добавить в интерфейсе какое либо поле [Transaction Type] и оно появится в этой таблице, или в другой если в другой добавите? А если на русском напишите? А как триггер будите компоновать на машинном уровне? Например надо пользователю сделать действие какое-то в другой таблице при апдейте этого поля. «Навик» такое может?
Для системы Вы этим усложните цепочку действий, ей вместо того чтобы подставить ID надо будет по этому ID вычислить наименование поля и подставить его. Вы усложните кучу операций, кучу переборов. Вы столкнетесь с проблемой уникальных наименований, и еще с неизвестно с чем. Наверняка возникнет море дополнительных сложностей.
И кстати каждая дополнительная операция — потеря быстродействия системы, что тоже очень важно.
Осмысленные наименования на машинном уровне — это зло. Это нужно только людям. Я проходил через решения всех этих проблем. Даже без этого было море проблем о которых и предположить изначально было нельзя. Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому. Только с 3 версии получилась боевая программа, которая позволила все сделать.
Судя по тому что я вижу, это система с заложенной конфигурацией, а не произвольной. Т.е. можно менять только в рамках настроек существующих полей. Или вы можете добавить в интерфейсе какое либо поле [Transaction Type] и оно появится в этой таблице, или в другой если в другой добавите? А если на русском напишите? А как триггер будите компоновать на машинном уровне? Например надо пользователю сделать действие какое-то в другой таблице при апдейте этого поля. «Навик» такое может?
Для системы Вы этим усложните цепочку действий, ей вместо того чтобы подставить ID надо будет по этому ID вычислить наименование поля и подставить его. Вы усложните кучу операций, кучу переборов. Вы столкнетесь с проблемой уникальных наименований, и еще с неизвестно с чем. Наверняка возникнет море дополнительных сложностей.
И кстати каждая дополнительная операция — потеря быстродействия системы, что тоже очень важно.
Осмысленные наименования на машинном уровне — это зло. Это нужно только людям. Я проходил через решения всех этих проблем. Даже без этого было море проблем о которых и предположить изначально было нельзя. Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому. Только с 3 версии получилась боевая программа, которая позволила все сделать.
Навик — это MS NAV. Очень существенная доля рынка в Европе среди SMB.
Вообще, начинать статью надо было с этого: «Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому.»
Сразу бы стало понятно — очередное изобретение велосипеда. :)))
И вы не поверите, но ЕРП системы в целом и отчеты в частности — нужны только людям. :)))
Вообще, начинать статью надо было с этого: «Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому.»
Сразу бы стало понятно — очередное изобретение велосипеда. :)))
И вы не поверите, но ЕРП системы в целом и отчеты в частности — нужны только людям. :)))
Навик — это MS NAV. Очень существенная доля рынка в Европе среди SMB.
Про MS NAV ничего не могу сказать. Не видел. Сейчас только погуглив составил мнение какое-то.
Вообще, начинать статью надо было с этого: «Например 2 первые версии внутреннего языка были забракованы и выкинуты на помойку, потому что в какой-то момент приходило осознание что данный путь в никуда и надо были изначально строить все архитектурно по другому.»
Статья вообще не об этом. У нас зашел разговор про то что БД в системах с возможность внутреннего программирования будут человеконечитаемые базы. Их можно сделать человекочитаемыми, но с увеличением ресурсоемкости и усложнением системы.
Сразу бы стало понятно — очередное изобретение велосипеда. :)))
К чему про велосипед? Если Вы хотите чтобы Ваша система была гибкая, Вам придтся сделать возможность внутреннего программирования. И стандартный язык в облаке Вы не возьмете. О безопасности то тоже надо думать. Причем со всех сторон, докер например с доступом к исходникам тоже не выход если у вас закрытый исходный код ядра — вы его просто откроете в этом случае. IonCube Вам тоже не поможет. Во первых тогда теряется смысл возможности внутреннего программирования, во вторых говорят оно расшифровывается при желании. Обфускация тоже только затрудняет, и не более.
Реально в облаке можно давать программирование только через свой интерфейс. Где тут велосипед то? Это прямая необходимость для данной функциональности.
MS NAV — насколько я понял:
а) коробочная версия
б) не уверен что на их C/AL можно посмотреть код всей системы, иначе появилось бы много MS NAV… сто пудовоу у них ядро закрыто, а редактировать можно только конфигурацию.
К сожалению понятия не имею об их возможностиях по программированию базы, может они вообще стандартными средствами для баз предлагают пользоваться, ибо это коробка.
Но если все через интерфейс и у них стаяла примерно аналогичная задача и они для себя решали примерно аналогичные проблемы. Решили — респект! Но это совершенно не значит что их техническое решение для их системы можно где-то еще использовать. Можно использовать только как концепт.
И вы не поверите, но ЕРП системы в целом и отчеты в частности — нужны только людям. :)))
Верю, я об этом и писал статью…
Добрый день! Статья интересная, но не продукт. У меня вопрос — Чем вы будете лучше чем Excel? Если вы пытаетесь сделать продукт для менеджеров, то типовых отчетов вполне хватит, если для аналитиков, то ваш продукт будет бесполезен. В любой сфере есть своя специфика, которую не всегда можно типовой функционал подтянуть, Excel дает возможность использовать предустановленое кол-во функций различного рода + написать свою на VBA, сделать анализ, подтянуть данные почти из любого источника (включая API на wsdl) и делай с ними все что угодно… Не понимаю почему многие постоянно пытаются заново велосипед изобретать. Я без критики, вы проделываете несомненно огромную работу, но вопрос — вы построили конкретный портрет своего клиента, и нужен ли этому клиенту конструктор?
Добрый день!
1) Конструктор отчетов должен удовлетворять потребности руководителей малого-среднего звена, по получению интересующих управленческих данных на основе данных системы. Нельзя быть во всех областях специалистом и всего предусмотреть в типовых отчетах.
2) Конструктор отчетов должен удовлетворять потребности простого персонала, путем получения каких-то простых данных, которые не могут дать типовые отчеты или интерфейс системы. В том числе и путем модифицирования типовых отчетов.
3) Для аналитиков — возможность легкого получения набора данных из системы для загрузки в специализированные программы и последующего анализа там.
4) Собственно сама возможность для разработчиков быстрым и удобным образом составлять типовые отчеты и выполнять запросы клиентов.
1) Конструктор отчетов должен удовлетворять потребности руководителей малого-среднего звена, по получению интересующих управленческих данных на основе данных системы. Нельзя быть во всех областях специалистом и всего предусмотреть в типовых отчетах.
2) Конструктор отчетов должен удовлетворять потребности простого персонала, путем получения каких-то простых данных, которые не могут дать типовые отчеты или интерфейс системы. В том числе и путем модифицирования типовых отчетов.
3) Для аналитиков — возможность легкого получения набора данных из системы для загрузки в специализированные программы и последующего анализа там.
4) Собственно сама возможность для разработчиков быстрым и удобным образом составлять типовые отчеты и выполнять запросы клиентов.
.
В принципе, Вы удовлетворили моё техническое любопытство. :-)
Раз у Вас есть востребованность на практике… наверное оно и вправду надо.
Наверное мы находимся в разных измерениях в автоматизации учёта.(которые не пересекаются)
У меня(http://cis-pos.com/) фирмы мелкий и средний бизнес,- автоматизирую «хорька» HoReCa(Hotel Restoran,Cafe,Shop).
У меня тоже конструктор-компоновщик.(но база данных хардкодная
Типа у всех есть documenttitles и documentscontents,firms и т.д… отраслевой атрибутикой отличаются)… а вот логика представления CRUID это легко конфигурируемое.(Но порог вхождения выше)(Ну и свой генератор отчётов естественно, но для специалиста)
И вот востребованность конструктора отчёта в моей сфере попадает в формат
для:
«Благородного Атоса, это слишком много, а для графа ДеЛяФер слишком мало»…
Т.е простые отчёты покрываются существующим репозиторием отчётов… а сложные «вынос мозга»(у меня есть все те перечисленные случаи и плюс интерактивность)… надо делать специалисту.
Раз у Вас есть востребованность на практике… наверное оно и вправду надо.
Наверное мы находимся в разных измерениях в автоматизации учёта.(которые не пересекаются)
У меня(http://cis-pos.com/) фирмы мелкий и средний бизнес,- автоматизирую «хорька» HoReCa(Hotel Restoran,Cafe,Shop).
У меня тоже конструктор-компоновщик.(но база данных хардкодная
Типа у всех есть documenttitles и documentscontents,firms и т.д… отраслевой атрибутикой отличаются)… а вот логика представления CRUID это легко конфигурируемое.(Но порог вхождения выше)(Ну и свой генератор отчётов естественно, но для специалиста)
И вот востребованность конструктора отчёта в моей сфере попадает в формат
для:
«Благородного Атоса, это слишком много, а для графа ДеЛяФер слишком мало»…
Т.е простые отчёты покрываются существующим репозиторием отчётов… а сложные «вынос мозга»(у меня есть все те перечисленные случаи и плюс интерактивность)… надо делать специалисту.
Sign up to leave a comment.
Каким должен быть идеальный конфигуратор отчетов