Комментарии 434
интересно, у минусующих есть какие то аргументы кроме «я зарабатываю на внедрении 1С и нефиг тут альтернативы предлагать»
Я, например, на внедрении 1С не зарабатываю, но тоже бы минуснул, если бы карма позволяла :) Как-то оно… наивно выглядит. Вроде «а давайте запилим новую ОС, чтобы опенсурсная была и я вот предлагаю файловую систему нового типа».
Аргументы? Пожалуйста:
Давайте сразу к выводам перескочим.
> Итак, сухой остаток — выкинуть по возможности все, что не относится к бизнес логике, сделать простым и универсальным все, что можно
> сделать просто и универсально. На мой взгляд, такой подход единственно конкурентоспособен,
Вы всерьез считаете, что кого-то из потребителей учётных систем вообще хоть капельки волнует абстрактность/универсальность их внутренней архитектуры? Не, серьёзно? Какие проблемы потребителей решает, например, вот такой выподвёрт?
> Предлагается хранить все докуменнты в одной таблице в блобе, упакованными в XML.
> Отдельно — только общие поля, которые показываются в списках и журналах — номер документа, дата создания, автор, статус."
Какие проблемы создаёт, придумать несложно. Производительность будет хилая, возможность массовых обработок с помощью SQL пропадёт и т.д. А вот что решает?
Я вам открою секрет: потребителям надо:
а) актуальные формы и формулы. Как только законодатели родят новую схему налогообложения или новые формы отчётности, они должны попасть в эту систему.
б) удобный и привычный интерфейс. Который преподают на курсах бухгалтеров
в) наличие специалистов и компаний-саппортеров
Вот это их интересует, а не очередной самодельный гибкий универсальный всеобъемлющий ORM.
Аргументы? Пожалуйста:
Давайте сразу к выводам перескочим.
> Итак, сухой остаток — выкинуть по возможности все, что не относится к бизнес логике, сделать простым и универсальным все, что можно
> сделать просто и универсально. На мой взгляд, такой подход единственно конкурентоспособен,
Вы всерьез считаете, что кого-то из потребителей учётных систем вообще хоть капельки волнует абстрактность/универсальность их внутренней архитектуры? Не, серьёзно? Какие проблемы потребителей решает, например, вот такой выподвёрт?
> Предлагается хранить все докуменнты в одной таблице в блобе, упакованными в XML.
> Отдельно — только общие поля, которые показываются в списках и журналах — номер документа, дата создания, автор, статус."
Какие проблемы создаёт, придумать несложно. Производительность будет хилая, возможность массовых обработок с помощью SQL пропадёт и т.д. А вот что решает?
Я вам открою секрет: потребителям надо:
а) актуальные формы и формулы. Как только законодатели родят новую схему налогообложения или новые формы отчётности, они должны попасть в эту систему.
б) удобный и привычный интерфейс. Который преподают на курсах бухгалтеров
в) наличие специалистов и компаний-саппортеров
Вот это их интересует, а не очередной самодельный гибкий универсальный всеобъемлющий ORM.
Вы всерьез считаете, что кого-то из потребителей учётных систем вообще хоть капельки волнует абстрактность/универсальность их внутренней архитектуры?
а что есть потребители которых волнует архитектура 1С?
Данная архитектура ориентирована на разработчиков а не потребителей.
поскольку без разработчиков все равно не обойтись то есть смысл
предложить решение гораздо более простое и саппорте чем 1С.
актуальные формы и формулы. Как только законодатели родят новую схему налогообложения или новые формы отчётности, они должны попасть в эту систему.
на практике \то попадает далеко не сразу а уж тем более не сразу попадает потребителю которому еще надо заплатить програмеру ха обновление.
б) удобный и привычный интерфейс. Который преподают на курсах бухгалтеров
веб интерфес не менее привычный. И он гораздо проще чем десятки пунктов меню на форме 1С. как то люди управляются с системами тиа Мой склад.
в) наличие специалистов и компаний-саппортеров
дело наживное.
> Данная архитектура ориентирована на разработчиков а не потребителей.
Значит, она мертворожденная по своей сути. Уж поверьте, невозможно убедить потребителя поменять учётную систему ради архитектуры. А разработчик не будет заниматься системой, которую он не сможет внедрить у клиента. Замкнутый круг.
> на практике \то попадает далеко не сразу а уж тем более не сразу попадает потребителю которому еще надо заплатить програмеру ха
> обновление.
На практике — попадает сразу всем клиентам, кроме тех, у которых конфигурация сильно кастомизирована.
> веб интерфес не менее привычный. И он гораздо проще чем десятки пунктов меню на форме 1С. как то люди управляются с системами
> тиа Мой склад.
Что значит «он гораздо проще»? Интерфейс несуществующей системы не может быть «проще» или «сложнее». Его вообще нет, и неизвестно, каким он будет. Если вы имеете в виду, что сам факт нахождения интерфейса программы в браузере сделает его гораздо проще, чем интерфейс 1С, то… вы сами к этому моменту, надеюсь, поняли, что это крайне нелепое утверждение?
Значит, она мертворожденная по своей сути. Уж поверьте, невозможно убедить потребителя поменять учётную систему ради архитектуры. А разработчик не будет заниматься системой, которую он не сможет внедрить у клиента. Замкнутый круг.
> на практике \то попадает далеко не сразу а уж тем более не сразу попадает потребителю которому еще надо заплатить програмеру ха
> обновление.
На практике — попадает сразу всем клиентам, кроме тех, у которых конфигурация сильно кастомизирована.
> веб интерфес не менее привычный. И он гораздо проще чем десятки пунктов меню на форме 1С. как то люди управляются с системами
> тиа Мой склад.
Что значит «он гораздо проще»? Интерфейс несуществующей системы не может быть «проще» или «сложнее». Его вообще нет, и неизвестно, каким он будет. Если вы имеете в виду, что сам факт нахождения интерфейса программы в браузере сделает его гораздо проще, чем интерфейс 1С, то… вы сами к этому моменту, надеюсь, поняли, что это крайне нелепое утверждение?
Значит, она мертворожденная по своей сути. Уж поверьте, невозможно убедить потребителя поменять учётную систему ради архитектуры
А зачем вообще произносить слово архитектура? Слово «бесплатная програма», «дешевый саппорт» и «возможность набивать заказы на планшете через инет» гораздо доходчивее.
Если вы имеете в виду, что сам факт нахождения интерфейса программы в браузере сделает его гораздо проще, чем интерфейс 1С,
Он проще потому что нет смысла его делать сложнее а не потому что он в браузере.
Интерфейс несуществующей системы не может быть «проще» или «сложнее». Его вообще нет, и неизвестно, каким он будет
Во первых есть и известно.
Во вторых в статье ДЛЯ ДЕВЕЛОПЕРОВ изложены принципы построения и решения недостатков 1С — а не расписано план что когда будет. Не волнуйте пока без работы не останетесь.
> А зачем вообще произносить слово архитектура? Слово «бесплатная програма», «дешевый саппорт» и
«возможность набивать заказы на планшете через инет» гораздо доходчивее.
Может, кто-то и клюнет. Хотя маркетинг так себе. Хорошие бесплатные учетные системы есть, но стоят они примерно столько же, сколько и платные. Если не произносить фразу «дешевый саппорт» — от этого любой мало-мальски вменяемый клиент убежит как от черта лысого.
> Он проще потому что нет смысла его делать сложнее а не потому что он в браузере.
Вы хотите сказать, что все те кнопочки/менюшки в учетных системах сделаны для усложнения интерфейса, а не потому, что это нужно бухгалтерам, операционистам, финансистам и т.д.?
> Во вторых в статье ДЛЯ ДЕВЕЛОПЕРОВ изложены принципы построения и решения недостатков 1С
Так в том же и вопрос — недостатки-то в чём? То, что там для добавления фич надо писать вот так, а тут вот этак — это просто факт, а не недостаток/преимущество. Ни по производительности, ни по простоте сопровождения конкретных данных нет.
> Не волнуйте пока без работы не останетесь.
Я не 1Сник. Я сейчас занимаюсь NAV и CRM-системами MS Dynamics и vTiger. Просто хотел за вашим энтузиазмом увидеть здравое зерно, но пока никак. Только «опенсурс», «сообщество напишет», «программисты PHP дешевые».
«возможность набивать заказы на планшете через инет» гораздо доходчивее.
Может, кто-то и клюнет. Хотя маркетинг так себе. Хорошие бесплатные учетные системы есть, но стоят они примерно столько же, сколько и платные. Если не произносить фразу «дешевый саппорт» — от этого любой мало-мальски вменяемый клиент убежит как от черта лысого.
> Он проще потому что нет смысла его делать сложнее а не потому что он в браузере.
Вы хотите сказать, что все те кнопочки/менюшки в учетных системах сделаны для усложнения интерфейса, а не потому, что это нужно бухгалтерам, операционистам, финансистам и т.д.?
> Во вторых в статье ДЛЯ ДЕВЕЛОПЕРОВ изложены принципы построения и решения недостатков 1С
Так в том же и вопрос — недостатки-то в чём? То, что там для добавления фич надо писать вот так, а тут вот этак — это просто факт, а не недостаток/преимущество. Ни по производительности, ни по простоте сопровождения конкретных данных нет.
> Не волнуйте пока без работы не останетесь.
Я не 1Сник. Я сейчас занимаюсь NAV и CRM-системами MS Dynamics и vTiger. Просто хотел за вашим энтузиазмом увидеть здравое зерно, но пока никак. Только «опенсурс», «сообщество напишет», «программисты PHP дешевые».
Вы хотите сказать, что все те кнопочки/менюшки в учетных системах сделаны для усложнения интерфейса, а не потому, что это нужно бухгалтерам, операционистам, финансистам и т.д.?
Типично для постсоветского разраба который лучше валенка-заказчика знает что тому нужно в его бизнесе…
Так в том же и вопрос — недостатки-то в чём?
в статье есть ссылка на соответствуюзую статью зачем повторятся
Кроме дополнительных отсутсвующих в 1С — кроспатформенность, модульность, открытый код, бесплатность, простота кодирования, веб интерфейс (не тот что в 1с а тот что нормально работает в мобильном устройсте)
. Я сейчас занимаюсь NAV и CRM-системами MS Dynamics и vTiger.
а зачем? Ведь 1С, по вашему, не имеет недостатков.
.
> Типично для постсоветского разраба который лучше валенка-заказчика знает что тому нужно в его бизнесе…
Критерий «мелкий и средний бизнес у нас сплошь и рядом пользуется 1С, а все её новоявленные конкуренты на рынке под лупой не заметны» вас чем не устраивает?
> Кроме дополнительных отсутсвующих в 1С — кроспатформенность, модульность, открытый код,
Эээ, а что, у 1С уже украли поддержку линукса, мобильные клиенты, модульность и закрыли код? Или вы раз увидели это в какой-то статье, то сразу поверили и приняли к действию?
> бесплатность
Для бизнес-пользователей? Зачем им это?
> простота кодирования
С каких это пор PHP стал проще, чем 1С?
> а зачем? Ведь 1С, по вашему, не имеет недостатков.
Потому что авторы этих систем, в отличие от вас, предлагают не воздушные замки крутых архитектур, а нужный клиентам функционал.
Критерий «мелкий и средний бизнес у нас сплошь и рядом пользуется 1С, а все её новоявленные конкуренты на рынке под лупой не заметны» вас чем не устраивает?
> Кроме дополнительных отсутсвующих в 1С — кроспатформенность, модульность, открытый код,
Эээ, а что, у 1С уже украли поддержку линукса, мобильные клиенты, модульность и закрыли код? Или вы раз увидели это в какой-то статье, то сразу поверили и приняли к действию?
> бесплатность
Для бизнес-пользователей? Зачем им это?
> простота кодирования
С каких это пор PHP стал проще, чем 1С?
> а зачем? Ведь 1С, по вашему, не имеет недостатков.
Потому что авторы этих систем, в отличие от вас, предлагают не воздушные замки крутых архитектур, а нужный клиентам функционал.
Критерий «мелкий и средний бизнес у нас сплошь и рядом пользуется 1С, а все её новоявленные конкуренты на рынке под лупой не заметны» вас чем не устраивает?
меня устраивает — мен все равно. Не устаривает многих пользователей у них нет ПОКА выбора.
С каких это пор PHP стал проще, чем 1С?
дело не в синтаксисе языка. А в том что написано в модулях и формах документов 1С. Я знаю что говорю — сам когда-то внедрял 7.7.
а нужный клиентам функционал.
То есть счета, накладные и прочая первичка ненужный фунционал? А шо тогда нужно владельцу малого бизнеса для учета.
> меня устраивает — мен все равно. Не устаривает многих пользователей у них нет ПОКА выбора.
Вы сейчас кривите душой. На самом деле вам надо было писать «мне кажется, что не устраивает многих пользователей». Потому что на самом деле 1С устраивает практически всех. Она дешёвая, простая, все бухгалтеры ей умеют пользоваться. Исключения бывают, но это именно исключения, а не «многие пользователи».
> дело не в синтаксисе языка. А в том что написано в модулях и формах документов 1С.
В вашей системе, если она будет развиваться, через пару лет будет то же самое.
Вы сейчас кривите душой. На самом деле вам надо было писать «мне кажется, что не устраивает многих пользователей». Потому что на самом деле 1С устраивает практически всех. Она дешёвая, простая, все бухгалтеры ей умеют пользоваться. Исключения бывают, но это именно исключения, а не «многие пользователи».
> дело не в синтаксисе языка. А в том что написано в модулях и формах документов 1С.
В вашей системе, если она будет развиваться, через пару лет будет то же самое.
Потому что на самом деле 1С устраивает практически всех.
а у них есть выбор?
В вашей системе, если она будет развиваться, через пару лет будет то же самое.
не будет. система модульная — нет никакой необходимости напихивать весь возможный функционал.
> а у них есть выбор?
Есть, конечно. Инфобухгалтер, Галактика, Акцент… уже не говоря про массу разного рода бесплатных изделий, в том числе и на php. Тот же vTiger, хоть и CRM по сути, но задачки «клиент-товар-заказ-счет-накладная» вполне решает.
Но какова их популярность в сравнении с 1С?
> система модульная — нет никакой необходимости напихивать весь возможный функционал.
Напихивать куда? В 1С тоже учет покупок, основных средств или там отчет «товар-оборотна ведомость» находятся в разных модулях, а не свалены в кучу. Функционал там разросся потому, что одному клиенту нужно вот в покупках расчет налогового кредита, другому клиенту раздельно финансовый, раздельно управленческий учет, третьему ещё что-то. Причем этих «что-то» тысяча и одна хрень, и в модуле закупок всё это учтено. И никуда их в другой модуль не выбросишь, ибо касается как раз закупок.
Есть, конечно. Инфобухгалтер, Галактика, Акцент… уже не говоря про массу разного рода бесплатных изделий, в том числе и на php. Тот же vTiger, хоть и CRM по сути, но задачки «клиент-товар-заказ-счет-накладная» вполне решает.
Но какова их популярность в сравнении с 1С?
> система модульная — нет никакой необходимости напихивать весь возможный функционал.
Напихивать куда? В 1С тоже учет покупок, основных средств или там отчет «товар-оборотна ведомость» находятся в разных модулях, а не свалены в кучу. Функционал там разросся потому, что одному клиенту нужно вот в покупках расчет налогового кредита, другому клиенту раздельно финансовый, раздельно управленческий учет, третьему ещё что-то. Причем этих «что-то» тысяча и одна хрень, и в модуле закупок всё это учтено. И никуда их в другой модуль не выбросишь, ибо касается как раз закупок.
Но какова их популярность в сравнении с 1С?
никакая. Потому и говорю — выбора нет
В 1С тоже учет покупок, основных средств или там отчет «товар-оборотна ведомость» находятся в разных модулях
там вообще дин модуль все — то что именуется конфигурацией.
я не ставлю задачу охватить весь сегмент перекрываемый 1С. Потому и не надо реализовывать все на все случаи жизни.
Да и 1с тоже не все равлизовывает потому и требует допиливания под клиента.
а раз надо допиливать то зачем все реализовывать? пусть програмер допилит только то что нужно не проираясь через километр исходников.
> никакая. Потому и говорю — выбора нет
А причина этого — в чём? Их разработчики не догадались сделать так хорошо, как догадались вы? Или может быть потому, что 1С просто покрывает бухгалтерские потребности подавляющего большинства клиентов, и они «проголосовали» своим выбором?
> там вообще дин модуль все — то что именуется конфигурацией.
Вообще, нет. Модульность на уровне функциональных компонент там есть. Другое дело, что там между ними есть связи, но… в вашем случае будет абсолютно то же самое.
> я не ставлю задачу охватить весь сегмент перекрываемый 1С.
> Потому и не надо реализовывать все на все случаи жизни.
Вы понимаете, что все эти «мелкие фичи» — они у всех клиентов разные. И потому их так много, что в чистом виде оно вообще мало кому понадобится. Ну найдете вы десяток-другой клиентов. Это того стоит?
А причина этого — в чём? Их разработчики не догадались сделать так хорошо, как догадались вы? Или может быть потому, что 1С просто покрывает бухгалтерские потребности подавляющего большинства клиентов, и они «проголосовали» своим выбором?
> там вообще дин модуль все — то что именуется конфигурацией.
Вообще, нет. Модульность на уровне функциональных компонент там есть. Другое дело, что там между ними есть связи, но… в вашем случае будет абсолютно то же самое.
> я не ставлю задачу охватить весь сегмент перекрываемый 1С.
> Потому и не надо реализовывать все на все случаи жизни.
Вы понимаете, что все эти «мелкие фичи» — они у всех клиентов разные. И потому их так много, что в чистом виде оно вообще мало кому понадобится. Ну найдете вы десяток-другой клиентов. Это того стоит?
Их разработчики не догадались сделать так хорошо, как догадались вы?Одна из причин. Мне бы их бабло. Впрочем их системы разрабытывались давно и морально устарели.
Ну найдете вы десяток-другой клиентов. Это того стоит?
это опенсорс проект
В отличие от остальных у меня нет цели сделать систему чтобы ее продавать за деньги. Я бы даже не брался за такое или устанавливал 1с как по молодости в начале нулевых…
> Одна из причин.
Самоуверенность, конечно же, это наверное хорошо :)
> это опенсорс проект
Делая опенсорсные приложения, все равно разработчик обычно хочет, чтобы ими пользовались. Тут вон целая армия айтишников показывает вам свой скепсис, но вы безапеляционно им возражаете: «Мой тысячепервый велосипед намного лучше, чем тысяча велосипедов, сделанных до него! Он обязательно победит!»
Самоуверенность, конечно же, это наверное хорошо :)
> это опенсорс проект
Делая опенсорсные приложения, все равно разработчик обычно хочет, чтобы ими пользовались. Тут вон целая армия айтишников показывает вам свой скепсис, но вы безапеляционно им возражаете: «Мой тысячепервый велосипед намного лучше, чем тысяча велосипедов, сделанных до него! Он обязательно победит!»
Мой тысячепервый велосипед намного лучше, чем тысяча велосипедов, сделанных до него! Он обязательно победит!
я не говорю что он победит. Но я говорю о технических решениях которые лучше. Причем лучше не по отдельности а именно в таком комплексе и взаимосвязи.
.
Вы предложили, например, для решения нетиповых задач поиск по текстовым документам:
> select from documents where details like '%вася пупкин %'
Например, этот запрос на выборку отгрузок по контрагенту у очень небольшой фирмы за год должен будет перелопатить несколько десятков мегабайт данных. Думаете, секунда потребуется?
> select from documents where details like '%вася пупкин %'
Например, этот запрос на выборку отгрузок по контрагенту у очень небольшой фирмы за год должен будет перелопатить несколько десятков мегабайт данных. Думаете, секунда потребуется?
думаю намного меньше. Шо такое несколько десятков мегабайт для mysql при линейной выборке для одной простой таблицы. Да он все это в память закинет и перелопатит в мгновение ока.
Опять же такие запросы — исключение — штатная работа ведется по таблице аналитики.
.
Опять же такие запросы — исключение — штатная работа ведется по таблице аналитики.
.
В реальности скорее больше. Ну вот простая математика — я сейчас смотрю на CRM небольшой фирмы, которая торгует разного рода лампочками/батарейками. Два товароведа, несколько продажников, бухгалтер, директор. Обычная «сферическая мелкая фирма в вакууме». Заказы — XML-документы, которые падают из EDI, и это как раз примерно то, что вы будете там хранить. Заказ в пару десятков позиций «весит» килобайт 20 ±. В день их около десятка. Заказ порождает как минимум накладную и счет. Итого полсотни килобайт на заказ, полмегабайта в день… и соответственно, полторы сотни мегабайт в год только на базовые торговые документы. Т.е. пересмотрите ваши прогнозы. Это узкое место у вас реально станет катастрофой, причём архитектурной, фундаментальной.
шо то до фига 20 кил на документ.
нет. Поиск по документам — это запасной вариант для экстренных случаев когда время выборки не будет иметь значения. Например как в 1с когда видишь в оборотно-сальдовой минус на остатке и начинаешь перерывать все документы откуда это минус нарисовался.
Штатная работа по таблице фактов.
Это узкое место у вас реально станет катастрофой, причём архитектурной, фундаментальной.
нет. Поиск по документам — это запасной вариант для экстренных случаев когда время выборки не будет иметь значения. Например как в 1с когда видишь в оборотно-сальдовой минус на остатке и начинаешь перерывать все документы откуда это минус нарисовался.
Штатная работа по таблице фактов.
> шо то до фига 20 кил на документ.
Ничего лишнего. Контрагент, наименование, способ оплаты, дата поставки, договор, валюта. И по товарам наименование, штрих-код, цена, единица измерения, количество, НДС, сумма. И всё это в тэгах.
Видите, даже про этот очевидный момент вы не в курсе.
> Поиск по документам — это запасной вариант для экстренных случаев
> когда время выборки не будет иметь значения.
А мне казалось, что это для тех случаев, когда ваша таблица фактов не позволяет сделать выборку, а не когда её время не имеет значения. Существенную разницу между первым и вторым видите?
А как вы в вашей таблице фактов будете хранить, например, такие факты как «применение оплаты к счетам»? У вас там отдельной строкой будет проводка по оплате, и отдельные строки — её применение к документам?
Ничего лишнего. Контрагент, наименование, способ оплаты, дата поставки, договор, валюта. И по товарам наименование, штрих-код, цена, единица измерения, количество, НДС, сумма. И всё это в тэгах.
Видите, даже про этот очевидный момент вы не в курсе.
> Поиск по документам — это запасной вариант для экстренных случаев
> когда время выборки не будет иметь значения.
А мне казалось, что это для тех случаев, когда ваша таблица фактов не позволяет сделать выборку, а не когда её время не имеет значения. Существенную разницу между первым и вторым видите?
А как вы в вашей таблице фактов будете хранить, например, такие факты как «применение оплаты к счетам»? У вас там отдельной строкой будет проводка по оплате, и отдельные строки — её применение к документам?
я в курсе — я вижу сколько занимает документ у меня в БД.
конечно десятки позиций займут столько места но обычно столько не набивают.
Закупка на склад может быть но продажи — обычно одна две позиции. Система не для супермаркетов.
в таблице документов есть отдельное поле — статус. Проведен, оплачен, утвержден и т.д.
конечно десятки позиций займут столько места но обычно столько не набивают.
Закупка на склад может быть но продажи — обычно одна две позиции. Система не для супермаркетов.
«применение оплаты к счетам»
в таблице документов есть отдельное поле — статус. Проведен, оплачен, утвержден и т.д.
таки провел проверку — сто тыщ доков с пятью позициями.
размер таблицы около 60 мегабайт
поиск LIKE по двум тегам отработал 4.9 сек.
но это на моем не первой свежести офисном компе с дефолтовой настройкой mysql.
на нормальном железе в секунду-две запросто впишется.
размер таблицы около 60 мегабайт
поиск LIKE по двум тегам отработал 4.9 сек.
но это на моем не первой свежести офисном компе с дефолтовой настройкой mysql.
на нормальном железе в секунду-две запросто впишется.
поиск LIKE по двум тегам отработал 4.9 сек.
Серьезно? На 60мб данных? Это, прямо скажем, отвратительно.
на офисном 32х компе с двумя ядрами и mysql под денвером
на нормальном серваке время будет сопоставимо с временем загрузки страницы.
опять же это запрос нештатный.
обычный запрос по таблице фактов = 0.05 сек
на нормальном серваке время будет сопоставимо с временем загрузки страницы.
опять же это запрос нештатный.
обычный запрос по таблице фактов = 0.05 сек
на офисном 32х компе с двумя ядрами и mysql под денвером
Да какая разница? Это неприемлемо медленно для СУБД.
на нормальном серваке время будет сопоставимо с временем загрузки страницы.
Угу, осталось понять, у всех ли заказчиков будут «нормальные серваки».
вы же на малый и средний бизнес ориентируетесь? Откуда у них «нормальные» серваки возьмутся? Скорее всего все это добро будет стоять на каком-нибудь десктопе с каким core i3.
Я не понимаю почему вы не понимаете очевидного. Ваша идея по совмещению реляционной модели и nosql не нова. Просто вместо кастылей обычно применяют чуть более разумные решения, вроде… часть данных хранится в mysql и для выборок агрегируются данные в другой СУБД которая больше для этого подходит. Всякие там elastic search идеально подходят для таких вещей.
Я не понимаю почему вы не понимаете очевидного. Ваша идея по совмещению реляционной модели и nosql не нова. Просто вместо кастылей обычно применяют чуть более разумные решения, вроде… часть данных хранится в mysql и для выборок агрегируются данные в другой СУБД которая больше для этого подходит. Всякие там elastic search идеально подходят для таких вещей.
вы же на малый и средний бизнес ориентируетесь?
в 1С кастомного поиска нет ВООБЩЕ. И как то ведут учет и даже захватили весь рынок. не понимаю откуда проблема.
часть данных хранится в mysql и для выборок агрегируются данные в другой СУБД
нет смысла делать проект пстым если там будут две субд. особенно если одна из них будет использоватся только по большим праздникам.
Скорее всего все это добро будет стоять на каком-нибудь десктопе с каким core i3.
а если туда 1С8 поставить? думаете быстрее моего добра работать будет?
я кстати тестировал вообще на
AMD Athlon(tm) II X2 250
Я никогда не работал с 1C8, но зато у меня есть опыт в проектировании архитектур систем автоматизации, CRM и прочем шлаке. И я не вижу ровным счетом никаких проблем с тем что бы организовать все адекватным образом без этих кастылей с xml и like.
в других архитектурах это были бы костыли. здесь нет — здесь оно в комплексе с остальными решениями. Тут костыли как раз nosql и прочие прибамбасы.
есть определенная идеология проекта и быстродействие тут не главное.
1с7.7 завоевала рынок используя как хранилище данных DBF файлы.
есть определенная идеология проекта и быстродействие тут не главное.
1с7.7 завоевала рынок используя как хранилище данных DBF файлы.
здесь нет — здесь оно в комплексе с остальными решениями.
Да те же костыли. Нет ровным счетом никаких аргументов ни за то, чтобы использовать псевдоструктурированные данные, ни за то, чтобы делать по ним поиск без использования встроенной функциональности СУБД.
аргументы есть — просто вы их услышать не хотите. Этот поиск — дополнительный бонус. В 1с работают и без него. Просто упаковка в XML вместо сериализации дает такую возможность — в журнале документов добавить поле для произвольного текста.
будет тормозить уберу и все.
.
будет тормозить уберу и все.
.
Просто упаковка в XML вместо сериализации дает такую возможность — в журнале документов добавить поле для произвольного текста.
Для поля для произвольного текста XML не нужен. Более того, в такой формулировке это ваше решение с XML не решает (простите) заявленную в посте задачу хранения разнородных документов в одной таблице.
будет тормозить уберу и все.
Без потери функциональности?
Для поля для произвольного текста XML не нужен.
тогда вернется много лишнего, особенно если буду какуюто цифру искать. в том то и суть что теги позволяют указать конкретное имя атрибута документа.
не решает (простите) заявленную в посте задачу хранения разнородных документов в одной таблице.
пока с теми документами что уже сделал (склад, закупки, продажи, малоценка) решает. не вижу пролбемы почему дальше не решит
Без потери функциональности?
функциональность — это поиск как дополнительная фича. Зато с сериализацией размер Бд буде меньше.
вообще поиск тут нужен не столко для пользователя сколько для внедренца — выискать какие то проблемные данные.
впрочем програмер может доки и по аналитике отсеять. Да, подумаю может таки сэкономлю размер БД, применив сериализацию. Пользаки все равно не запомнят что такое тэг в XML. просто текст, согласен и по сериализованому вернется. тем более что я пишу не только id а и названия бизнес сущностей.
кароче считайте что XML нет — а то вы наверно и по ночам не спите так переживаете :)
неважно. В статье это просто как идея которая может кому то пригодится в другой системе., в документообороте например. Для того и статья. Сериализация и так очевидное решение.
тогда вернется много лишнего, особенно если буду какуюто цифру искать.
Какую цифру? Мы же о произвольном тексте говорим.
пока с теми документами что уже сделал (склад, закупки, продажи, малоценка) решает.
И насколько различна структура тех документов, которые вы храните в одной таблице? Сколько их атрибутов хранится только в XML?
функциональность — это поиск как дополнительная фича
А я-то думал, что функциональность — это расширяемость атрибутивного состава документов без изменения структуры БД.
Сериализация и так очевидное решение.
Хранение в XML — это тоже сериализация. И да, это настолько очевидное решение, что у адекватных БД давно есть встроенная поддержка в том или ином виде, только вы ее игнорируете.
Какую цифру? Мы же о произвольном тексте говорим.
количество товара тоже текст но \то цифра
И насколько различна структура тех документов, которые вы храните в одной таблице? Сколько их атрибутов хранится только в XML?
ну, как например отличается договор, накладная и начисление амортизации.
хранятся все атрибуты кроме самых общих — номер дока, его тип, статус, общая сумма.
А я-то думал, что функциональность — это расширяемость атрибутивного состава документов без изменения структуры БД.
так и есть. Это ОСНОВНАЯ функциональность. Поиск как бонус.
Хранение в XML — это тоже сериализация.
имелась ввиду сериализация обьекта в PHP/
адекватных БД давно есть встроенная поддержка
да, только синтаксис разный. А я хочу сохранить переносимость. Как минимум на том уровне что обеспечивает ADODB
количество товара тоже текст но \то цифра
Нет, количество товара — это число.
хранятся все атрибуты кроме самых общих — номер дока, его тип, статус, общая сумма.
То есть, скажем, даты открытия/закрытия — хранятся только в XML?
так и есть. Это ОСНОВНАЯ функциональность
Из ваших объяснений так и не понятно, какой объем расширений вы планируете так поддерживать.
А я хочу сохранить переносимость.
Зачем?
Нет, количество товара — это число.
для аналитики — число, для просмотра и печати -текст
скажем, даты открытия/закрытия
для изменения состояния документа есть отдельная таблица аудита где хранятся оные даты.
хотя эти даты в вычислениях не учавтсвуют и вполне могут хранится только в XML
Из ваших объяснений так и не понятно, какой объем расширений вы планируете так поддерживать.
.с точки зрения документов — любой.
Зачем?
ну например внедренец захочет заюзать mssql или оракл. например у клиента уже будет один сервер БД он скажет на фига мне еще mysql
тем более это ничего не стоит — просто использовать правильно adodb
для аналитики — число, для просмотра и печати -текст
Всегда число. Оно в доменной модели число. То, что оно для печати форматируется как-то, на домен не влияет.
для изменения состояния документа есть отдельная таблица аудита где хранятся оные даты.
А если эта дата не входит в то, что вы считаете состоянием документа?
с точки зрения документов — любой.
Суммы и даты тоже?
например у клиента уже будет один сервер БД он скажет на фига мне еще mysql
У вас же легкая инсталляция, нет?
тем более это ничего не стоит — просто использовать правильно adodb
Это стоит как минимум тестирования на всех поддерживаемых БД. Вы это делаете?
Всегда число. Оно в доменной модели число. То, что оно для печати форматируется как-то, на домен не влияет.
это теоритизирование не имеет никакого отношения к конкретно этому проекту.
Суммы и даты тоже?
да.
мне надоело ходит по кругу ы хотите мнея гдле то подловить перекрестным допросом? Не тратьте время — я знаю что делаю
У вас же легкая инсталляция, нет?
да. и даже можно без инсталяции — скопировать WAMP сервер с проектом.
Но кто то возможно захочет внедрить там где mysql не подходит. Переносимость в данном случае не требует дополнительного кодирования. Это как бонус, так же как с поиском.
Это стоит как минимум тестирования на всех поддерживаемых БД. Вы это делаете?
Теоретически тестирование не нужно — это обеспечивает ADODB/ Но могут быть нюансы конечно.
В любом случае я не говорю что система переносима (я не создавал sql скрипты по другие БД) Я говорю что система может быть легко портируема на другой сервер БД. Теоретически — без изменения исходников. Но это не такая существенная фича чтобы тратить время на проверку.
это теоритизирование не имеет никакого отношения к конкретно этому проекту.
Имеет, и вполне конкретное. Это та самая проблема типизации, которую вы игнорируете.
Теоретически тестирование не нужно — это обеспечивает ADODB
Зато практически нужно (это говорит человек, который регулярно видит различные баги на системе, работающей с MySQL и MS SQL).
В любом случае я не говорю что система переносима (я не создавал sql скрипты по другие БД) Я говорю что система может быть легко портируема на другой сервер БД. Теоретически — без изменения исходников. Но это не такая существенная фича чтобы тратить время на проверку.
Пока эта «фича» не проверена, ее не существует.
в журнале документов добавить поле для произвольного текста
Может вам в сторону MongoDB посмотреть?
суть хорошей архитектуры в том, что с оной мы можем решить сильно позже, где и как будут храниться наши данные и как мы будем делать выборки.
В вашем случае вы сознательно на раннем этапе проектирования системы делаете конкретный выбор в сторону конкретного способа хранения данных и соответственно все проблемы связанные с этим закладываются в фундамент вашей архитектуры.
Поймите, я считаю что если это будет работать, то почему бы и да, тем более что производительность для вас на втором месте. Я просто не понимаю этой зацикленности, как будто бы это самая крутая штука в приложении. Но если мы планируем хорошую архитектуру, решение использовать xml + like или nosql хранилище мы должны принимать в последнюю очередь.
В вашем случае вы сознательно на раннем этапе проектирования системы делаете конкретный выбор в сторону конкретного способа хранения данных и соответственно все проблемы связанные с этим закладываются в фундамент вашей архитектуры.
Поймите, я считаю что если это будет работать, то почему бы и да, тем более что производительность для вас на втором месте. Я просто не понимаю этой зацикленности, как будто бы это самая крутая штука в приложении. Но если мы планируем хорошую архитектуру, решение использовать xml + like или nosql хранилище мы должны принимать в последнюю очередь.
вы тоже не хотите услышать — см коментарий выше. Забудте вообще про поиск.
упаковка в xml универсальное не зависящее от структуры документа способ хранить данные которые нужны не для вычислений а для обработки атрибутов документа. Все потроха тима имени и адреса кантрагента могу туда воткнуть и будет под руками при печати.
Для бизнес-данных — таблица фактов.
расширятся будет если когда то добавится новая бизнес-сущность в систему.
суть в том что в систему может быть добавлен любой документ или отчет без изменения структуры БД.
скопировал в папку сайта пару файлов прописал в пункт меню и все.
упаковка в xml универсальное не зависящее от структуры документа способ хранить данные которые нужны не для вычислений а для обработки атрибутов документа. Все потроха тима имени и адреса кантрагента могу туда воткнуть и будет под руками при печати.
Для бизнес-данных — таблица фактов.
расширятся будет если когда то добавится новая бизнес-сущность в систему.
суть в том что в систему может быть добавлен любой документ или отчет без изменения структуры БД.
скопировал в папку сайта пару файлов прописал в пункт меню и все.
суть в том что в систему может быть добавлен любой документ
Не может, если у него есть не-текстовые поля.
шо то не припомню учетных документов с нетекстовыми полями. как люди вели учет без компов?
кстати в системе предусмотрен атач стороних документов, pdf или сканов оригиналов например. как доп фича разумеетя. к хранению первички это не относится
кстати в системе предусмотрен атач стороних документов, pdf или сканов оригиналов например. как доп фича разумеетя. к хранению первички это не относится
шо то не припомню учетных документов с нетекстовыми полями.
Даты, суммы — нетекстовые поля. Связи с другими сущностями — семантически нетекстовые поля.
как люди вели учет без компов?
Медленно.
Даты, суммы — нетекстовые поля. Связи с другими сущностями — семантически нетекстовые поля.
в данном случае текстовые птому что используются как текст.
то что используется как суммы даты и ссылки — в таблице аналитики.
в данном случае текстовые птому что используются как текст.
То есть вы суммы складываете как текст (=конкатенируете)? По датам сортируете как по тексту (т.е., в лексикографическом порядке)?
то что используется как суммы даты и ссылки — в таблице аналитики.
То есть при добавлении в документ новой суммы/даты/ссылки — структура аналитической таблицы должна поменяться?
То есть вы суммы складываете как текст (=конкатенируете)? По датам сортируете как по тексту (т.е., в лексикографическом порядке)?
это выполняется в таблицах аналитики — там поля соответствующего типа.
структура аналитической таблицы должна поменяться?
с какого перепугу?
в аналитике хранятся движения по синтетическим и аналитическим счетам.
и по ним выполняются вычисления остатков и оборотов.
если это ссылка на товар, контрагента и т.д.
это будет измерение в таблице аналитики — оно там уже есть.
Если это какая то специфична дата/ссылка для документа она в нем и хранится в упакованом виде.
с какого перепугу?
С такого, что вы выше пишете, что даты и суммы хранятся в таблицах аналитики.
в аналитике хранятся движения по синтетическим и аналитическим счетам.
И больше ничего?
С такого, что вы выше пишете, что даты и суммы хранятся в таблицах аналитики.
в тех же полях независимо от типа документа
И больше ничего?
а больше ничего и не надо для УЧЕТНОЙ системы
.
а больше ничего и не надо для УЧЕТНОЙ системы
Видимо, у вас очень ограниченное понятие учетной системы. Например, для системы учета федерального имущества, находящегося в ведении правообладателя, нужно совсем другое.
для системы учета федерального имущества, находящегося в ведении правообладателя, нужно совсем другое.
Я не делаю проект для учета имущества.
Проект для бухгалтерского и складского учета в пределах стандартного функционала 1С. И уж точно не для федеральных органов.
вы бы еще андронный колайдер сюда приплели
А правообладателем федерального имущества не обязан быть федеральный орган. Более того, это имущество вполне может быть на складе.
Складской учет, говорите? А в складском учете бывают такие странные вещи как «Дата истечения срока годности» и «Предполагаемая дата следующей поставки». Их вы как предлагаете обрабатывать?
Складской учет, говорите? А в складском учете бывают такие странные вещи как «Дата истечения срока годности» и «Предполагаемая дата следующей поставки». Их вы как предлагаете обрабатывать?
так же как в 1С — никак.
Это задача кладовщика.
и не путайте учетную систему с планированием ресурсов.
Это задача кладовщика.
и не путайте учетную систему с планированием ресурсов.
Ну то есть заказчик, которому нужно, чтобы за его склад отвечала одна система, в ней велся складской учет (что бы вы под этим ни понимали), а так же учитывались сроки годности, на вашу платформу может не смотреть?
да, есть специфические типы учета
Например в аптеках.
Сам по себе учет никак не зависит от срока годности но програма должна преупреждать о том что такие товары есть и надо лезть на полку выкидывать их.
стандатно там и 1С не пойдет. Подпилить напильником -и я могу в принципе,
но зачем пытатся обьять необьятное.
рестораны тоже имеют свою специфику.
и что мне рецептуру блюд засовывать чтобы расходы считать?
.
Например в аптеках.
Сам по себе учет никак не зависит от срока годности но програма должна преупреждать о том что такие товары есть и надо лезть на полку выкидывать их.
стандатно там и 1С не пойдет. Подпилить напильником -и я могу в принципе,
но зачем пытатся обьять необьятное.
рестораны тоже имеют свою специфику.
и что мне рецептуру блюд засовывать чтобы расходы считать?
.
Вам — нет. Но платформа должна это позволять, причем без существенной потери производительности (как разработки, так и времени выполнения), чтобы разработчик, которому такая задача прилетела от бизнеса (или который решил покрыть этот сегмент бизнеса), смог это реализовать без костылей.
моя не должна
я не собираюсь перекрывать весь сегмент для 1с, CRM и прочего.
кому приспичит или хорошо заплатят — добавит поле в таблицу документов и все дела.
считайте что подпилить саму платформу — дополнительная фича, котрой нет у разрабов конфигураций 1С.
я исхожу из принципа Парето. Пусть остальные 20% остаются на 1С.
я не собираюсь перекрывать весь сегмент для 1с, CRM и прочего.
кому приспичит или хорошо заплатят — добавит поле в таблицу документов и все дела.
считайте что подпилить саму платформу — дополнительная фича, котрой нет у разрабов конфигураций 1С.
я исхожу из принципа Парето. Пусть остальные 20% остаются на 1С.
Между прочим, у 1С есть модуль учета имущества.
а больше ничего и не надо для УЧЕТНОЙ системы
Это все шикарно, но есть одна проблема. Как то раз нам заказали простенькую систему учета движения документов в административной комиссии. По ТЗ она задумывалась крайне просто: входящие, исходящие, внутренние и пара проводок — вот весь функционал. После года эксплуатации число запросов новых функций переросло в отдельное ТЗ, которое мы успешно закрыли. На следующий год история повторилась. К чему это я? Вы клиенту не сможете объяснить — простите, но это учетная система, тут такого сделать нельзя — клиент просто уйдет к конкуренту, у которого можно. Как думаете, почему 1С выпустили Битрикс? Ведь сайты для бухгалтеров тоже не край как нужны.
в вашем случае это система документооборота.
Я клиенту делаю то что делает бухгалтерская или складская учетная система. А битрикс это сорее инет магазин интегрированй с 1С она действительно не нужна бухгалтерам.
Она нужна тем у кого электронная комерция и ведение учета в 1С. А обмен данными сайтов с 1с — стандартный гемор — пройдитесь п форумам.
Я клиенту делаю то что делает бухгалтерская или складская учетная система. А битрикс это сорее инет магазин интегрированй с 1С она действительно не нужна бухгалтерам.
Она нужна тем у кого электронная комерция и ведение учета в 1С. А обмен данными сайтов с 1с — стандартный гемор — пройдитесь п форумам.
Да хоть тролейбусом это назовите. Клиент завтра вас спросит:
Вы ему скажате:
В лучшем случае клиент молча начнет искать новую систему в которой «можно».
Да не важно нужна она или нет, клиент скажет вам — надо — и вы должны ему это прикрутить, причем прямо в систему, чтоб и данные оттуда брало и новые кнопочки добавить можно было. Это не вопрос — зачем 1С выпустил Битрикс? — это вопрос — понимаете как клиенты запарили 1С, что они решились выпустить Битрикс?
дорогой мой caballero, мне нужно что вот здесь была кнопочка по нажатию на которую, система разашлет всем лицам из справочника «клиенты» поздравление с новым годом. Это можно сделать?
Вы ему скажате:
нет, ибо моя система на это не расчитана, если вам это нужно, купите вот еще эту и эту систему, и тогда это можно будет сделать.
В лучшем случае клиент молча начнет искать новую систему в которой «можно».
А битрикс это сорее инет магазин интегрированй с 1С она действительно не нужна бухгалтерам
Да не важно нужна она или нет, клиент скажет вам — надо — и вы должны ему это прикрутить, причем прямо в систему, чтоб и данные оттуда брало и новые кнопочки добавить можно было. Это не вопрос — зачем 1С выпустил Битрикс? — это вопрос — понимаете как клиенты запарили 1С, что они решились выпустить Битрикс?
В лучшем случае клиент молча начнет искать новую систему в которой «можно».
если рассылка поздравлений — основная функция системы то ему не ко мне.
Но в принципе можно. напишу обработку на крон пройдет по справочнику и разошлет.
Еще раз — стандартный функционал у меня не выходит за рамки СТАНДАРТНОГО функционала 1С.
Написать специальный код который че то там делает можно. Так же как и там.
Возможно будет работать неоптимально и медленно — так же как и в 1с от которой пока никто не отказался потому что нельзя разослать открытки клиентам.
если рассылка поздравлений — основная функция системы
Не основная, возможно клиент даже пользоваться ей не будет, просто он увидил у «соседа» эту функцию и тоже хочет.
Возможно будет работать неоптимально и медленно — так же как и в 1с от которой пока никто не отказался потому что нельзя разослать открытки клиентам
А зачем отказываться когда можно за пару тысяч допилить нужный функционал, благо платформа это позволяет и разработчиков уйма )
Ого, длинная ветка комментария получилась. Не буду по статье, так как ниже вероятно уже перемололи косточки, а остановлюсь только на ваших ошибках в этом треде.
Это кто не набивает? Если мы говорим не про бизнес, а про посетителя интернет магазина, то он в своем заказе действительно редко набивает больше 5-6 позиций. А теперь не смотрим на на средний бизнес, а переходим сразу к самым маленьким. Выйдите в киоск под домом за сигаретами/кофем/жвачкой/сникерсом или что вы там обычно покупаете — обратите внимание на разнообразие ассортимента в каждой из категорий; все это добро завозят в киоски в течении недели по несколько раз, но не смотря на это в накладных все равно десятки позиций. У классического мелкого дистрибютора (купил на заводе, развез по магазинам) по несколько сотен заказов в день, в каждом из которых до 20 позиций.
Из бизнеса, которому достаточно документооборота с количеством позиций меньше десяти мне приходят на ум только дорогие бутики, где 10 консультантов, 3 пары женской обуви, 2 сумочки и шарфик, но им даже 1С не подходит (не говоря про ваш опенсорс) — только SAP/R3!
Вы упоминали, что программировали 15 лет назад на 1С7.7. Видимо с тех пор вообще никаких новостей не видели. Универсальный поиск на формах списков появился еще в 8.0, а в 8.1 появился разухабистый полнотекстовый поиск по всем реквизитам объектов (включая реквизиты табличных частей) — последний использует не просто прямое символьное соответствие, а позволяет задавать правила поиска, использует спецсимволы и ключевые слова, а так же ищет по синонимам — делалось по аналогии с поиском информации в яндексе/гугле.
На счет стандартного функционала — только по платформе: работа из коробки под Windows и Linux серверами; наличие 32- и 64-битных сборок, легкая публикация на веб-серверах IIS и Apache, кросс-браузерность, наличие мобильных клиентов под Android, iOs и Windows, использование в качестве СУБД MsSQL, PostgreSQL, IBM DB2 и Oracle. Перечислять же стандартный функционал для разработки прикладных решений и дня не хватит, но пусть тут будет парочка: на базе указанного программистом источника данных, платформа сама генерирует форму отчета, его внешний вид и дает пользователю возможность управлять группировками, сортировками и оформлением; к платформе можно подключить произвольный источник данных, к которому есть ODBC-драйвер, и далее пользователь может работать с данными любой внешней таблицы как со справочником — добавлять/редактировать/удалять произвольные записи, а так же использовать эти значения в реквизитах родных справочников и документов конфигурации.
Планирование ресурсов — это одна из задач учетной системы. В самой первой конфигурации, которую 1С написали, что бы отладить платформу 8.0 (я про УПП 1.0) это уже было реализовано и далее только дорабатывалось.
Неужели вы не видите, как сами себе противоречите? 1С и их партнеры «насочиняли» сотни разных конфигураций для тех же аптек и общепитов, именно для того что бы пользователи могли сесть за рабочее место и им все было понятно и очевидно — только нужные документы, только нужные отчеты, только нужные кнопочки на формах. И никакой путаницы! В результате для конечного потребителя получается очень дешево — вместо того, что бы платить программистам за обучение предметной области, за разработку «велосипеда», за исправление багов, владелец бизнеса просто покупает готовое решение, которое используется уже у сотен тысяч его конкурентов по всей стране и приносит им прибыль (а еще можно сотрудников переманивать, которых даже переучивать не нужно).
я в курсе — я вижу сколько занимает документ у меня в БД.
конечно десятки позиций займут столько места но обычно столько не набивают.
Это кто не набивает? Если мы говорим не про бизнес, а про посетителя интернет магазина, то он в своем заказе действительно редко набивает больше 5-6 позиций. А теперь не смотрим на на средний бизнес, а переходим сразу к самым маленьким. Выйдите в киоск под домом за сигаретами/кофем/жвачкой/сникерсом или что вы там обычно покупаете — обратите внимание на разнообразие ассортимента в каждой из категорий; все это добро завозят в киоски в течении недели по несколько раз, но не смотря на это в накладных все равно десятки позиций. У классического мелкого дистрибютора (купил на заводе, развез по магазинам) по несколько сотен заказов в день, в каждом из которых до 20 позиций.
Из бизнеса, которому достаточно документооборота с количеством позиций меньше десяти мне приходят на ум только дорогие бутики, где 10 консультантов, 3 пары женской обуви, 2 сумочки и шарфик, но им даже 1С не подходит (не говоря про ваш опенсорс) — только SAP/R3!
в 1С кастомного поиска нет ВООБЩЕ. И как то ведут учет и даже захватили весь рынок. не понимаю откуда проблема.
Еще раз — стандартный функционал у меня не выходит за рамки СТАНДАРТНОГО функционала 1С.
Вы упоминали, что программировали 15 лет назад на 1С7.7. Видимо с тех пор вообще никаких новостей не видели. Универсальный поиск на формах списков появился еще в 8.0, а в 8.1 появился разухабистый полнотекстовый поиск по всем реквизитам объектов (включая реквизиты табличных частей) — последний использует не просто прямое символьное соответствие, а позволяет задавать правила поиска, использует спецсимволы и ключевые слова, а так же ищет по синонимам — делалось по аналогии с поиском информации в яндексе/гугле.
На счет стандартного функционала — только по платформе: работа из коробки под Windows и Linux серверами; наличие 32- и 64-битных сборок, легкая публикация на веб-серверах IIS и Apache, кросс-браузерность, наличие мобильных клиентов под Android, iOs и Windows, использование в качестве СУБД MsSQL, PostgreSQL, IBM DB2 и Oracle. Перечислять же стандартный функционал для разработки прикладных решений и дня не хватит, но пусть тут будет парочка: на базе указанного программистом источника данных, платформа сама генерирует форму отчета, его внешний вид и дает пользователю возможность управлять группировками, сортировками и оформлением; к платформе можно подключить произвольный источник данных, к которому есть ODBC-драйвер, и далее пользователь может работать с данными любой внешней таблицы как со справочником — добавлять/редактировать/удалять произвольные записи, а так же использовать эти значения в реквизитах родных справочников и документов конфигурации.
так же как в 1С — никак. Это задача кладовщика.
и не путайте учетную систему с планированием ресурсов.
Планирование ресурсов — это одна из задач учетной системы. В самой первой конфигурации, которую 1С написали, что бы отладить платформу 8.0 (я про УПП 1.0) это уже было реализовано и далее только дорабатывалось.
да, есть специфические типы учета
Например в аптеках…
рестораны тоже имеют свою специфику.
и что мне рецептуру блюд засовывать чтобы расходы считать?
там ща наплодили десятки конфигураций которые друг друга на три четверти дублируют но почему то отличаются внутренним интерфейсом.
Одна из причин почему стало сложнее и дороже с 1С.
С семеркой было гораздо проще.
Неужели вы не видите, как сами себе противоречите? 1С и их партнеры «насочиняли» сотни разных конфигураций для тех же аптек и общепитов, именно для того что бы пользователи могли сесть за рабочее место и им все было понятно и очевидно — только нужные документы, только нужные отчеты, только нужные кнопочки на формах. И никакой путаницы! В результате для конечного потребителя получается очень дешево — вместо того, что бы платить программистам за обучение предметной области, за разработку «велосипеда», за исправление багов, владелец бизнеса просто покупает готовое решение, которое используется уже у сотен тысяч его конкурентов по всей стране и приносит им прибыль (а еще можно сотрудников переманивать, которых даже переучивать не нужно).
вы не первый здесь кто пытается доказать что 1с решает все проблемы, решает дешево, не имеет недостатков и сколько не ройся по бухгалтерским форумам не найдешь ни одного пользователя который бы жаловался на 1С.
Не будем начинать дискусию по второму кругу.
Не будем начинать дискусию по второму кругу.
Еще раз — стандартный функционал у меня не выходит за рамки СТАНДАРТНОГО функционала 1С.
Какой из конфигураций 1С? Срок годности товара входил в базовую конфигурацию «торговля и склад» ещё в 7.7, за счет чего она, кстати, вытеснила многих конкурентов.
xml поля с xpath запросами — это и есть чистой воды nosql. Вопрос выбора хранить документы или в xml в postgre, или в xml в basex, или в json в postgre, или в json в mongo — это вопрос выбора костыля, если основная база реляционная.
Тупое = у мускуля по текстовому полю на однобайтовом значении на порядка 50 млн записей (средний бизнес за 5 лет нагенерировал фктов) занял вот прямо сейчас специально для вас на сервере с 32 гигами оперативки больше минуты.
Поддержка xpath на уровне запросов лишь синтаксический сахар по сути для поиска по текстовому полю, куда важнее поддержка его на уровне индексов, чтобы не было фулл-скана таблицы.
Поддержка xpath на уровне запросов лишь синтаксический сахар по сути для поиска по текстовому полю, куда важнее поддержка его на уровне индексов, чтобы не было фулл-скана таблицы.
и часто вы ищете по документам за пять лет?
в реальности разумеется будет выбран какой то период за последнее время. Ну и тип документа будет указан а не тупо по всем подряд
а если уж кому надо найти документ из его молодости то уж как нибудь минуту подождет
в реальности разумеется будет выбран какой то период за последнее время. Ну и тип документа будет указан а не тупо по всем подряд
а если уж кому надо найти документ из его молодости то уж как нибудь минуту подождет
В общето «open source» вполне себе может быть «за деньги». Открытое ПО != бесплатное ПО
Открытое ПО != бесплатное ПО
да, один из вариантов монетизации
можно зарабатывать на внедрении, саппорте, консультациях, посещении оф. сайта проекта, какое нибудь хитрое лицензироание т.д.
Иногда это просто имя в айтишном мире с вытекающим отсюда возможностями. вариантов много. Че об этом думать, сначала надо проект до ума довести.
Если бы я бросил работу и вложил кучу бабла в проект тогда бы переживал по этому поводу.
НЛО прилетело и опубликовало эту надпись здесь
Вот что я только что прочитал?
Нет, честно. Давайте уже смеритесь с тем, что 1С — решает бизнес логику, а всякие вои там веб интерфейсы вы можете приклееть к 1С через http сервисы, даже протокол OData есть. И лепите себе там всякое, что душа пожелает.
Но оставьте в покое 1С. Вы все время говорите о том, что 1С крупная компания и с ней нет смысла тягаться, но тягаетесь, так как всегда ставите заведомо 1С на равне с вашим решением.
Например, про программиста и счета — позвать 1С программиста и php — это как бы разные вещи.
Поймите наконец, у 1С преимущество не в платформе, отчетностях, деньгах. А в том, что у 1С армия разработчиков, т.е. вы в любом захолустье найдете программиста 1С.
А у всех аналогов 1С — один ключевой недостаток, причем для клиентов — если ваш проект аналогов загнется, то клиент будет просто у разбитого корыта.
Плюс — обучение и т.д. Вот сила 1С, а не ее конфигуратор, или гибкость/не гибкость.
Нет, честно. Давайте уже смеритесь с тем, что 1С — решает бизнес логику, а всякие вои там веб интерфейсы вы можете приклееть к 1С через http сервисы, даже протокол OData есть. И лепите себе там всякое, что душа пожелает.
Но оставьте в покое 1С. Вы все время говорите о том, что 1С крупная компания и с ней нет смысла тягаться, но тягаетесь, так как всегда ставите заведомо 1С на равне с вашим решением.
Например, про программиста и счета — позвать 1С программиста и php — это как бы разные вещи.
Поймите наконец, у 1С преимущество не в платформе, отчетностях, деньгах. А в том, что у 1С армия разработчиков, т.е. вы в любом захолустье найдете программиста 1С.
А у всех аналогов 1С — один ключевой недостаток, причем для клиентов — если ваш проект аналогов загнется, то клиент будет просто у разбитого корыта.
Плюс — обучение и т.д. Вот сила 1С, а не ее конфигуратор, или гибкость/не гибкость.
во первых проект опенсорс. Гораздо хуже сидеть «на игле» у 1С и платить бабло за каждое изменение или ждать пока дистрибутор выпустит обновление. И хорошо если не менял чтото в конфигурации иначе плати програмерам чтобы мержили…
Во вторых что это за аргумент — армия разработчиков? Зачем придумали яву — на С++ армия разработчиков. Зачем придумали PHP — на яве — армия разработчиков. Заем придумали опенофис — с майкрософтом тягаться вздумали?
Во вторых что это за аргумент — армия разработчиков? Зачем придумали яву — на С++ армия разработчиков. Зачем придумали PHP — на яве — армия разработчиков. Заем придумали опенофис — с майкрософтом тягаться вздумали?
А разве 1С скрывает исходники своих конфигураций? Это тоже опенсорс, хоть и проприетарный.
> И хорошо если не менял чтото в конфигурации иначе плати програмерам чтобы мержили…
В предлагаемом вами решении саппорт/кастомизация ведь не бесплатные будут, верно? Это тоже работа программеров.
> И хорошо если не менял чтото в конфигурации иначе плати програмерам чтобы мержили…
В предлагаемом вами решении саппорт/кастомизация ведь не бесплатные будут, верно? Это тоже работа программеров.
возможно и бесплатно — например будет комунити которое на гитхабе оперативно скоректирует логику после изменения законодательства. А заменить отдельный файл в приложении не составит труда даже среднему юзеру.
Но даже если небесплатно — веб програмер гораздо дешевле програмера 1С. С учетом что изменения вносить проще (изза простоты системы) — еще в два раза дешевле.
Но даже если небесплатно — веб програмер гораздо дешевле програмера 1С. С учетом что изменения вносить проще (изза простоты системы) — еще в два раза дешевле.
> Но даже если небесплатно — веб програмер гораздо дешевле програмера 1С.
Веб-программер гораздо дешевле программера 1С исключительно потому, что программер 1С понимает и умеет использовать такие неведомые веб-разработчикам штуки, как «проводки», «план счетов», «амортизация» и т.д. Ставя задание 1Снику, клиент будет говорить: «Нам нужно, чтобы товары, приобретаемые от клиентов из категории „велосипеды“, проходили только по управленке, с возможностью реализации только за нал». Ставя задачу веб-разработчику, клиенту нужно рассказывать: «Здесь в поле „Тип учёта“ нужно проставлять флаг „управленческий“, если клиент находится в группе такой-то, при этом при продаже проверять метод оплаты, и запрещать проводить накладную, если в строках есть хоть один товар, партия которого имеет тип учета „управленческий“, а метод оплаты накладной равен „безналичная оплата“. И у клиента в штате при этом должен быть хоть один человек, способный это сформулировать. А как только веб-разработчик будет знать эту предметную область, уж поверьте, его стоимость труда сразу заметно вырастет.
> С учетом что изменения вносить проще
А за счет чего проще? Поля в реляционной СУБД как-то сложнее добавляются, чем в этом ОРМ?
Веб-программер гораздо дешевле программера 1С исключительно потому, что программер 1С понимает и умеет использовать такие неведомые веб-разработчикам штуки, как «проводки», «план счетов», «амортизация» и т.д. Ставя задание 1Снику, клиент будет говорить: «Нам нужно, чтобы товары, приобретаемые от клиентов из категории „велосипеды“, проходили только по управленке, с возможностью реализации только за нал». Ставя задачу веб-разработчику, клиенту нужно рассказывать: «Здесь в поле „Тип учёта“ нужно проставлять флаг „управленческий“, если клиент находится в группе такой-то, при этом при продаже проверять метод оплаты, и запрещать проводить накладную, если в строках есть хоть один товар, партия которого имеет тип учета „управленческий“, а метод оплаты накладной равен „безналичная оплата“. И у клиента в штате при этом должен быть хоть один человек, способный это сформулировать. А как только веб-разработчик будет знать эту предметную область, уж поверьте, его стоимость труда сразу заметно вырастет.
> С учетом что изменения вносить проще
А за счет чего проще? Поля в реляционной СУБД как-то сложнее добавляются, чем в этом ОРМ?
Веб-программер гораздо дешевле программера 1С исключительно потому, что программер 1С понимает и умеет использовать такие неведомые веб-разработчикам штуки, как «проводки», «план счетов», «амортизация» и т.д
если вебпрограмист займется саппортом то уж как нибудь он разберется с проводками. Особенн с учетом того что здесь с ними работать гораздо проще. А если изменения не заточены на конкретный бизнес — то достаточно чтобы это сделал кто то один — остальные просто скопируют нужный файлик.
А за счет чего проще? Поля в реляционной СУБД как-то сложнее добавляются, чем в этом ОРМ?
это не ОRМ. Точнее это такой же ORM как 1C
Вы ж не добавляете в 1С поля в БД вручную?
Вот и здесь — никто никакие поля не добавляет -добавляются атрибуты документов и справочников. С учетом что PHP слаботипизированный язык и добавления как такового нет — просто добавляете элемент в асоциативный массив. То есть не нужен никакой визуальный мастер.
.
Вот и здесь — никто никакие поля не добавляет -добавляются атрибуты документов и справочников.
… и как это отражается в БД?
Автоматически (в базовом классе документа) упаковывается в XML
Я понимаю что сложно представить ситему не требующую расширения БД но именно так я и проектировал — иначе нет смысла.
По той же причине я использую библиотеку ADODb которая автоматом генерит SQL запросы. Причем не тупо генерит а сравнивает асоциативный массив со структурой таблицы и генерит совпадающие поля с учетом типов.
На ее основе построен класс Entity по шаблону Active Record. от которого наследуются все бизнес-сущности.
Иными словами, в системе практически не используются прямые SQL запросы.
То есть здесь не просто сайт на PHP — тщательно подобран стек технологий.
То же касается самого сайта — в основе компонентный не MVC фреймворк который обеспечивает персистентность страницы после переагрузки.
То есть програмер работает как на делфи или .NET WebForms — через компоненты которые генерят события (нажатие на кнопку, переход по ссылке)
Разраб просто пишет бизнес-логику в обработчиках.
Ну и т. д.
Я понимаю что сложно представить ситему не требующую расширения БД но именно так я и проектировал — иначе нет смысла.
По той же причине я использую библиотеку ADODb которая автоматом генерит SQL запросы. Причем не тупо генерит а сравнивает асоциативный массив со структурой таблицы и генерит совпадающие поля с учетом типов.
На ее основе построен класс Entity по шаблону Active Record. от которого наследуются все бизнес-сущности.
Иными словами, в системе практически не используются прямые SQL запросы.
То есть здесь не просто сайт на PHP — тщательно подобран стек технологий.
То же касается самого сайта — в основе компонентный не MVC фреймворк который обеспечивает персистентность страницы после переагрузки.
То есть програмер работает как на делфи или .NET WebForms — через компоненты которые генерят события (нажатие на кнопку, переход по ссылке)
Разраб просто пишет бизнес-логику в обработчиках.
Ну и т. д.
Автоматически (в базовом классе документа) упаковывается в XML
Угу. То есть все реляционные действия недоступны. Вот захотел я добавить новое числовое поле, чтобы потом по нему делать суммы — фиг. Захотел добавить новую дату для условий фильтрации — фиг. Захотел добавить новый классификатор. и по нему делать выборки — фиг. Ну то есть нет, можно достать в клиент и в нем обработать — но прощай производительность.
Я понимаю что сложно представить ситему не требующую расширения БД
Да нет, ничего сложного, имя им легион. Вопрос того, какие компромисы туда заложены.
Вот захотел я добавить новое числовое поле, чтобы потом по нему делать суммы — фиг
Вообще то атрибуты первичных документов и справочников — общеприняты. Пока что мне ни разу не понадобилось добавит какое то экзотическое поле чтобы по нему что то вычислять.
Подобные костыли нужны как раз в системах негибких где все надо зардкодить включая поля в таблицах БД.
Любые бизнес-данные выбираются с таблиц аналитики.
А представте как люди работают с прогами писаными на делфи где вообще ничего не добавишь.
Речь идет о компромисном варианте.
Опять же напомню ориентация на небольшой бищне где не нужны какието выкрутасы.
Да нет, ничего сложного, имя им легион. Вопрос того, какие компромисы туда заложены.
скажем так — система проектируется на решение ТИПОВЫХ задач. То есть работу с типовыми стандартными первичными документами и отчетами малого предприятия с несколькими десятками первички в день, не торгующему за валюту, не требуюзему консолидированой отчетности и т. д.
Но в то же время требующего если не бухгалтерского то хотя бы управленческого учета с набором ходовых отчетов типа движение по складу…
.
Вообще то атрибуты первичных документов и справочников — общеприняты. Пока что мне ни разу не понадобилось добавит какое то экзотическое поле чтобы по нему что то вычислять.
«мне не понадобилось — никому не понадобится». В итоге получается, что система легко модифицируема только в одном очень узком направлении.
Любые бизнес-данные выбираются с таблиц аналитики.
Можно подумать, у них нет тех же проблем со структурой.
скажем так — система проектируется на решение ТИПОВЫХ задач.
… и, видимо, эти типовые задачи заморожены во времени.
«мне не понадобилось — никому не понадобится». В итоге получается, что система легко модифицируема только в одном очень узком направлении.
система модифицирована в стандартном направлении. Кому надо узкое — берите 1С или что там. Не встречал бухгалтера который говорит — сделай мне доп. поле с вычислениями. Бухгалтер говорит — реши такую то задаччу.
Можно подумать, у них нет тех же проблем со структурой
Нет пока не добавятся совсем уж новые бизнес-сущности — например управленение проектами.
Но в таком случае изменение БД это ничто по сравнении с тем что надо понаписать.
.… и, видимо, эти типовые задачи заморожены во времени.
Не поверите но некоторые из них заморожены со времен Пачоли. Бухучет исключительно консервативное направление.
система модифицирована в стандартном направлении.
А где «стандарт» — определили вы. Ну да.
Не встречал бухгалтера который говорит — сделай мне доп. поле с вычислениями. Бухгалтер говорит — реши такую то задаччу.
… а задача требует допполя с вычислениями.
А где «стандарт» — определили вы.
Нет. ПСБУ или как их там.
… а задача требует допполя с вычислениями.
задача требует решения. а как мои трудности.
в той первичке что уже успел написать (закупки продажи, малоценка, ОС) ни разу не понадобилось никакого поля.
Нет. ПСБУ или как их там.
О, регламенты и регламентирующие ведомства. У них есть та замечательная особенность, что они иногда меняются, причем в формате «а теперь с первого мартобря все подаем по новому стандарту». Так что тут тем более без модифицируемости не обойдешься.
задача требует решения. а как мои трудности.
… до тех пор, пока выполнены нефункциональные требования заказчика.
в той первичке что уже успел написать (закупки продажи, малоценка, ОС) ни разу не понадобилось никакого поля.
Сколько у вас ушло на это времени?
ну я как бы вынужден на жизнь зарабатывать, ишачить на аутсорсе и все такое.
скажем так — средний первичный документ с ненавороченым, как в налоговой накладной печатной формой, делается за полдня.
Конечно надо понимать архитектуру и предметную облсть Впрочем я просто заглядываю в 1С какие проводки и все такое — так быстрее.
в любом случае быстрее и проще чем в 1С. Хотя сравнение в отрыве от всего остального в комплексе. не имеет смысла.
скажем так — средний первичный документ с ненавороченым, как в налоговой накладной печатной формой, делается за полдня.
Конечно надо понимать архитектуру и предметную облсть Впрочем я просто заглядываю в 1С какие проводки и все такое — так быстрее.
в любом случае быстрее и проще чем в 1С. Хотя сравнение в отрыве от всего остального в комплексе. не имеет смысла.
Конечно надо понимать архитектуру и предметную облсть
… и мы снова к этому возвращаемся.
Но мой вопрос был не к производительности, а к количеству эволюционных изменений, которые вам пришлось внести в уже работающую у заказчика систему.
система в разработке пока. тчнее сама платфма готова но надо понаделывать все первичку отчеты и все такое — в терминах 1С — написать конфигурацию с нуля…
Думаю изменений у заказчика будет не больше чем в случае с 1С. Там в Бд никто не лезет — все работают на языке програмирования через высокоуровневые обьекты. И у меня так же.
Думаю изменений у заказчика будет не больше чем в случае с 1С. Там в Бд никто не лезет — все работают на языке програмирования через высокоуровневые обьекты. И у меня так же.
Угу. Поэтому вы и не можете утверждать, насколько сложно будет ее поддерживать и развивать со временем.
могу потому что она на порядок проще.
То что по факту 1с уже есть програмисты а тут еще конь не валялся — не относятся к обсуждаемой технической стороне.
То что по факту 1с уже есть програмисты а тут еще конь не валялся — не относятся к обсуждаемой технической стороне.
могу потому что она на порядок проще.
Это еще не значит, что ее проще развивать. Если система проста, но в ней не заложена модифицируемость, развивать ее будет дорого.
разумеется заложена иначе нет смысла.
Поэтому система модульная, поэтому изменение бизнес логики не требует изменения структуры Бд и не влияет на остальные части системы.
замена документа новой версией — заменить пару файлов и т.д.
она простая не потому что я взял файл PHP и тупо захардкодил накладную. В большинстве систем которые не имеют как в 1с визуальных редакторов и прочего, так кстати, и делают. Потому они и не развиваются — там черт ногу сломит.
Поэтому система модульная, поэтому изменение бизнес логики не требует изменения структуры Бд и не влияет на остальные части системы.
замена документа новой версией — заменить пару файлов и т.д.
она простая не потому что я взял файл PHP и тупо захардкодил накладную. В большинстве систем которые не имеют как в 1с визуальных редакторов и прочего, так кстати, и делают. Потому они и не развиваются — там черт ногу сломит.
поэтому изменение бизнес логики не требует изменения структуры Бд и не влияет на остальные части системы.
Вы так пишете, как будто это что-то особенное. Хотя это, на самом деле, свойство любой системы с приличной (даже не хорошей) архитектурой. И это все еще не означает, что ее легко развивать.
Мы уже выясняли, скажем, что в вашей системе не заложено механизмов развития любых значимых полей в БД.
Вы так пишете, как будто это что-то особенное.для систем где нет визуальных построителей — таки да особенное.
Иначе надо лазить в Бд. Либо выполнять еще какую мудреную конфигурацию.
А потом вы обновляете документ а он не стыкуется с измененной структрурой.
Мы уже выясняли, скажем, что в вашей системе не заложено механизмов развития любых значимых полей в БД.
все значимые там уже есть.
более того — даже если вы добавите новое поле в таблицу какого нибудь справочника — вы автоматом сможете работать с ним как с атрибутом бизнес-обьекта. Ничего не надо конфигурить ничего не надо дописывать.
просто
$c = new Contragent();
$c->somenewfield = 666;
$c->save();
главное чтобы свойство совпало с именем поля. Никаких изменений в sql никакого маппинга.
Куда уж больше возможностей к расширению.
для систем где нет визуальных построителей — таки да особенное.
Серьезно? Изоляция бизнеса от инфраструктуры — это что-то особенное?
все значимые там уже есть.
Вы не можете этого знать.
более того — даже если вы добавите новое поле в таблицу какого нибудь справочника
То есть все-таки надо будет изменять структуру БД для добавления новых полей?
Куда уж больше возможностей к расширению.
Это тривиальный ORM, вы серьезно это считаете «возможностями к расширению»?
Изоляция бизнеса от инфраструктуры — это что-то особенное?
особенно е то что он РЕАЛЬНО изолирован
Вы не можете этого знать.
могу — у меня достаточно опыта с учетными системами.
То есть все-таки надо будет изменять структуру БД для добавления новых полей?
нет. Я просто написал что даже если вы что то добавите система подхватит это поле и буде с ним работать. но добавлять новые поля к существущей структуре не вижу смысла.
Это тривиальный ORM,
это не ОRМ. нигде не задаются и не конфигурятся реляции между бизнес обьектами.
Вобще как я уже писал бизнес обьекты строятся на паттерне Active Record
Точнее они наследуются от библиотечного который так построен.
особенно е то что он РЕАЛЬНО изолирован
Угу. Можете чем-то подтвердить, что он у вас «реальнее» изолирован, чем во всех других системах?
у меня достаточно опыта с учетными системами.
Он в будущее тоже распространяется?
но добавлять новые поля к существущей структуре не вижу смысла.
Тогда как же изменять структуру данных при эволюции бизнес-требований?
это не ОRМ
То есть вы не маппите таблицы в БД на объекты языка программирования?
нигде не задаются и не конфигурятся реляции между бизнес обьектами.
Это ни на что не влияет.
Вобще как я уже писал бизнес обьекты строятся на паттерне Active Record
Который в широком смысле подвид ORM.
Можете чем-то подтвердить, что он у вас «реальнее» изолирован, чем во всех других системах?
это требует уточнения всез терминов вклюяя переделение критерия излированости.
не собираюсь заниматся казуистикой.
Он в будущее тоже распространяется?
в такой же степени как у разработчиков 1С.
Что за словоблудие ей богу.
То есть вы не маппите таблицы в БД на объекты языка программирования?
я просто указываю в обьекте имя таблицы и имя ключевого поля.
с полями он само разбирается. Но в любом случае ОРМ тут ни причем. я не задаю реляции между обьектами.
Это ни на что не влияет.это влиячет на определение ОРМ или нет.
Который в широком смысле подвид ORM.
по моему вы просто придираетесь
считаете что у меня просто ОРМ. не вопрос
Возьмите напрмер .NET TF и назовите его готовой учетной системой.
вы придираетесь непонятно к чему и главное непонятно зачем.
это требует уточнения всез терминов вклюяя переделение критерия излированости.
Ну тогда и не говорите, что у вас система проще и в ней легче вносить изменения.
с полями он само разбирается. Но в любом случае ОРМ тут ни причем. я не задаю реляции между обьектами.
Это не имеет отношения к тому, ORM это или нет.
это влиячет на определение ОРМ или нет.
Нет.
считаете что у меня просто ОРМ. не вопрос
Нет. Я считаю, что та функциональность, которую вы описываете как достоинство — это обычный ORM, и, как следствие, я не понимаю, как он может давать вам те преимущества, которые вы заявляете.
Вобще как я уже писал бизнес обьекты строятся на паттерне Active Record
Который в широком смысле подвид ORM
Проекция реляционной структуры в объекты и объектный интерфейс это не одно и тоже. Первое это ORM, второе это AR.
Это неоднозначный вопрос. В широком смысле слова ORM — это любая технология, которая отражает реляционную БД на прикладную (в противовес generic table) структуру. Дальше уже есть детали, которые разделяют AR и Mapper.
В широком смысле слова ORM
Это ваше мнение, или вы цитируете?
en.wikipedia.org/wiki/Object-relational_mapping
Далее, en.wikipedia.org/wiki/Active_record_pattern: «This pattern is commonly used by object persistence tools, and in object-relational mapping (ORM).»
Далее, en.wikipedia.org/wiki/Active_record_pattern: «This pattern is commonly used by object persistence tools, and in object-relational mapping (ORM).»
Вика? Серьезно?
Давайте мы лучше обратимся к основоположнику AR и AT моделей, товарищу Фаулеру, который ясно сообщает:
Как видно никакого «Объектно-реляционного отображения» здесь нет.
Давайте мы лучше обратимся к основоположнику AR и AT моделей, товарищу Фаулеру, который ясно сообщает:
Шлюз записи данных выступает в роли объекта, полностью повторяющего одну за-
пись, например одну строку таблицы базы данных. Каждому столбцу таблицы соответст-
вует поле записи
Как видно никакого «Объектно-реляционного отображения» здесь нет.
Во-первых, Фаулер не «основоположник», он всего лишь собрал используемые паттерны в книжку.
Во-вторых, ваша цитата относится к Row Data Gateway («A Row Data Gateway acts as an object that exactly mimics a single record, such as one database row. In it each column in the database becomes one field»), а не к Active Record.
В-третьих, все эти шаблоны относятся к разделу Data Source Architectural Patterns, и термин O/R mapping там употребляется постоянно, равно как и в разделе Mapping to Relational Databases, где — опять-таки — они все перечисляются.
Наконец, в-четверых, шаблон называется Data Mapper, а не ORM.
Так что не, don't pull your book on me.
Во-вторых, ваша цитата относится к Row Data Gateway («A Row Data Gateway acts as an object that exactly mimics a single record, such as one database row. In it each column in the database becomes one field»), а не к Active Record.
В-третьих, все эти шаблоны относятся к разделу Data Source Architectural Patterns, и термин O/R mapping там употребляется постоянно, равно как и в разделе Mapping to Relational Databases, где — опять-таки — они все перечисляются.
Наконец, в-четверых, шаблон называется Data Mapper, а не ORM.
Так что не, don't pull your book on me.
Так где же там объектно-реляционное отображение? Не во взаемодействии ли с РБД через объектный интерфейс?
Так где же там объектно-реляционное отображение? Не во взаемодействии ли с РБД через объектный интерфейс?
Нет. В том, что в ActiveRecord программист работает с объектом доменной модели, который при этом соответствует какой-то записи в БД.
Фаулер не «основоположник», он всего лишь собрал используемые паттерны в книжку
Будьте любезны тогда ссылку на первое упоминание сего шаблона в подтверждение ваших догадок
Мне хватает высказывания самого Фаулера (это вступление к PoEAA):
Patterns aren’t original ideas; they’re very much observations of what happens in the field. As a result, we pattern authors don’t say we “invented” a pattern but rather that we “discovered” one.
То есть упоминание термина есть применение ORM?
Нет. Поймите, у Фаулера вообще нет такой вещи как «ORM». Он говорит про O/R-mapping как подход (без особого, кстати, определения, что это), а интересующие нас шаблоны перечисляет в разделе шаблонов доступа к данным, располагая по их по степени увеличения сложности доменной модели.
Шаблон называется — Active Record — в остальном вы что-то путаете
Какой шаблон? Тот, который используется у автора поста? Вероятно, он сам так говорит. Тот, который используется во многих (не во всех) ORM-фреймворках? В EF, по крайней мере, Data Mapper (с кучкой вспомогательных, понятное дело).
Какой шаблон? Тот, который используется у автора поста? Вероятно, он сам так говорит
Вероятно, я лишь «услышал звон» и решил что «в интернете кто то не прав».
В том, что в ActiveRecord программист работает с объектом доменной модели, который при этом соответствует какой-то записи в БД
Так AR не обязана реализовываться в качестве доменной модели. Основная идея лишь в добавлении логики, позволяющей легко восстанавливать, сохранять и удалять данные записи. Цели проекции этой записи в домен у этого шаблона нет. В отличии от Mapper.
Так AR не обязана реализовываться в качестве доменной модели.
Обязана.
The essence of an Active Record is a Domain Model (116) in which the classes match very closely the record structure of an underlying database.
Основная идея лишь в добавлении логики, позволяющей легко восстанавливать, сохранять и удалять данные записи.
Мне кажется, вы путаете с Row Data Gateway.
Фаулер не «основоположник», он всего лишь собрал используемые паттерны в книжку
Будьте любезны тогда ссылку на первое упоминание сего шаблона в подтверждение ваших догадок
Суть в том что Фаулер не придумал этот шаблон. Шаблоны проектирования (те что описаны в той же книге фаулера) вообще никто не придумывал, они просто были. Их просто выделили и описали.
Но вроде как название AR получило именно от него, если мне память не изменяет.
Но вроде как название AR получило именно от него, если мне память не изменяет.
Но вроде как название AR получило именно от него, если мне память не изменяет.
Ну, по крайней мере, википедия с вами в этом согласна.
Шаблоны проектирования (те что описаны в той же книге фаулера) вообще никто не придумывал, они просто были
Мы уедем в область философии такими темпани. Не считаю, что без мыслительной деятельности отдельно взятых программистов, шаблоны существовали как данность. Да, если выделить все возможные вариации алгоритмов, то в них можно выделить несколько шаблонов, но рассуждая аналогично можно выделить и множество вариаций сочетаний цветом и звуков, тогда деятельность художников и музыкантов будет сводится лишь к именованию картин и музыки, а не к их созданию.
Если вы считаете шаблоны данностью, то в аналогии с природоиспытателями, различные законы (шаблонов алгоритмов) кто то должен был открыть, его я и называю — основоположником.
Если вы считаете шаблоны данностью, то в аналогии с природоиспытателями, различные законы (шаблонов алгоритмов) кто то должен был открыть, его я и называю — основоположником.
… хотя их принято называть «первооткрывателями». Основоположниками называют тех, кто заложил основы теории или учения. Основоположником идеи шаблонов проектирования, если что, считается Кристофер Александер.
Так чем же конкретный шаблон не есть теория?
Ничем не теория, в общем-то.
Я не могу позволить себе использовать термин «первооткрыватель», так как не считаю шаблоны чем то данным. Для меня это как предмет искусства, его нужно создать, а не открыть, как силу притяжения.
Кто «создал» шаблон — тот, кто написал удовлетворяющий ему код, или тот, кто придумал название?
Тот кто описал и доказал его состоятельность. Аналогично описанию и доказанию теорем.
А чем тогда был уже написанный и работающий код до того, как это назвали шаблоном?
Написанным и работающим кодом. Так же, как и картина является просто мазней по хосту до тех пор, пока ценитель не увидит в ней произведение искусства.
Написанным и работающим кодом.
А после того, как кто-то другой, кто никогда не видел этого кода, опишет паттерн, этот код внезапно станет паттерном. Вас это не смущает?
Так же, как и картина является просто мазней по хосту до тех пор, пока ценитель не увидит в ней произведение искусства.
Эээ, может вы еще и скажете, что картина становится картиной в тот момент, когда ее увидел ценитель, а не когда ее написал автор?
А после того, как кто-то другой, кто никогда не видел этого кода, опишет паттерн, этот код внезапно станет паттерном. Вас это не смущает?
Нисколько. Паттерн это категория, категории не существуют как данности, они плод стараний познающих, категоризирующих субъектов, не более того.
Эээ, может вы еще и скажете, что картина становится картиной в тот момент, когда ее увидел ценитель, а не когда ее написал автор?
Хороший вопрос. Если я напишу «картину», она не будет являться картиной до тех пор, пока ее не оценят. То есть предмет искусства есть совокупность создающего и оценивающего субъекта, а не только создающего. Другими словами чтоб предмет искусства стал таковым, его не достаточно просто создать (намазюков на холсте), его еще необходимо оценить (кем либо, помимо автора). С другой стороны данности, как сила притяжения, не нуждаются ни в создателе, ни в оценщике чтоб быть данностью.
Другими словами чтоб предмет искусства стал таковым, его не достаточно просто создать (намазюков на холсте), его еще необходимо оценить (кем либо, помимо автора).
Извините, история искусства с вами не очень согласна.
Вдаваться в философские рассуждения далее не вижу смысла, мы на разных позициях стоим.
Нисколько. Паттерн это категория, категории не существуют как данности, они плод стараний познающих, категоризирующих субъектов, не более того.
Тот кто описал и доказал его состоятельность. Аналогично описанию и доказанию теорем.
Противоречит друг другу. Категории не нуждаются в доказывании состоятельности, это просто описание условий отбора по которым сущность попадает в категорию или не попадает. В терминах математики паттерны программирования — это определения, не более. Вот эти подмножества множество всех сущностей мы называем натуральными числами, вот эти комплексными, вот эти синглтонами, а вот эти фабриками.
Шаблон (в данном контексте) именно не создается, а открывается — кто-то замечает, что для решения схожих задач (типа объектно-реляционного отображения) множество людей использует очень схожие подходы. Этот кто-то лишь анализирует их, абстрагирует в одно типовое решение и даёт название. Иногда называя этот шаблон «антипаттерном», то есть типичной ошибкой проектирования или реализации :) После этого любой может сказать «мое решение соотвествует <pattern_name>, не объясняя основные принципы, даже если решение создано раньше чем его автор узнал о <pattern_name>, а может даже раньше чем этот шаблон был выделен. Ну или любой может сказать: „это решение соответствует <pattern_name>, поэтому нормально работать не будет“.
Шаблон, по сути, лишь „регулярка“, которую сначала кто-то написал, чтобы выделить из множества уже существующих решений основные, а уж потом другие начинают использовать эту регулярку в качестве „валидатора“, а то и писать код заранее так, чтобы он ей соотвествовал.
Можно ли назвать автора регулярки проверки соответствия решения некоторому шаблону автором решения? Нет. Сначала нужно создать множество решений, а лишь потом открыть, что большие их подмножества соответствуют некоторому шаблону. Обычная аналитика, а творчества там, по сути, лишь в именовании наблюдаемых явлений.
Шаблон, по сути, лишь „регулярка“, которую сначала кто-то написал, чтобы выделить из множества уже существующих решений основные, а уж потом другие начинают использовать эту регулярку в качестве „валидатора“, а то и писать код заранее так, чтобы он ей соотвествовал.
Можно ли назвать автора регулярки проверки соответствия решения некоторому шаблону автором решения? Нет. Сначала нужно создать множество решений, а лишь потом открыть, что большие их подмножества соответствуют некоторому шаблону. Обычная аналитика, а творчества там, по сути, лишь в именовании наблюдаемых явлений.
Если вы считаете шаблоны данностью, то в аналогии с природоиспытателями, различные законы (шаблонов алгоритмов) кто то должен был открыть, его я и называю — основоположником.
Люди каждый день открывают новые виды животных и насекомых. Но животные эти и насекомые существовали до этого открытия. Они родились в ходе эволюции. Только такие структуры для описываемых задач могли выжить в пределах большого количества проектов.
таки да. я помню когда начинал програмировать не то что инета — персоналка не у каждого была. и применял синглетон ы и фабричные методы как очевидные конструкции. И только потом узнал что это оказывается паттернами именуется.
Я не считаю шаблоны данностью, для меня это аналог человеческой идеи, которая не существует без познающего субъекта.
все эти шаблоны относятся к разделу Data Source Architectural Patterns, и термин O/R mapping там употребляется постоянно, равно как и в разделе Mapping to Relational Databases, где — опять-таки — они все перечисляются
То есть упоминание термина есть применение ORM?
лон называется Data Mapper, а не ORM.
Шаблон называется — Active Record — в остальном вы что-то путаете
Шаблон называется Active Record и он, наряду с DataMapper, является одним из шаблонов решений задачи ORM. ORM — это задача, это ответственность какого-то программного артефакта, коль скоро в коде вы используете объекты, данные которых хранятся в реляционной базе данных.
Значит любой доступ к базе через объектный интерфейс есть ORM? ))
Доступ к базе не есть. А представление записей в виде объектов — есть. Банально, PDOStatement::fetchAll(PDO::FETCH_ASSOC) — не ORM, а PDOStatement::fetchAll(PDO::FETCH_OBJ) — уже простейшая ORM по сути, поскольку осуществляет маппинг записей базы на объекты. Примитивный, но маппинг.
То есть если вы получаете из базы данные не в виде массива, а в виде объектов, то это уже ORM?
Да.
Интересно, а где же обратное преобразование? )
Маппинг не обязан быть двусторонним.
Маппинг не обязан быть двусторонним
при создании нового экземпляра класса (и заполнении соответствующих полей) в таблицу добавляется новая запись;
при чтении полей объекта считываются соответствующие значения записи таблицы баз данных;
при изменении (удалении) какого-либо объекта изменяется (удаляется) соответствующая ему запись
То есть эти три правила можно смело отбросить?
Каждому столбцу таблицы соответствует поле записи
Это и есть основное правило объектно-реляционного отображения ORM, широко известного как ActiveRecord. Вы ещё больше его «упростили» добавив в это правило: «с таким же именем».
Оу, а можно тогда сразу увидеть список этих правил?
Каких этих?
О которых вы говорите:
Если правило основное, то есть и другие, не основные правила. Вот их хотелось бы увидеть.
Это и есть основное правило
Если правило основное, то есть и другие, не основные правила. Вот их хотелось бы увидеть.
каждый экземпляр данного класса соответствует одной записи таблицы;
при создании нового экземпляра класса (и заполнении соответствующих полей) в таблицу добавляется новая запись;
при чтении полей объекта считываются соответствующие значения записи таблицы баз данных;
при изменении (удалении) какого-либо объекта изменяется (удаляется) соответствующая ему запись.
при создании нового экземпляра класса (и заполнении соответствующих полей) в таблицу добавляется новая запись;
при чтении полей объекта считываются соответствующие значения записи таблицы баз данных;
при изменении (удалении) какого-либо объекта изменяется (удаляется) соответствующая ему запись.
В широком смысле слова ORM — это любая технология, которая отражает реляционную БД на прикладную
В случае если последняя — объектная :)
это не ОRМ. нигде не задаются и не конфигурятся реляции между бизнес обьектами.
То есть нигде не задается, что счёт имеет коллекцию позиций счета?
главное чтобы свойство совпало с именем поля. Никаких изменений в sql никакого маппинга.
Что?! Это обычный маппинг 1:1 по имени.
поэтому изменение бизнес логики не требует изменения структуры Бд
Такого даже авторы nosql решений не заявляют, они заявляют ровно обратное — вы можете в любой момент изменять структуру БД в соответствии с новыми требованиями бизнес-логики, у вас может одновременно существовать несколько различных структур в одной «таблице».
Конечно надо понимать архитектуру и предметную облсть
То есть обычный веб-разработчик, клепавший сотнями визитки лэндинги, ничего за полдня не сделает, а скорее ничего нормального не сделает и за полгода.
Пока что мне ни разу не понадобилось добавит какое то экзотическое поле чтобы по нему что то вычислять.
Дата остановки начисления пени по договору на основании подачи иска в суд — экзотическое поле в вашем понимании или нет? А это не просто справочный атрибут, а непосредственно влияющий на финансовые расчёты, как управленческие, так и бухгалтерские.
Выходит, что в Вашем случае мониторинг законодательства, реализация свежей формы Декларации по прибыли или ковыряние в дебрях свежего чуда-юда под кодовым названием 275-ФЗ предлагается делать бесплатно? На основе работы волонтеров, видимо?
Удачи, бро )
«Мы все через это прошли» (с)
Когда-то я тоже был молодым максималистом, с идеей о несовершенстве мира.
Удачи, бро )
«Мы все через это прошли» (с)
Когда-то я тоже был молодым максималистом, с идеей о несовершенстве мира.
мониторинг законодательства, реализация свежей формы Декларации по прибыли или ковыряние в дебрях свежего чуда-юда под кодовым названием 275-ФЗ предлагается делать бесплатно? На основе работы волонтеров, видимо?
не поверите но некоторые бесплатно делают целые операционные системы, включая написание драйверов.
Когда-то я тоже был молодым максималистом, с идеей о несовершенстве мира
9 из 10 что я гораздо старше вас. Поэтому я понимаю что делаю и зачем.
Простите, но это пост из серии «Я джва года хочу такую игру»
я ничего не хочу. Есть некоторые идеи которые я реализовываю в своем проекте. 99.9% проектов на гитхабе именно такие. Что именно вас в этом не устраивает?
Да меня в общем-то все устраивает :) Просто статья обрывается на самом интересном месте: что-то вроде потока мыслей, но без конкретной реализации или хотя бы ее начала.
в первом варианте статьи я сослался на реализацию и был забанен на неделю.
В статье описаны ряд идей которые могут реализовать то, что не реализовано или реализовано сложно и дорого у существующих систем.
Есть и всегда будут люди пытающиеся найти альтернативные решения существующим вещам. Независимо от того нравится вам одинэсникам это или нет.
В статье описаны ряд идей которые могут реализовать то, что не реализовано или реализовано сложно и дорого у существующих систем.
Есть и всегда будут люди пытающиеся найти альтернативные решения существующим вещам. Независимо от того нравится вам одинэсникам это или нет.
Как хранить документы, которые очевидно, имеют разнородную структуру. Отдельная таблица под каждый тип документа, общая таблица с кучей универсальных полей, модные нынче NoSQL хранилища… Предлагается хранить все докуменнты в одной таблице в блобе, упакованными в XML.
Угу. Давайте напишем NoSQL сами.
Вы производительность своей схемы хранения тестировали?
тестировал. Нет никаких проблем с производительностью.
Кроме того я неоднократно подчеркнул что речь об автоматизации малого бизнеса. Тех, для кого 1С громоздко и дорого а ексель нефункционально. Иными словами в БД не будет трилиарда документов. Кроме того выполнять поиск по блобу, как показало написание бизнес-логики, придется нечасто.
Кроме того я неоднократно подчеркнул что речь об автоматизации малого бизнеса. Тех, для кого 1С громоздко и дорого а ексель нефункционально. Иными словами в БД не будет трилиарда документов. Кроме того выполнять поиск по блобу, как показало написание бизнес-логики, придется нечасто.
тестировал. Нет никаких проблем с производительностью.
Результатами поделитесь?
Кроме того я неоднократно подчеркнул что речь об автоматизации малого бизнеса. Тех, для кого 1С громоздко и дорого а ексель нефункционально. Иными словами в БД не будет трилиарда документов.
Ну не будет триллиарда. Будет тысяч сто. За несколько лет. Какая нужна конфигурация, чтобы подавляющее большинство операций выполнялось в пределах полусекунды?
не будет тысяч сто хотя бы потому что никто не будет выполнять поиск тупо по всем документам. Будет искаться конкретный атрибут по конкретным типам документам — нет смысла искать контрагента в документе начисление зарплаты. А тип документа — отдельное индексируемое поле. Да и за пять лет никто не будет искать — дата документа опять же отдельное поле.
А в большинстве случаев поиск будет производится по таблице аналитики а не по блобу.
А в большинстве случаев поиск будет производится по таблице аналитики а не по блобу.
… ну и чем это лучше, чем NoSQL?
тем что система состоит не только из таблицы документов. Все восторги по поводу nosql быстро утихают когда оказывается что нужна именно реляционая схема.
Сам недавно портировал после предыдущей команды систему логистики складов с CouchDB на MSSQL. А выглядело вначале многообещающе — упаковал инвойс или ордер в json и радуйся.
Сам недавно портировал после предыдущей команды систему логистики складов с CouchDB на MSSQL. А выглядело вначале многообещающе — упаковал инвойс или ордер в json и радуйся.
тем что система состоит не только и таблицы документов. Все восторги по поводу nosql быстро утихают когда оказывается что нужна именно реляционая схема.
А зачем вам «именно реляционная схема», учитывая, что вы большую часть информации спрячете в XML, над которым реляционные операции проводятся тяжело?
я прячу в XML то что не требует реляционных операций. В этом и суть.
Ну то есть все связи, все суммы — они в XML не попадут?
попадут — там они продублируются для того чтобы если формируется печать документа не надо было подтаскивать другие таблицы (точнее вообще не надо было писать такой код). То есть там не только контрагент а и его имя и если надо адрес. Эти данные все равно под руками во время редактирования документа — они и засовываются в XML.
Но эти же данные (не все а бзнес-данныепо котоым выполняется обработка) сохраняются и в таблице аналитики. Там сумма, количество и ссылки на остальные бизнес сущности (просто вторичные ключи). По этой таблице и выполняются вычисления. Таблица состоит из полей целого типа. А значит обрабатывается очень быстро.
То есть обычная денормализация. Дата документа кроме ссылки на него тоже дублируется в таблице аналитики (хотя есть возможность и приджойнить).
Но эти же данные (не все а бзнес-данныепо котоым выполняется обработка) сохраняются и в таблице аналитики. Там сумма, количество и ссылки на остальные бизнес сущности (просто вторичные ключи). По этой таблице и выполняются вычисления. Таблица состоит из полей целого типа. А значит обрабатывается очень быстро.
То есть обычная денормализация. Дата документа кроме ссылки на него тоже дублируется в таблице аналитики (хотя есть возможность и приджойнить).
Если данные продублируются, значит, они хранятся и в обычном представлении. А если это так, значит, вы, собственно, не решили заявленную задачу: хранение разнородных документов в одной таблице.
решил.
количество бизнес-сущностей ограничено. Ссылки на них хранятся в таблице аналитики (измерения в ROLAP таблице фактов). Только ссылки — например id контрагента.
Я использую это например для подсчета остатков и оборотов.
В самом документе нет необходимости хранить реляционые отношения — там хранится все, что понадобилось бы вытащить при обработке документа. У меня под руками имя контрагента для печати и под руками id товара для выполнения проводок. Для каждого типа документа свой дочерний клас который знает что где упаковано.
Я ж не просто натыкал таблиц — я как раз разрабатываю первичку — голый движок никому не нужен. Потому на практике убедился что данных подход вполне юзабельный. Данные хранятся в разных местах и в разном виде для разного использования. Потому и дублируются. Держать данные в одном месте для разного использования — проблематично. потому то 1С такая тормознутая и надо писать кучу лишнего кода.
количество бизнес-сущностей ограничено. Ссылки на них хранятся в таблице аналитики (измерения в ROLAP таблице фактов). Только ссылки — например id контрагента.
Я использую это например для подсчета остатков и оборотов.
В самом документе нет необходимости хранить реляционые отношения — там хранится все, что понадобилось бы вытащить при обработке документа. У меня под руками имя контрагента для печати и под руками id товара для выполнения проводок. Для каждого типа документа свой дочерний клас который знает что где упаковано.
Я ж не просто натыкал таблиц — я как раз разрабатываю первичку — голый движок никому не нужен. Потому на практике убедился что данных подход вполне юзабельный. Данные хранятся в разных местах и в разном виде для разного использования. Потому и дублируются. Держать данные в одном месте для разного использования — проблематично. потому то 1С такая тормознутая и надо писать кучу лишнего кода.
То есть в вашей системе нет никакой расширяемости механизма хранения?
Его не только нет — смысл в том чтобы он не понадобился вообще.
Чтобы первичку и отчеты можно было делать не меняя структуру БД.
Основные бизнес-сущности — товары, контрагенты, сотрудники, банки, денежные счета уже заложены (для малого бизнеса должно хватить)
С учетом опять же относительно небольших объемов какой то оптимизации, написания хранимок или специальных предствлений из списка таблиц не нужно. Сложная логика будет выполнятся в PHP
Если какой отчет понадобится подождать секунд пять-десять — невелика плата за экономия на саппорте…
Пока у меня такой только один — шахматка.
Да и то потому что не стал писать прямые выборки на sql а тупо дергаю бизнес обьекты — бухгалтерские счета — пока это не критично -переписать и заменить файлик в системе секунда делов.
Чтобы первичку и отчеты можно было делать не меняя структуру БД.
Основные бизнес-сущности — товары, контрагенты, сотрудники, банки, денежные счета уже заложены (для малого бизнеса должно хватить)
С учетом опять же относительно небольших объемов какой то оптимизации, написания хранимок или специальных предствлений из списка таблиц не нужно. Сложная логика будет выполнятся в PHP
Если какой отчет понадобится подождать секунд пять-десять — невелика плата за экономия на саппорте…
Пока у меня такой только один — шахматка.
Да и то потому что не стал писать прямые выборки на sql а тупо дергаю бизнес обьекты — бухгалтерские счета — пока это не критично -переписать и заменить файлик в системе секунда делов.
Его не только нет — смысл в том чтобы он не понадобился вообще.
Не выйдет. Вы не сможете развивать систему вслед за требованиями и законодательством.
выйдет.
Если я пишу первичку с нуля это тоже самое как скорректировать под законодательство.
Настолько кардинально менялось законодательстово один раз когда в Украине перешли но новый план счетов 15 лет назад.
но даже в этом случае нужно было бы только перебить счета на новые номера.
структура БД бы не поменялась.
.
Если я пишу первичку с нуля это тоже самое как скорректировать под законодательство.
Настолько кардинально менялось законодательстово один раз когда в Украине перешли но новый план счетов 15 лет назад.
но даже в этом случае нужно было бы только перебить счета на новые номера.
структура БД бы не поменялась.
.
> не будет тысяч сто хотя бы потому что никто не будет выполнять поиск тупо по всем документам.
Хотел бы я посмотреть, как вы пересчитаете себестоимость остатков на складе при проведении возврата «задним числом» полгода назад.
Хотел бы я посмотреть, как вы пересчитаете себестоимость остатков на складе при проведении возврата «задним числом» полгода назад.
на нормальном железе — не более секунды. Mysql вообще очень хорошо работает с отдельными таблицами с фиксированым размером записи.
А postgresql с нативным jsonb еще быстрее. Или mysql + elasticsearch для агрегаций выборок. CQRS там и все такое…
как в определите где у вас контрагент? смысл XML однозначный способ структуирования данных применимый для поиска обычными текстовыми функциями. LIKE прежде всего.
Эээ, а зачем использовать «обычные текстовые функции», когда есть специализированные парсеры и индексы поверх них?
а так быстрее. зачем какие то парсеры — тут же структуированый код а не произвольный текст.
с парсерами и прочим простота и универсальность системы сойдет на нет.
тем более всякие витиеватые выьборки редко нужны в повседневно работе. Бухгалтеру точно не нужны.
Если речь идет об аналитиках то это немного другая задача и для нее возможно нужны какие то другие инструменты.
Но я веду речь об учетной системе.
с парсерами и прочим простота и универсальность системы сойдет на нет.
тем более всякие витиеватые выьборки редко нужны в повседневно работе. Бухгалтеру точно не нужны.
Если речь идет об аналитиках то это немного другая задача и для нее возможно нужны какие то другие инструменты.
Но я веду речь об учетной системе.
Для вас может парсить регулярками xml это нормально, а для меня как-то не очень.
Да ни капельки. Для велосипеда на коленке может и сойдет но не для opensource продукта.
а так быстрее
Да ни капельки. Для велосипеда на коленке может и сойдет но не для opensource продукта.
я вообще не парсю XML ни регулярками ни чем то иным.
Если речь о прямом поиске в БД на случай какой оказии то просто поиск по тексту. Тэги помоuают прицелится.
я не парсю xml чтобы найти что там есть контрагент вася пупкин я ищу простую строку
Но штатная работа — через высокоуровневые бизнес-обьекты. Так же как в 1С. В этом смысл — свести к минималной простоте большинство задач. Экзотичексие но редкие будут выполнятся неоптимально ну и фиг с ними.
Если речь о прямом поиске в БД на случай какой оказии то просто поиск по тексту. Тэги помоuают прицелится.
я не парсю xml чтобы найти что там есть контрагент вася пупкин я ищу простую строку
select from documents where details like '%<contragentname>вася пупкин </contragentname>%'
Но штатная работа — через высокоуровневые бизнес-обьекты. Так же как в 1С. В этом смысл — свести к минималной простоте большинство задач. Экзотичексие но редкие будут выполнятся неоптимально ну и фиг с ними.
а так быстрее.
Правда? Вы уверены, что поиск по вхождению быстрее поиска по полноценному индексу?
мне пофиг будет оно выполнятся секунду или полсекунды. Зато не надо вообще никаких индекса и вообше ничего. Только таблица с текстовым блобом. И этого достаточно для работы с любым, в том числе наперед неизвестным, типом документа любой структуры.
Такова идеология данного подхода и смысл статьи…
Такова идеология данного подхода и смысл статьи…
мне пофиг будет оно выполнятся секунду или полсекунды.
А, это много объясняет.
И этого достаточно для работы с любым, в том числе наперед неизвестным, типом документа любой структуры.
Интересно, зачем вообще люди придумали структурированные документы, расширяемую разметку, эти вот все глупости?
документ вполне себе структуирован. А как он хранится это вообще не забота разраба.
Он работает с высокоуровневым обьектом -экземпляром класса, например, Invoice и его атрибутами. Мое дело стобы система сохранила и выдала документ однообразным образом независимо от его структуры.
Но на всякий пожарный чтобы осталась возможность поиска напрямую по таблице для каких то нештатных задач… Поэтому с одной стороны упаковка в блоб с другой стороны такая упаковка чтбы можно было сделать ручную выборку.
Он работает с высокоуровневым обьектом -экземпляром класса, например, Invoice и его атрибутами. Мое дело стобы система сохранила и выдала документ однообразным образом независимо от его структуры.
Но на всякий пожарный чтобы осталась возможность поиска напрямую по таблице для каких то нештатных задач… Поэтому с одной стороны упаковка в блоб с другой стороны такая упаковка чтбы можно было сделать ручную выборку.
Он работает с высокоуровневым обьектом -экземпляром класса, например, Invoice и его атрибутами. Мое дело стобы система сохранила и выдала документ однообразным образом независимо от его структуры.
Угу, и как ему к этому объекту написать «хочу сумму по всем счетам, выставленным в мае»?
Серьезно, вы сейчас идете по всем штатным обсуждениям, которые возникают вокруг schemaless storage — и при этом так снисходительно отмахиваетесь от NoSQL.
Угу, и как ему к этому объекту написать «хочу сумму по всем счетам, выставленным в мае»?
поверьте гораздо проще чем в 1с
по сути одной строкой. Хотя на практике такие выборки не имеют смысла. Что бухгалеру скажет эта цифра?
А для взаиморасчетов с контаагентами есть специальный отчет.
schemaless storage — и при этом так снисходительно отмахиваетесь от NoSQL
потому что подавляющее число бизнес-вычислений выполняется по реляционным данным.
Универсально только хранение документов и справочников.
Информация которая нужна для бизнес вычислений и для манипуляций с документом — дублируется.
Мне не нужно применять реляции к атрибутам документа и не надо пихать второстепенные атрибуты там где у меня хранятся движения по количеству и сумме.
поверьте гораздо проще чем в 1с
по сути одной строкой.
Так как же?
А для взаиморасчетов с контаагентами есть специальный отчет.
Который кто-то должен написать.
потому что подавляющее число бизнес-вычислений выполняется по реляционным данным.
Нет. Подавляющее число бизнес-вычислений выполняется по бизнес-данным, а схема их хранения — глубоко вторична. Вы сам себе противоречите: сначала вы предлагаете программисту работать с бизнес-моделью, а потом говорите, что он делает вычисления по реляционным данным.
Так как же?
в бизнес обьекта есть метод find (это как раз напоминает как в ОРМ)
там задам условие. Как в обычном SQL
Который кто-то должен написать.
как и остальные отчеты, оборотно-сальдовую ведомость например. Взаиморасчеты с контрагентами — стандартная задача.
вы предлагаете программисту работать с бизнес-моделью, а потом говорите, что он делает вычисления по реляционным данным.
большиство вычислений ка напрмер, статки и обороты он и выполняет работая с бизнес моделью. Обьект Account например
имеет методы возвращающие остатки и обороты по синтетическому счету. как напрмер.СКД() в 1С.
Но в той же 1с есть и запросы и даже напоминающие SQl если брать восмерку.
И у меня так — маразма с гроздьями обьектов как в ОРМ у меня нет.
то есть все станлартные операции- сохранить докмент или там загрузить документ выполняются встроенными методами. ну а произвольные выборки конечно надо писать с помощью какого набора предикатов.
.
Что бухгалеру скажет эта цифра?
Например, сумму стоимости оказанных услуг, если счета выставляются по факту.
А чего не в текстовых файлах сразу и поиск по документам grep-ом сделать.
а чего бы вам не прочитать статью прежде чем ерничать?
Мне вот интересно, на какую реакцию вы расчитывали? Вы описали идею (причем не науровне концепта а просто… что у вас есть идея написать свою альтернативу какому-то продукту), причем из этого описания видна куча ляпов и мест для улучшения. Оно может для вас все красиво и понятно, мне например все это описание говорит о том что на свет появится еще один проект сложный в поддержке, плохо расширяемы и страдающий проблемами с производительностью.
Люди вам высказывают реально полезные моменты, и к некоторым стоит прислушаться.
Вообще что бы я вам предложил, так это сделать концепт проекта покрытый тестами. Никакого интерфейса или инфраструктуры, тупо бизнес объекты ваши и сервисы. Ну и тесты. Никаких баз данных, просто in-memory заглушки для тестов. Это займет не так много времени (в сравнении с реализацией полноценного проекта это мелочи), зато позволит вам более тщательно проработать архитектуру и идею проекта, сразу наткнуться на гору ляпов и попробовать их исправить. Никаких фреймворков, никаких библиотек (почти, возможно doctrine/collection еще или что-то подобное для работы с коллекциями), только старый добрый PHP.
А уж как будет работающий прототип (по тестам работающий) уже можно будет думать как что где хранить и т.д. У меня пока складывается впечатление что задумка у вас уже есть но вы пока понятия не представляете как это реализовать.
Ну и да, DSL таки построить свой придется.
Люди вам высказывают реально полезные моменты, и к некоторым стоит прислушаться.
Вообще что бы я вам предложил, так это сделать концепт проекта покрытый тестами. Никакого интерфейса или инфраструктуры, тупо бизнес объекты ваши и сервисы. Ну и тесты. Никаких баз данных, просто in-memory заглушки для тестов. Это займет не так много времени (в сравнении с реализацией полноценного проекта это мелочи), зато позволит вам более тщательно проработать архитектуру и идею проекта, сразу наткнуться на гору ляпов и попробовать их исправить. Никаких фреймворков, никаких библиотек (почти, возможно doctrine/collection еще или что-то подобное для работы с коллекциями), только старый добрый PHP.
А уж как будет работающий прототип (по тестам работающий) уже можно будет думать как что где хранить и т.д. У меня пока складывается впечатление что задумка у вас уже есть но вы пока понятия не представляете как это реализовать.
Ну и да, DSL таки построить свой придется.
Мне вот интересно, на какую реакцию вы расчитывали? Вы описали идею (причем не науровне концепта а просто… что у вас есть идея написать свою альтернативу какому-то продукту),
наоборот. Я пишу эту альтернативу. И то что я изложил — уже обкатанные идеи.
У меня пока складывается впечатление что задумка у вас уже есть но вы пока понятия не представляете как это реализовать
вообще то у меня проект на гитхабе и работающий прототип в инете. Законченая платформа с частью первички (пока склад, закупки, продажи).
сложный в поддержке, плохо расширяемы и страдающий проблемами с производительностью.
Наоборот. Проект именно прост в поддержке и максимально расширяемый. Да, производительность меньше- но речь не об ентерпрайз продукте. Потому произвдительность уменьшена за счет простоты, расширяемости и универсальности.
Люди вам высказывают реально полезные моменты, и к некоторым стоит прислушаться.
Да что вы говорите! А я то думаю — на фига они тут мне коменты строчат.
Вообще что бы я вам предложил, так это сделать концепт проекта покрытый тестами
я в курсе что нужны тесты. Это никак не относится к архитектурным принципам проекта. Не надо мне расказывать азбучные истины — я не начинающий програмер.
Ну и да, DSL таки построить свой придется.
не придется — PHP плюс высокоуровневые бизнес объекты.
Вы вообще прочитали что нибудь дальше названия статьи?
а есть фидбек от реальных пользователей для вашей системы?
система в разработке. Вы думаете написать вю первичку и отчеты — пара дней. Глянте в конфу 1с сколько там этого добра. Пока демке только закупки и продажи.
Статья не о моей системе а о технических аспектах реализации на основе опыта написания подобных систем.
Статья не о моей системе а о технических аспектах реализации на основе опыта написания подобных систем.
Я решил тут вместе с автором пофантазировать. Допустим я мелкий биз в глубинке, чаще всего это купи-продай до 100 человек. Что мне нужно?
Цель любого бизнесмена максимально упростить и абстрагироваться от тех вещей которые не приводят к основной цели бизнеса — прибыли. Думаю я поспрашивал у друзей-знакомых, кто имел с этим дело, или я раньше сам видел что все пользуются 1С. Тут появляется неважно откуда у меня информация об альтернативе. Что сподвигнет меня выбрать не 1С? Опенсорс — думаю 90% подобных бизнесменов сочтут слово ругательством и даже не будут гуглить что это, так что не агрумент совсем. Бесплатно — но кто-то это должен будет поставить и настроить, пусть это будет сисадмин даже хотя бы. Думаю найти сисадмина который будет ставить опенсорс по мануалам, которые, как обычно, давно не обновляли, в общем думаю тут я бы уже отказался в пользу 1С. Но допустим я настойчивый и знаю что такое опенсорс иду на принцип. Я нашел сисадмина, но он сказал что ему нужен месяц на внедрение и пару месячных окладов обычного сисадмина за работу. Тут я уже тысяч 50 рублей потратил в глубинке и 150 в Москве и это минимум. При этом я думаю тысяч за 100 можно было уже для начала купить достаточный набор из УТ, ЗУП и Бухгалтерии и вчерашний студент поставит это за 10 тысяч и за пару вечеров. Так можно продолжать бесконечно, не знаю что должно произойти чтобы какой-то продукт мог потеснить 1С на пьедестале, особенно на уровне мелкого бизнеса.
Цель любого бизнесмена максимально упростить и абстрагироваться от тех вещей которые не приводят к основной цели бизнеса — прибыли. Думаю я поспрашивал у друзей-знакомых, кто имел с этим дело, или я раньше сам видел что все пользуются 1С. Тут появляется неважно откуда у меня информация об альтернативе. Что сподвигнет меня выбрать не 1С? Опенсорс — думаю 90% подобных бизнесменов сочтут слово ругательством и даже не будут гуглить что это, так что не агрумент совсем. Бесплатно — но кто-то это должен будет поставить и настроить, пусть это будет сисадмин даже хотя бы. Думаю найти сисадмина который будет ставить опенсорс по мануалам, которые, как обычно, давно не обновляли, в общем думаю тут я бы уже отказался в пользу 1С. Но допустим я настойчивый и знаю что такое опенсорс иду на принцип. Я нашел сисадмина, но он сказал что ему нужен месяц на внедрение и пару месячных окладов обычного сисадмина за работу. Тут я уже тысяч 50 рублей потратил в глубинке и 150 в Москве и это минимум. При этом я думаю тысяч за 100 можно было уже для начала купить достаточный набор из УТ, ЗУП и Бухгалтерии и вчерашний студент поставит это за 10 тысяч и за пару вечеров. Так можно продолжать бесконечно, не знаю что должно произойти чтобы какой-то продукт мог потеснить 1С на пьедестале, особенно на уровне мелкого бизнеса.
Бесплатно — но кто-то это должен будет поставить и настроить, пусть это будет сисадмин даже хотя бы.
Стащите вариант с WAMP сервером. Настраивать в самой системе нечего кроме бизнес-настроек.
Не нужен никакой сисадмин.
Если хотите развернуть как сайт чтобы доступатся с инета — это не сложнее чем развернуть обычный сайт — например сайт визитку вашей компании -любой вебразраб сделает.
Обновление сайта как уже писал — заменой файлов как нибудь FTP освоите если сайт на хостинге. А если внутри то вообще никаких проблем.
Идете на форум, комунити или саппорт или просто к людям которые стороние разрабы и говорите — вот тут вышел бланк накладной теперь к единице измерения еще полагается код писать.
Они вам дают ссылку или кидают пару файлов вы их копируете в соответствующие папки и все. Задача для продвинутого юзера не более того.
Можно, я объясню?
дело не в том, что мне нравится подход автора, нет, скорее как раз наоборот.
Но легко сказать, почему у бизнеса может быть востребована альтернативная система учета: сложность. Даже в мск полно бизнесов, где 1С в многих применениях слишком сложна. Да, в вопросе фискального учета она имеет подавляющую долю рынка, если говорить про мелочь. Но для работы — она категорически неудобна. А налоговый учет очень часто отдан на аутсорс, и штатные сотрудники компании в своей повседневной деятельности никак с ним не связаны!
Вот представьте себе, офис, сидят девочки, продают — не знаю — туры. или страховки. На кой им 1С? Как их обучать? Сколько времени и денег на это надо?
гораздо проще нарисовать что-то типа АРМ с 3 кнопками в веб-морде, и привет.
А потом, отдельно, рисовать выгрузку данных из своей ERP 8-) в 1C. И 1С, конечно, тут будет использоваться уже в предельно стандартной форме.
Логичная схема?
Знаю массу компаний, которые идут именно этим путем. То есть, альтернативная система оказывается уже внедрена, не потому, что кто-то принципиально решил выбрать опенсорс, а потому, что людям работать надо!
Ну, а от такой штуки уже очень недалеко и до «а давайте попробуем 1С вообще выкинуть — эта налог тоже умеет, и формы актуальные все есть!».
так что, альтернативная система вполне может быть. Другой вопрос — удастся ли это кому-то в близкой перспективе или нет…
простой пример: облачные системы вполне себе заменяют 1С по крайней мере для некоторых видов компаний. Мое дело, например, подписку купил — 1С не нужна. В чем вы видите уж такое принципиальное отличие от идей автора?
дело не в том, что мне нравится подход автора, нет, скорее как раз наоборот.
Но легко сказать, почему у бизнеса может быть востребована альтернативная система учета: сложность. Даже в мск полно бизнесов, где 1С в многих применениях слишком сложна. Да, в вопросе фискального учета она имеет подавляющую долю рынка, если говорить про мелочь. Но для работы — она категорически неудобна. А налоговый учет очень часто отдан на аутсорс, и штатные сотрудники компании в своей повседневной деятельности никак с ним не связаны!
Вот представьте себе, офис, сидят девочки, продают — не знаю — туры. или страховки. На кой им 1С? Как их обучать? Сколько времени и денег на это надо?
гораздо проще нарисовать что-то типа АРМ с 3 кнопками в веб-морде, и привет.
А потом, отдельно, рисовать выгрузку данных из своей ERP 8-) в 1C. И 1С, конечно, тут будет использоваться уже в предельно стандартной форме.
Логичная схема?
Знаю массу компаний, которые идут именно этим путем. То есть, альтернативная система оказывается уже внедрена, не потому, что кто-то принципиально решил выбрать опенсорс, а потому, что людям работать надо!
Ну, а от такой штуки уже очень недалеко и до «а давайте попробуем 1С вообще выкинуть — эта налог тоже умеет, и формы актуальные все есть!».
так что, альтернативная система вполне может быть. Другой вопрос — удастся ли это кому-то в близкой перспективе или нет…
простой пример: облачные системы вполне себе заменяют 1С по крайней мере для некоторых видов компаний. Мое дело, например, подписку купил — 1С не нужна. В чем вы видите уж такое принципиальное отличие от идей автора?
обясните тогда каким чудом вообще существуют учетные системы не являющиеся 1С? Ну не 100% же рынка 1С держит. и не потому что пользователи никогда не слышали об 1с и купили что первое попало на глаза.
есть проблема — не все компании согласны засунуть свои бизнес-данные неведомое облако. Как с точки зрения конфиденциальности так с точки зрения сохранности. Не то что облака это не обеспечивают а просто — «терзают смтные сомненья».
облачные системы вполне себе заменяют 1С по крайней мере для некоторых видов компаний
есть проблема — не все компании согласны засунуть свои бизнес-данные неведомое облако. Как с точки зрения конфиденциальности так с точки зрения сохранности. Не то что облака это не обеспечивают а просто — «терзают смтные сомненья».
В чем вы видите уж такое принципиальное отличие от идей автора?
На вскидку у автора есть одно катастрофическое отличие. Он считает, что отвязка разработчика такой платформы от предметной области возможна. Нифига это не возможно. Даже более. В любом мало-мальском проекте разработчик просто обязан быть в предметной области, её проблематике. Иначе он велосипидет в итоге пятое колесо которое приделывает к хромой собаке. Зато архитектура красивая и «опенсурс».
Ну я ведь сразу написал: «дело не в том, что мне нравится подход автора, нет, скорее как раз наоборот». Ничего, что я себя цитирую? 8-)
И ответил не в рут, а на реплику. И то, что написано далее, надо понимать в этом же контексте.
Вопрос был: с чего кто-то вообще начнет новое пробовать?
Ответ: а с того, что есть большой кусок жизни малого бизнеса, который 1С покрывает очень плохо. мучительно плохо. И большая часть нормальных бизнесов вынуждена использовать что-то стороннее. И как только это «что-то» будет уметь еще и бухгалтерию — возникает точка роста.
Вот и все. А про фрейм для построения собственной бухгалтерии любым желающим — тут у меня самого сомнений хватает.
И ответил не в рут, а на реплику. И то, что написано далее, надо понимать в этом же контексте.
Вопрос был: с чего кто-то вообще начнет новое пробовать?
Ответ: а с того, что есть большой кусок жизни малого бизнеса, который 1С покрывает очень плохо. мучительно плохо. И большая часть нормальных бизнесов вынуждена использовать что-то стороннее. И как только это «что-то» будет уметь еще и бухгалтерию — возникает точка роста.
Вот и все. А про фрейм для построения собственной бухгалтерии любым желающим — тут у меня самого сомнений хватает.
Вопрос был: с чего кто-то вообще начнет новое пробовать?
этот вопрос стоит пере каждым разработчиком ПО. и не только ПО. Например колбасы.
И большая часть нормальных бизнесов вынуждена использовать что-то стороннее.
ну скажем так бизнесы иду к програмерам а те уже решают или рекомендуют или еще как.
по любому спрос на льтернативные решения в учете есть. Например портирует сообщество ккакой нибудь опернбраво или адьепер (или как его там)
Но оно требует допиливания, там древний код. некторые на чве написаны и все такое.
Потому и смысл предложить оптимальный набор технологий, платформу с высокоуровневыми бизнес-обьектами и сразу заточить под отечественного клиента.
как то так.
Смысл этого всего предложить плюсы там где не устраивает существующее положение вещей.
Базара нет — устремления благие.
Чего уж там говорить, написав в одно лицо свою первую ERP почти 20 лет назад 8-) и потом еще несколько похожих вещей, я и сам изрядно грешен велосипедизмом.
Но все же, теперь мне кажется, что ваша задача трудноразрешима. Хотя бы потому, что 1С не только в авангарде всех изменений минфина и налоговой, но еще — по злостным слухам — сама является чуть ли не причиной этих изменений.
Любой самый чудный опенсорсный проект/платформа в наших условиях всегда будет догоняющим, увы.
Все внедрения опенбраво, которые я видел, были сделаны энтузиастами. Даже если этот энтузиаст — директор. там в решении немалая часть — волюнтаристское «хочу назло всем». И лично знаю людей, кто в итоге об этом пожалел.
Я не отговариваю — конечно, пилите! Больше того, я и сам раз в несколько месяцев бью себе по рукам, чтоб не начать пилить очередной квази- или прото- ERP 8-)
Другой вопрос — что обольщаться не стоит: шансов немного. на то, что напишете, на то, что написанное будет сколько-то пристойным, и на то, что это хоть кому-то понадобится.
Чего уж там говорить, написав в одно лицо свою первую ERP почти 20 лет назад 8-) и потом еще несколько похожих вещей, я и сам изрядно грешен велосипедизмом.
Но все же, теперь мне кажется, что ваша задача трудноразрешима. Хотя бы потому, что 1С не только в авангарде всех изменений минфина и налоговой, но еще — по злостным слухам — сама является чуть ли не причиной этих изменений.
Любой самый чудный опенсорсный проект/платформа в наших условиях всегда будет догоняющим, увы.
Все внедрения опенбраво, которые я видел, были сделаны энтузиастами. Даже если этот энтузиаст — директор. там в решении немалая часть — волюнтаристское «хочу назло всем». И лично знаю людей, кто в итоге об этом пожалел.
Я не отговариваю — конечно, пилите! Больше того, я и сам раз в несколько месяцев бью себе по рукам, чтоб не начать пилить очередной квази- или прото- ERP 8-)
Другой вопрос — что обольщаться не стоит: шансов немного. на то, что напишете, на то, что написанное будет сколько-то пристойным, и на то, что это хоть кому-то понадобится.
Хотя бы потому, что 1С не только в авангарде всех изменений минфина и налоговой, но еще — по злостным слухам — сама является чуть ли не причиной этих изменений.
ну мое дело представить техническую сторону. Геопллитика и все такое конечно имеет место быть.
что обольщаться не стоит
я не обльщаюсь — я взрослый человек. У меня многолетнихй прграмиский опыт в том числе и автоматизации. Есть какие-то идеи где то свои где то подсмотренные.
Жалко добру пропадать.
Вот и реализовываю потихоньку.
К примеру большинство продуктов майкрософта не чисто их — они просто великий итегратор — берут все полезное что плохо лежит собирают в кучу и вот результат.
Или вот нпример разработчик nginx — тоже наверно говорили ты че апач собрался переплюнуть, да кто этим пользоватся будет. но чел нашел минусы апача и предложил прогу которая без них с приемлемым функционалом.
Конечно для таких дел нужен инвестор раскрутка и все такое. но у меня эта система — не смысл жизни. :)
доделаю попробую предложить тем кто мыкается по форумам в поисках проги потому что все не устраивает. откатаю на реальных клиентах а там видно будет.
nginx — продукт для профессионалов. Там не нужно армию хз кого (пере)обучать.
Офис — ну да, ситуация схожая. Именно поэтому, все конкуренты обязательно делают свои продукты максимально похожими на мелкософт. Максимально!
А тут получается как? Будет платформа, на основе которой любой желающий, вместо того, чтоб тупо внедрить 1С, сможет написать свой клон 1С? Очень трудный путь, как мне кажется.
Офис — ну да, ситуация схожая. Именно поэтому, все конкуренты обязательно делают свои продукты максимально похожими на мелкософт. Максимально!
А тут получается как? Будет платформа, на основе которой любой желающий, вместо того, чтоб тупо внедрить 1С, сможет написать свой клон 1С? Очень трудный путь, как мне кажется.
Нет. он тупо внедрит то что «тут». Потому и разрабатывается то что в 1с называется конфигурацией — первичка отчеты и все такое.
Просто статья о технической стороне реализации самой платформы.
Просто статья о технической стороне реализации самой платформы.
Офис — ну да, ситуация схожая. Именно поэтому, все конкуренты обязательно делают свои продукты максимально похожими на мелкософт. Максимально!
OO и LO не слишком смахивают на продукты Microsoft, как по мне.
тоже наверно говорили ты че апач собрался переплюнуть
Да ладно… Может вы не вкурсе, но nginx изначально разрабатывался для рамблера, то есть это не была какая-то поделка любителя, это было решение разработанное профессианалом для решения проблем рамблера. Получилось неплохо, было решено вкинуть это в опенсурс. Сейчас вот фэйсбуки тоже его юзают.
В целом же сделать лучше чем apache не проблема. Разница только в том что nginx изначально тестировался в боевых условиях и проектировался под нагрузки.
Вроде немного не так. nginx был разработан не в Рамблере, а сотрудником Рамблера в свободное от основных обязанностей время (и использоваться начал не в Рамблере, о нём случайно узнали там, что есть что-то разработанное их сотрудником, что может решить проблемы очередного сервиса), не программистом-профессионалом, а программистом-любителем (сисадмином по профессии). И проект был изначально «для души» и распространялся сразу в исходниках.
Как нам обустроить альтернативу 1С