Здравствуйте, Dmitry The Wing, Вы писали:
>>> Необходимо определиться с выбором средств разработки: >>> — 1С >>> или >>> — локальный сервер Apache + php + FireBird + ajax
DTW>Система будет вести учет материалов, движение их в производстве, учет продукции, начисление зарплаты и т.д.
Я так понял, наработок на FB у вас нет? Ну тогда вот:
В случае 1С — уже есть готовые решение (и склады (учет) и зарплата), почему бы их не адаптировать? Благо контор очень много и большое комунити.
FB — а нафига собственно заново писать алгоритмы/изобретать велосипед? Вам ведь не только серверную часть нужно будет делать, а еще и систему отчетов прикручивать и UI строить. Потом поддерживать не запаритесь?
Здравствуйте, Figaro, Вы писали:
F>Не не типовые... навороченные от одной конторы У меня был извращенный вариант: 30 баз ~8 Гб каждая, 4 терминальника Citrix + 1SQL сервер, все четырех-процники... Порядка 300 коннекшинов одновременно... Хреновастенько выдерживали...
Значит, не судьба
Или контора такая была, не туда свороченная
Есть заказчик, которому не важно в чем будет реализовыван проект, — важна только скорость разработки и модификаций.
Есть два штатных исполнителя.
Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.
Т.е. режим работы даже более экзотичен, чем Extreme Programming.
А теперь сам вопрос:
Необходимо определиться с выбором средств разработки:
— 1С
или
— локальный сервер Apache + php + FireBird + ajax
"Dmitry The Wing" <19014@users.rsdn.ru> wrote in message news:3402510@news.rsdn.ru... > Необходимо определиться с выбором средств разработки: > — 1С > или > — локальный сервер Apache + php + FireBird + ajax
Странный вопрос — что лучше коньки или лыжи, и то и другое служит для передвижения. Так как вы даже приблизетельно не написали что система будет делать, и кто будет с ней работать, ответ только один — пишете на том, что лучше знаете.
Здравствуйте, wellwell, Вы писали:
W>"Dmitry The Wing" <19014@users.rsdn.ru> wrote in message news:3402510@news.rsdn.ru... >> Необходимо определиться с выбором средств разработки: >> — 1С >> или >> — локальный сервер Apache + php + FireBird + ajax
W>Странный вопрос — что лучше коньки или лыжи, и то и другое служит для передвижения. Так как вы даже приблизетельно не написали что система будет делать, и кто будет с ней работать, ответ только один — пишете на том, что лучше знаете.
В том то и дело, что исполнители отличаются, в основном, знаниями.
Оба способны к обучению, но базовые знания не совпадают.
Потому тут не подходит критерий "что лучше знаете". Нужен другой, — более веский.
Система будет вести учет материалов, движение их в производстве, учет продукции, начисление зарплаты и т.д.
Здравствуйте, DarkMaster, Вы писали:
DM>Здравствуйте, Dmitry The Wing, Вы писали:
>>>> Необходимо определиться с выбором средств разработки: >>>> — 1С >>>> или >>>> — локальный сервер Apache + php + FireBird + ajax
DTW>>Система будет вести учет материалов, движение их в производстве, учет продукции, начисление зарплаты и т.д.
DM>Я так понял, наработок на FB у вас нет? Ну тогда вот:
DM>В случае 1С — уже есть готовые решение (и склады (учет) и зарплата), почему бы их не адаптировать? Благо контор очень много и большое комунити. DM>FB — а нафига собственно заново писать алгоритмы/изобретать велосипед? Вам ведь не только серверную часть нужно будет делать, а еще и систему отчетов прикручивать и UI строить. Потом поддерживать не запаритесь?
Отчеты в любом случае делать с нуля, а вот UI ... большую часть интерфейса можно сделать универсальной — справочники и ненавороченные документы (FB позволит прочитать структуру данных и все связи, а спец.информацию можно разместить в описаниях полей и таблиц, благо на их размер нет ограничений), а остальные — так они и в 1С делаются каждый отдельно.
адаптировать ... а не получится ли, что сделать с нуля будет быстрее, чем адаптировать?
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>Необходимо определиться с выбором средств разработки: DTW>>- 1С DTW>>или DTW>>- локальный сервер Apache + php + FireBird + ajax DTW>>Нужно мнение незаинтересованных лиц.
DC>Что в результате должно быть? Веб-клиент или нативное приложение? Портабельность важна?
В результате должна получиться система управления производством с учетом сырья, продукции и зарплаты.
На данный момент вопроса о типе клиента и портируемости нет. Если бы этот вопрос стоял — то тема бы просто не возникла.
Здравствуйте, DarkMaster, Вы писали:
DM>Здравствуйте, Tonal-, Вы писали:
DTW>>>- локальный сервер Apache + php + FireBird + ajax T>>Мы делаем на Python + PyQt + FireBird — классно получается.
DM>И сколько времени вы уже делаете? Вопрос обучаемости и 2-х исполнителей у вас не стоит?
DM>P.S. Вопрос не плане флейма о крутизне 1С и FB, а в плане сроков реализации...
Присоединяюсь — любопытно услышать о том, что делает система, и сколько потребовалось времени на разработку.
DTW>Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.
Конкретика таки нужна, сложно вообще что-то советовать не зная даже примерного направления задачи. Может заказчику 3D шутер нужен, тут на 1С будет довольно сложно реализовывать.
DTW>А теперь сам вопрос:
DTW>Необходимо определиться с выбором средств разработки: DTW>- 1С DTW>или DTW>- локальный сервер Apache + php + FireBird + ajax
Минусы 1С
Помимо оплаты за разработку заказчику придется заплатить 1Сникам за движок (а т.к. они отдельно движок не торгуют, то и за бухгалтерию какую-нить простенькую, и если сетевая — то дороже)
Все ж таки она (1С) заточена под конкретный круг задач
Минусы локальный сервер Apache + php + FireBird + ajax
Много чего системного придется реализовывать с нуля (в сравнении с 1С — тот же объект "Документ", система отчетов и прочее).
При падении всего этого добра нужен быдет грамотрый админ который все поднимет назад.
Плюсы описывать не буду, потому как задача не ясна даже на уровене догадок.
Здравствуйте, Aristarh_Dark, Вы писали:
A_D>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.
A_D>Конкретика таки нужна, сложно вообще что-то советовать не зная даже примерного направления задачи. Может заказчику 3D шутер нужен, тут на 1С будет довольно сложно реализовывать.
В результате должна получиться система управления производством с учетом сырья, продукции и зарплаты.
Детали заказчик формирует после завершения очередного этапа.
Например, первый этап — справочники и формирование карточек товара, т.е. состав и нормативы по сырью.
DTW>>А теперь сам вопрос:
DTW>>Необходимо определиться с выбором средств разработки: DTW>>- 1С DTW>>или DTW>>- локальный сервер Apache + php + FireBird + ajax
A_D>Минусы 1С A_D> Помимо оплаты за разработку заказчику придется заплатить 1Сникам за движок (а т.к. они отдельно движок не торгуют, то и за бухгалтерию какую-нить простенькую, и если сетевая — то дороже) A_D> Все ж таки она (1С) заточена под конкретный круг задач
A_D>Минусы локальный сервер Apache + php + FireBird + ajax A_D> Много чего системного придется реализовывать с нуля (в сравнении с 1С — тот же объект "Документ", система отчетов и прочее). A_D> При падении всего этого добра нужен быдет грамотрый админ который все поднимет назад.
A_D>Плюсы описывать не буду, потому как задача не ясна даже на уровене догадок.
При падении админ грамотный требуется в обоих случаях, тут вопрос в том, насколько грамотно настроены баккапы. В случае FB баккапы могут быть автоматическими, а вот с 1С — только ручные...
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>>Необходимо определиться с выбором средств разработки: DTW>>>- 1С DTW>>>или DTW>>>- локальный сервер Apache + php + FireBird + ajax DTW>>>Нужно мнение незаинтересованных лиц. DC>>Что в результате должно быть? Веб-клиент или нативное приложение? Портабельность важна? DTW>В результате должна получиться система управления производством с учетом сырья, продукции и зарплаты.
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>При падении админ грамотный требуется в обоих случаях, тут вопрос в том, насколько грамотно настроены баккапы. В случае FB баккапы могут быть автоматическими, а вот с 1С — только ручные...
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>При падении админ грамотный требуется в обоих случаях, тут вопрос в том, насколько грамотно настроены баккапы. В случае FB баккапы могут быть автоматическими, а вот с 1С — только ручные...
DC>Ужасы какие про 1с рассказываете...
А разве я не прав и существует автоматика для баккапов в 1С?
Здравствуйте, Dmitry The Wing, Вы писали:
DC>>Ужасы какие про 1с рассказываете... DTW>А разве я не прав и существует автоматика для баккапов в 1С?
Да, неправы. Существует. Начиная от пакетного режима (штатного средства) и до всяких раров и планировщиков (для файловой версии) и sql-jobs для sql-версии.
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Dmitry The Wing, Вы писали:
DC>>>Ужасы какие про 1с рассказываете... DTW>>А разве я не прав и существует автоматика для баккапов в 1С?
DC>Да, неправы. Существует. Начиная от пакетного режима (штатного средства) и до всяких раров и планировщиков (для файловой версии) и sql-jobs для sql-версии.
DTW>В результате должна получиться система управления производством с учетом сырья, продукции и зарплаты. DTW>Детали заказчик формирует после завершения очередного этапа. DTW>Например, первый этап — справочники и формирование карточек товара, т.е. состав и нормативы по сырью.
Управленческий учет на 1С реализовать, ИМХО, проще.
Извините... Но заказчика интересует, что? скорость разработки, поддержка (если вы отвалитесь)? Постановка неконкретизирована...
DTW>Ситуация:
DTW>Есть заказчик, которому не важно в чем будет реализовыван проект, — важна только скорость разработки и модификаций. DTW>Есть два штатных исполнителя.
DTW>Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.
DTW>Т.е. режим работы даже более экзотичен, чем Extreme Programming.
DTW>А теперь сам вопрос:
DTW>Необходимо определиться с выбором средств разработки: DTW>- 1С DTW>или DTW>- локальный сервер Apache + php + FireBird + ajax
DTW>Нужно мнение незаинтересованных лиц.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: 1C vs php + FireBird
От:
Аноним
Дата:
26.05.09 19:36
Оценка:
DTW>Значит будем считать, что в этом различий нет...
Уже писал Вам письмо на e-mail в профиле, с предложением по системе, наверное, не заинтересовало.
Не пишите на 1С, лучше напишите с нуля на современных технологиях (web-сервер, FB), если позволяет опыт
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Ситуация:
DTW>Необходимо определиться с выбором средств разработки: DTW>- 1С DTW>или DTW>- локальный сервер Apache + php + FireBird + ajax
Собственное решение Apache + PHP может вылиться в конечном счете дороже для заказчика.
1С довольно распространенная штука, имеющая стандартную архитектуру (справочники, документы, регистры, пользовательский интерфейс и др.). Проектирование собственного движка займет больше времени и поддержка, возможно, будет требовать больше "человеко-часов".
1С конечно прожорливее в плане ресурсов.
Проще взять готовый движок на 1С и не мучаться.
DTW>>Значит будем считать, что в этом различий нет...
А>Уже писал Вам письмо на e-mail в профиле, с предложением по системе, наверное, не заинтересовало.
А>Не пишите на 1С, лучше напишите с нуля на современных технологиях (web-сервер, FB), если позволяет опыт
Вчера не заглядывал в почту, потому и не видел.
Посмотрел — понравилось. Идея почти совпадает с моей, за исключением того, что я планировал все сделать в окнах без закладок + у меня нет дизайна внешнего вида, а в остальном практически то же самое.
Именно это и планируется реализовать в виде локального web-сервера.
P.S.: Возможно, других заинтересует Ваше предложение, может стоит выложить здесь ссылку?
Здравствуйте, _Oleg_, Вы писали:
_O_>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>Ситуация:
DTW>>Необходимо определиться с выбором средств разработки: DTW>>- 1С DTW>>или DTW>>- локальный сервер Apache + php + FireBird + ajax
_O_>Собственное решение Apache + PHP может вылиться в конечном счете дороже для заказчика. _O_>1С довольно распространенная штука, имеющая стандартную архитектуру (справочники, документы, регистры, пользовательский интерфейс и др.). Проектирование собственного движка займет больше времени и поддержка, возможно, будет требовать больше "человеко-часов".
_O_>1С конечно прожорливее в плане ресурсов. _O_>Проще взять готовый движок на 1С и не мучаться.
Не согласен с тем, что разработка и поддержка займет больше "человеко-часов".
Поясню:
На первых этапах, когда происходит разработка базовых элементов интерфейса и в целом движка, которые в 1С уже есть (или почти такие как надо) бесспорно времени будет потрачено больше.
Однако на последующих этапах, когда на 1С придется разрабатывать новое + модифицировать старое, то выигрывать будет уже вариант с php.
Время, затраченное на каждый этап при использовании 1С будет по началу постоянны, а затем начнет расти.
При использовании же php, время, затраченное на каждый этап, будет постоянно уменьшаться. (стоит пояснять?)
Здравствуйте, Figaro, Вы писали:
F>Здравствуйте, Dmitry The Wing, Вы писали:
F>Извините... Но заказчика интересует, что? скорость разработки, поддержка (если вы отвалитесь)? Постановка неконкретизирована...
Повторюсь: исполнители в штате заказчика, т.е. оба будут в курсе всех этапов разработки (насколько это возможно) + любой этап можно проанализировать впоследствии заглянув в лог SVN, а грамотно составлять комментарии в интересах обоих разработчиков.
К слову: 1С не позволяет провести подобный анализ без покупки специальных дополнительных средств.
DTW>>Ситуация:
DTW>>Есть заказчик, которому не важно в чем будет реализовыван проект, — важна только скорость разработки и модификаций. DTW>>Есть два штатных исполнителя.
DTW>>Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.
DTW>>Т.е. режим работы даже более экзотичен, чем Extreme Programming.
DTW>>А теперь сам вопрос:
DTW>>Необходимо определиться с выбором средств разработки: DTW>>- 1С DTW>>или DTW>>- локальный сервер Apache + php + FireBird + ajax
DTW>>Нужно мнение незаинтересованных лиц.
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Повторюсь: исполнители в штате заказчика, т.е. оба будут в курсе всех этапов разработки (насколько это возможно) + любой этап можно проанализировать впоследствии заглянув в лог SVN, а грамотно составлять комментарии в интересах обоих разработчиков. DTW>К слову: 1С не позволяет провести подобный анализ без покупки специальных дополнительных средств.
Опять страшилки
Для 77 — gcomp и svn. Для 8.* — её родное хранилищие.
... << RSDN@Home 1.2.0 alpha rev. 772>>
Re[4]: 1C vs php + FireBird
От:
Аноним
Дата:
27.05.09 05:48
Оценка:
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>Повторюсь: исполнители в штате заказчика, т.е. оба будут в курсе всех этапов разработки (насколько это возможно) + любой этап можно проанализировать впоследствии заглянув в лог SVN, а грамотно составлять комментарии в интересах обоих разработчиков. DTW>>К слову: 1С не позволяет провести подобный анализ без покупки специальных дополнительных средств.
DC>Опять страшилки
DC>Для 77 — gcomp и svn. Для 8.* — её родное хранилищие.
прочитал про gcomp и понял, что оно предназначено для конфигурации, а ert оно умеет?
Здравствуйте, <Аноним>, Вы писали:
DC>>Для 77 — gcomp и svn. Для 8.* — её родное хранилищие. А>прочитал про gcomp и понял, что оно предназначено для конфигурации, а ert оно умеет?
Здравствуйте, Figaro, Вы писали:
F>К сожалению отсутствие ТЗ — и SVN не поможет, в данном случае все-таки 1С... и лучше восьмерка
Типа 1С сама ТЗ додумает?
Отсутствие ТЗ только приводит к необходимости частой переработки уже реализованного, что, как мне кажется, в 1С намного сложнее, т.к. оно постоянно перепроверяет и перелопачивает все свои таблички.
В нормальной БД добавить новое поле, ключ, триггер, индекс, и удалить ненужные — намного проще и не требует остановки системы.
главное сперва добавить новое, поменять код, а затем уже удалять старые.
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, <Аноним>, Вы писали:
DC>>>Для 77 — gcomp и svn. Для 8.* — её родное хранилищие. А>>прочитал про gcomp и понял, что оно предназначено для конфигурации, а ert оно умеет?
DC>Умеет. Для этого отдельный ключ у неё есть.
Это хорошо. Поможет отслеживать изменения в существующих конфигурациях.
Большое спасибо за наводку.
Re[9]: 1C vs php + FireBird
От:
Аноним
Дата:
27.05.09 06:02
Оценка:
DTW>Вчера не заглядывал в почту, потому и не видел. DTW>Посмотрел — понравилось. Идея почти совпадает с моей, за исключением того, что я планировал все сделать в окнах без закладок + у меня нет дизайна внешнего вида, а в остальном практически то же самое.
DTW>Именно это и планируется реализовать в виде локального web-сервера.
DTW>P.S.: Возможно, других заинтересует Ваше предложение, может стоит выложить здесь ссылку?
Нет, спасибо, пока не стоит.
Сами видите, что проект еще в начальной стадии, в нем не хватает:
1. безопасности (права доступа к объектам)
2. жизненных циклов документов (стутусы)
3. встраиваемых событий
4. дополнительных сервисных функций (автопроцедуры, механизм оповещения о событий)
кроме того, возможно будет совершенстоваться администраторская часть и все конфигурирование будет осуществляться преимущественно из системы, сейчас XML-файлы.
И главное, ведется работа по "быстрому старту" демо-стенда, чтобы для знакомства с системой было бы достаточно деплоить один war в web-сервер (в том числе со встраиваемой СУБД FireBierd, которую не требуется устанавливать) и быстро начать что-то настраивать свое.
К сожалению в обычных БД не все так просто — удалить поле в существующей таблице... это уже к конкретной реализации БД... Я не являюсь защитником 1С, но пришлось иногда лет 10 подрабатывать на этом поприще, и некоторые реализации подобные видел.. И буст там был задействован и и же с ними...
Короче, пытаюсь сказать — все до нас написано
DTW>>P.S.: Возможно, других заинтересует Ваше предложение, может стоит выложить здесь ссылку?
А>Нет, спасибо, пока не стоит.
А>Сами видите, что проект еще в начальной стадии, в нем не хватает:
А>1. безопасности (права доступа к объектам) А>2. жизненных циклов документов (стутусы) А>3. встраиваемых событий А>4. дополнительных сервисных функций (автопроцедуры, механизм оповещения о событий)
А>кроме того, возможно будет совершенстоваться администраторская часть и все конфигурирование будет осуществляться преимущественно из системы, сейчас XML-файлы.
А>И главное, ведется работа по "быстрому старту" демо-стенда, чтобы для знакомства с системой было бы достаточно деплоить один war в web-сервер (в том числе со встраиваемой СУБД FireBierd, которую не требуется устанавливать) и быстро начать что-то настраивать свое.
Единственное, что мне там не понравилось — скорость обработки ajax-запросов (при открытии и закрытии окон). У меня это делается намного быстрее ... Стоит обратить внимание на этот момент и поискать узкое место, ибо оно там явно есть...
Здравствуйте, Figaro, Вы писали:
F>К сожалению в обычных БД не все так просто — удалить поле в существующей таблице... это уже к конкретной реализации БД... Я не являюсь защитником 1С, но пришлось иногда лет 10 подрабатывать на этом поприще, и некоторые реализации подобные видел.. И буст там был задействован и и же с ними... F>Короче, пытаюсь сказать — все до нас написано
Это я просто к примеру, что если очень надо — можно и физичестки структуру БД изменить, хотя это в корне неправильно.
1С делает то же самое при изменении структуры документов и справочников, но любое изменение чего-то кроме внешних отчетов — это обязательная остановка системы.
Вдогонку:
Создание одинаковых окон-закладок оправдано далеко не всегда, я бы даже сказал, что в большинстве случаев это нельзя допускать, а там можно открыть сколь угодно одинаковых ...
Re[11]: 1C vs php + FireBird
От:
Аноним
Дата:
27.05.09 06:33
Оценка:
DTW>Единственное, что мне там не понравилось — скорость обработки ajax-запросов (при открытии и закрытии окон). У меня это делается намного быстрее ... Стоит обратить внимание на этот момент и поискать узкое место, ибо оно там явно есть...
Да, спасибо, за независимый совет, мы записали это в багтрекер, попробуем оптимизировать, кстати, в FF все открывается намного быстрее.
Если интересно как-то следить за новостями проекта, то мы можем Вас включить в рассылку, это будут не частые информационные письма с добавлением больших функциональностей в систему, и возможно, в какой-то момент Вы сможете при разработке новой системы воспользоваться этим ядром и удешевить процесс производства. Если интересно, напишите письмом, адрес у Вас есть, отписаться сможете в любой момент.
Re[12]: 1C vs php + FireBird
От:
Аноним
Дата:
27.05.09 06:39
Оценка:
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Вдогонку: DTW>Создание одинаковых окон-закладок оправдано далеко не всегда, я бы даже сказал, что в большинстве случаев это нельзя допускать, а там можно открыть сколь угодно одинаковых ...
Да, действительно, тогда напрашивается проверка на открытость и не создавать второй раз.
Зафиксирвоали тоже в багтрекер, думаю, что это не сложно сделать.
Здравствуйте, Figaro, Вы писали:
F>skipped...
F>А при том же сочетании php+<сочетании неважно чего> тож придется тормозить работу... ладно, эт все лирика
Зачем тормозить то?
Разработка и отладка в обоих случаях производится не на боевой системе, но!
в случае с пхп+фб обновление боевой — простое копирование файлов пхп-сценариев и запуск sql-скрипта, вносящего изменения в БД, что занимает пару минут максимум,
а на 1С это:
сравнение,
принятие,
объединение
(частенько все 3 процесса занимают немалое время)
и + если изменения затронули структуру данных — ПЕРЕИНДЕКСАЦИЯ (страшное слово)
у нас одна только переиндексация занимает 30 минут (остальное не предсказуемо по времени).
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Поясню: DTW>На первых этапах, когда происходит разработка базовых элементов интерфейса и в целом движка, которые в 1С уже есть (или почти такие как надо) бесспорно времени будет потрачено больше. DTW>Однако на последующих этапах, когда на 1С придется разрабатывать новое + модифицировать старое, то выигрывать будет уже вариант с php.
DTW>Время, затраченное на каждый этап при использовании 1С будет по началу постоянны, а затем начнет расти. DTW>При использовании же php, время, затраченное на каждый этап, будет постоянно уменьшаться. (стоит пояснять?)
DTW>Это мое мнение, основанное на предыдущем опыте.
Зависит от того, насколько качественно был выполнен первый этап на PHP, разработан UI и насколько гибко можно будет менять логику документооборота.
Нужно смотреть конкретно на задачу.
Здравствуйте, _Oleg_, Вы писали:
_O_>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>Поясню: DTW>>На первых этапах, когда происходит разработка базовых элементов интерфейса и в целом движка, которые в 1С уже есть (или почти такие как надо) бесспорно времени будет потрачено больше. DTW>>Однако на последующих этапах, когда на 1С придется разрабатывать новое + модифицировать старое, то выигрывать будет уже вариант с php.
DTW>>Время, затраченное на каждый этап при использовании 1С будет по началу постоянны, а затем начнет расти. DTW>>При использовании же php, время, затраченное на каждый этап, будет постоянно уменьшаться. (стоит пояснять?)
DTW>>Это мое мнение, основанное на предыдущем опыте.
_O_>Зависит от того, насколько качественно был выполнен первый этап на PHP, разработан UI и насколько гибко можно будет менять логику документооборота. _O_>Нужно смотреть конкретно на задачу.
Верно, зависит, но на то и голова на плечах, чтобы изначально предусматривать универсальность разрабатываемых объектов и возможность простой модификации их.
Re[12]: 1C vs php + FireBird
От:
Аноним
Дата:
27.05.09 08:42
Оценка:
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Вдогонку: DTW>Создание одинаковых окон-закладок оправдано далеко не всегда, я бы даже сказал, что в большинстве случаев это нельзя допускать, а там можно открыть сколь угодно одинаковых ...
Итого, сделали 3 режима:
1. открывать только в одном окне все залкадки
2. работать как сейчас
3. не открывать новую закладку с объектом меню, если уже такая открыта
Я забыл уточнить: 1С рассматривается только версии 7.7, т.к. 8+ здесь никто не знает, а важна скорость.
DTW>Ситуация:
DTW>Есть заказчик, которому не важно в чем будет реализовыван проект, — важна только скорость разработки и модификаций. DTW>Есть два штатных исполнителя.
DTW>Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.
DTW>Т.е. режим работы даже более экзотичен, чем Extreme Programming.
DTW>А теперь сам вопрос:
DTW>Необходимо определиться с выбором средств разработки: DTW>- 1С DTW>или DTW>- локальный сервер Apache + php + FireBird + ajax
DTW>Нужно мнение незаинтересованных лиц.
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Dmitry The Wing, Вы писали:
DC>>>Ужасы какие про 1с рассказываете... DTW>>А разве я не прав и существует автоматика для баккапов в 1С?
DC>Да, неправы. Существует. Начиная от пакетного режима (штатного средства) и до всяких раров и планировщиков (для файловой версии) и sql-jobs для sql-версии.
Я тут пообщался с опытными 1С-никами ... про пакетный режим никто ничего конкретного не сказал, но я понят так, что этот режим вызывается в конфигураторе из меню "Администрирование" — "Сохранить данные" — так? тогда где здесь автоматика?
остальное же не гарантирует, что сохранит полноценную версию данных, т.к. в момент баккапа 1С может что-то успеть записать в чатсь таблиц ... люди ссылаются на то, что баккапы делаются в ночное время, но что если производство круглосуточное? а у нас именно так. нет такого времени, когда никто не работает ...
Сейчас занимаюсь разработкой ERP системы по управлению
персоналом и кадровым делопроизводством. В систему заносится информация
о кандидатах с которыми были проведены собеседования, сотрудники компании (с избыточной информацией по ним) с возможностью
сортировки уволенных, на больничном, в декрете, на стажировке, в штате и т.д.,
штатная структура предприятия, внутренний и внешний кадровый резерв, план подбора и т.д. Для реализации я
выбрал apache, php, mysql. Так же реализована отличная система настраиваемых отчетов (причем даже с диаграммами .
Почему я выбрал не 1С? Потому что считаю что сама 1С не является легко масштабируемой системой, даже
ее ERP(? скорее CMS..) решения требуют больших затрат на лицензирование и оборудование, а сама система требует долго изучения.
Еще к минусам могу отнести частые несовместимости новых версий (например в старой версии платформы есть функция "Пусто" а в новой ее меняют на "НеПусто"), что в итоге опять приводит к расходам на отладку (но это скорее касается 1С8 как программного решения). Далее нельзя налету отредактировать
какой-либо модуль не заходя в саму 1С (из дома не поправишь). Садится и разбираться с тем что написал Рыжиков в своих ERP — Вы
потратите больше времени чем если бы Вы написали ее с нуля. Особых плюсов в 1С я не увидел.
Теперь поговорим о php/js. Да, скорее всего писать проект придется с нуля используя наработки сторонних разработчиков (jquery, prototype,
какие-либо хелперы для php по работе с базами данных и генерацией отчетов). К плюсам могу отнести: простота и скорость создания любых элементов управления и интерфейсов, возможность быстрого редактирования конкретного модуля, легкая масштабируемость (кроме браузера и интернет канала ничего от клиента не требуется). В своей ERP я писал все сам, но для быстроты процесса можно воспользоваться jQuery, extJS (в демках есть прекрасные интерфейсы которые можно сразу использовать, Вам останется только реализовать логику и структуру базы данных). К минусам могу отнести запары связанные с генерацией отчетов (к сожалению готовых классов по работе с Excel/Doc очень мало но эту проблему можно решить используя OLE офиса, что правда привязывает вас к Windows), утечки памяти в самом пхп (обычно решается обновлением версии), оптимизация SQL запросов.
В заключении хочу показать несколько скриншотов своей ERP, как пример:
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Я тут пообщался с опытными 1С-никами ... про пакетный режим никто ничего конкретного не сказал, но я понят так, что этот режим вызывается в конфигураторе из меню "Администрирование" — "Сохранить данные" — так? тогда где здесь автоматика?
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>Я тут пообщался с опытными 1С-никами ... про пакетный режим никто ничего конкретного не сказал, но я понят так, что этот режим вызывается в конфигураторе из меню "Администрирование" — "Сохранить данные" — так? тогда где здесь автоматика?
DC>Странные у Вас "опытные" 1сники...
Видимо этим в кругу моих знакомых никто не пользуется ... да и в справке 1С такого слова не находится ...
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>>Я тут пообщался с опытными 1С-никами ... про пакетный режим никто ничего конкретного не сказал, но я понят так, что этот режим вызывается в конфигураторе из меню "Администрирование" — "Сохранить данные" — так? тогда где здесь автоматика? DC>>Странные у Вас "опытные" 1сники... DTW>Видимо этим в кругу моих знакомых никто не пользуется ... да и в справке 1С такого слова не находится ...
Это слово находится в книжке "Конфигурирование и администрирование" стандартного набора книг из коробки 1с
DTW>Разработка и отладка в обоих случаях производится не на боевой системе, но! DTW>в случае с пхп+фб обновление боевой — простое копирование файлов пхп-сценариев и запуск sql-скрипта, вносящего изменения в БД, что занимает пару минут максимум, DTW>а на 1С это: DTW>[list] DTW>сравнение, DTW>принятие, DTW>объединение DTW>(частенько все 3 процесса занимают немалое время)
Есть хороший пункт "Загрузить изменённую Конфигурацию".
Описанные действия нужны при загрузки стандартных конфигураций (Бухгалтерия, Зарплата) итд.
Так как структура конфигураций могут не совпадать. Если же конфигурация наследуема, то основным является сравнения на этапе разработки, для самоконтроля.
По поводу 7.7 можно добавить ускорение для SQL ввиде 1С, для ДБФ можно сгенерить классы для прямого доступа.
Использование OpenConf_Light_Pack для интеллисенсе, констукторы запросов итд.
По поводу архивирования для дбф вполне подходит внешняя архивация правда после обновления нужно пройтись "Тестирование и исправление БД".
Плюс ДБФ желательно использовать через Терминалы.
Штамповать код на 1С легко и приятно, даже при том минимуме возможностей. Плю использование ВК расширяет горизонты.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Есть хороший пункт "Загрузить изменённую Конфигурацию". S> Описанные действия нужны при загрузки стандартных конфигураций (Бухгалтерия, Зарплата) итд. S>Так как структура конфигураций могут не совпадать. Если же конфигурация наследуема, то основным является сравнения на этапе разработки, для самоконтроля.
S>По поводу 7.7 можно добавить ускорение для SQL ввиде 1С, для ДБФ можно сгенерить классы для прямого доступа. S>Использование OpenConf_Light_Pack для интеллисенсе, констукторы запросов итд. S>По поводу архивирования для дбф вполне подходит внешняя архивация правда после обновления нужно пройтись "Тестирование и исправление БД". S>Плюс ДБФ желательно использовать через Терминалы. S> Штамповать код на 1С легко и приятно, даже при том минимуме возможностей. Плю использование ВК расширяет горизонты.
OpenConf, 1C++, терминал — все это используется.
Обойти сравнение никак нельзя при коллективной работе.
Внешняя архивация все-таки неприемлима, т.к. работа круглосуточна. Поэтому приходится временно выгонять всех и архивировать.
В работе и невооруженным глазом видно различие в скорости получения данных из 1С и аналогичных или даже более сложных данных из нормальных внешних БД.
Также меня не устраивает время, затрачиваемое на внесение простейших изменений в конфигурацию, и необходимость отключения пользователей на это время.
В случае реализации в виде web-сервера пользователи вообще не будет замечать изменения, пока те не коснутся конкретно тех моментов, которые использует данный пользователь.
Да и скорость изменения сценариев пхп намного выше в первую очередь за счет модульности такого кода. В 1С же общие элементы приходится либо совать в глобальник, либо деталь внешними (куча накладок), либо классы 1с++ ... все варианты имеют кучу ограничений ... зачем себя ограничивать изначально, пока есть выбор?
Свобода рисовать интерфейс таким, каким хочется, а не таким, каким разрешено правилами 1С — тоже много значит.
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Также меня не устраивает время, затрачиваемое на внесение простейших изменений в конфигурацию, и необходимость отключения пользователей на это время.
DTW>В случае реализации в виде web-сервера пользователи вообще не будет замечать изменения, пока те не коснутся конкретно тех моментов, которые использует данный пользователь.
Почему??? Можешь использовать Tcp/Ip для связи с 1С. У меня ТСД через Wi-Fi работает под определенным юзером.
Многие кстати используют прямую запись и чтение в БД.
DTW>Да и скорость изменения сценариев пхп намного выше в первую очередь за счет модульности такого кода. В 1С же общие элементы приходится либо совать в глобальник, либо деталь внешними (куча накладок), либо классы 1с++ ... все варианты имеют кучу ограничений ... зачем себя ограничивать изначально, пока есть выбор?
Все зависит от задачи. Когда в модуле проведения 10 тысяч строк 1С кода, куча ветвлений то я лично выберу 1С, или другой фреймворк для работы с Бд как с объектами. Ну и плюс огромное количество кода, которое применяется но не изменяется.
Ваш выбор. А насчет архивации по верху открытых таблиц, ничего страшного. "тестирование и исправление БД" лечит, лишние ссылки, либо настроить архиватор, что бы Journal архивировал в воследнюю очередь. Проверить документы, так или иначе придется проверять и добивать в любом случае.
DTW>Свобода рисовать интерфейс таким, каким хочется, а не таким, каким разрешено правилами 1С — тоже много значит.
есть FormEx от Альфа http://www.dorex.ru/?projects&formex
Приветствую,
стоял похожий вопрос, выбрали C#+DevExpress (XAF,XPO) может будет интересно
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Ситуация:
DTW>Есть заказчик, которому не важно в чем будет реализовыван проект, — важна только скорость разработки и модификаций. DTW>Есть два штатных исполнителя.
DTW>Основной минус — это отсутствие конкретизации в задаче — есть пока только общее направление, и заказчиак не может составить следующий этап, не пощупав предыдущий.
DTW>Т.е. режим работы даже более экзотичен, чем Extreme Programming.
DTW>А теперь сам вопрос:
DTW>Необходимо определиться с выбором средств разработки: DTW>- 1С DTW>или DTW>- локальный сервер Apache + php + FireBird + ajax
DTW>Нужно мнение незаинтересованных лиц.
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Здравствуйте, DenisCh, Вы писали:
DC>>Здравствуйте, Dmitry The Wing, Вы писали:
DC>>>>Ужасы какие про 1с рассказываете...
1С — это и есть ужас.
DTW>>>А разве я не прав и существует автоматика для баккапов в 1С?
Бэкап на горячую в 1С невозможен и автоматики никакой нет. 1С не годится как система энтерпрайз уровня. Так для бухгалтерии из 5 бухов максимум.
DC>>Да, неправы. Существует. Начиная от пакетного режима (штатного средства) и до всяких раров и планировщиков (для файловой версии) и sql-jobs для sql-версии.
Это рары и планировщики существуют сами по себе. А в 1С встроенных средств нет.
Здравствуйте, Figaro, Вы писали:
F>skipped...
F>А при том же сочетании php+<сочетании неважно чего> тож придется тормозить работу... ладно, эт все лирика
Здравствуйте, Figaro, Вы писали:
F>skipped...
F>Вы только забываете — "контроль целлосности данных"... хотя хз, кому Вы это поручите
В 1С-е это сделано через ж.
Всех юзеров отключить, монопольный режим, удаление помеченных объектов. А еще оказываеца и ни все они удаляются.
Собственно идиотизм, почему-бы не сделать так, как в других нормальных СУБД
Здравствуйте, Dmitry The Wing, Вы писали:
S>> Штамповать код на 1С легко и приятно, даже при том минимуме возможностей.
Нда... Месье знает толк в извращениях...
DTW>OpenConf, 1C++, терминал — все это используется. DTW>Обойти сравнение никак нельзя при коллективной работе. DTW>Внешняя архивация все-таки неприемлима, т.к. работа круглосуточна. Поэтому приходится временно выгонять всех и архивировать.
Я ж говорю для ентерпрайза негодна.
DTW>В работе и невооруженным глазом видно различие в скорости получения данных из 1С и аналогичных или даже более сложных данных из нормальных внешних БД.
А офигенно тормозящие отчеты с их идиотским языком запросов.
DTW>Также меня не устраивает время, затрачиваемое на внесение простейших изменений в конфигурацию, и необходимость отключения пользователей на это время.
DTW>В случае реализации в виде web-сервера пользователи вообще не будет замечать изменения, пока те не коснутся конкретно тех моментов, которые использует данный пользователь. DTW>Да и скорость изменения сценариев пхп намного выше в первую очередь за счет модульности такого кода. В 1С же общие элементы приходится либо совать в глобальник, либо деталь внешними (куча накладок), либо классы 1с++ ... все варианты имеют кучу ограничений ... зачем себя ограничивать изначально, пока есть выбор?
DTW>Свобода рисовать интерфейс таким, каким хочется, а не таким, каким разрешено правилами 1С — тоже много значит.
Ну тогда в чем вопрос? Ответ уже известен — надо брать и использовать нормальную СУБД. Например, MS SQL и BLToolkit: http://bltoolkit.net/
Здравствуйте, Serginio1, Вы писали:
DTW>>В случае реализации в виде web-сервера пользователи вообще не будет замечать изменения, пока те не коснутся конкретно тех моментов, которые использует данный пользователь.
S> Почему??? Можешь использовать Tcp/Ip для связи с 1С. У меня ТСД через Wi-Fi работает под определенным юзером. S>Многие кстати используют прямую запись и чтение в БД.
Как-то страшно даже представить ... у 1С есть свой веб-сервер? если нет — то его реализация будет намного геморнее, чем взять тот же апач
Здравствуйте, Igor Beeone, Вы писали:
IB>Приветствую, IB>стоял похожий вопрос, выбрали C#+DevExpress (XAF,XPO) может будет интересно
В итоге шарп генерит бинарники, а это означает, что все равно будут иметь место ситуации, когда систему придется останавливать, пусть и на пару порядков реже, чем с 1С, но будут. К тому же шарпом овладеть несколько сложнее, чем тем же пхп. (Один из разработчиков будет безнадежно отставать поначалу)
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Serginio1, Вы писали:
S>>По поводу 7.7 можно добавить ускорение для SQL ввиде 1С, для ДБФ можно сгенерить классы для прямого доступа.
___>Если есть SQL — (в данном случае) нафиг нужна 1С?
Видимо это опечатка. Serginio1 имел в виду 1С++ ... оно действительно на порядок ускоряет работу с данными, позволяя использовать sql-запросы к dbf, используя внешние драйверы, однако это все равно не сравнится со скоростью доступа к данным полноценных БД.
Здравствуйте, _d_m_, Вы писали:
DTW>>Свобода рисовать интерфейс таким, каким хочется, а не таким, каким разрешено правилами 1С — тоже много значит.
___>Ну тогда в чем вопрос? Ответ уже известен — надо брать и использовать нормальную СУБД. Например, MS SQL и BLToolkit: http://bltoolkit.net/
Как я уже ответил на сообщение от Igor Beeone:
В итоге шарп генерит бинарники, а это означает, что все равно будут иметь место ситуации, когда систему придется останавливать, пусть и на пару порядков реже, чем с 1С, но будут. К тому же шарпом овладеть несколько сложнее, чем тем же пхп. (Один из разработчиков будет безнадежно отставать поначалу)
Здравствуйте, Dmitry The Wing, Вы писали:
___>>Ну тогда в чем вопрос? Ответ уже известен — надо брать и использовать нормальную СУБД. Например, MS SQL и BLToolkit: http://bltoolkit.net/
DTW>Как я уже ответил на сообщение от Igor Beeone:
DTW>В итоге шарп генерит бинарники, а это означает, что все равно будут иметь место ситуации, когда систему придется останавливать, пусть и на пару порядков реже, чем с 1С, но будут. К тому же шарпом овладеть несколько сложнее, чем тем же пхп. (Один из разработчиков будет безнадежно отставать поначалу)
Останавливать что? Если речь идет об ASP.Net+MS SQL, то во всяком случае изменения в СУБД делаются налету. А веб-сервер, что пхп, что аспнет — здесь в одинаковых условиях.
Шарпом овладеть на начальном этапе не сложнее пхп особено если использовать возможности уровня пхп. Так шта...
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Dmitry The Wing, Вы писали:
___>>>Ну тогда в чем вопрос? Ответ уже известен — надо брать и использовать нормальную СУБД. Например, MS SQL и BLToolkit: http://bltoolkit.net/
DTW>>Как я уже ответил на сообщение от Igor Beeone:
DTW>>В итоге шарп генерит бинарники, а это означает, что все равно будут иметь место ситуации, когда систему придется останавливать, пусть и на пару порядков реже, чем с 1С, но будут. К тому же шарпом овладеть несколько сложнее, чем тем же пхп. (Один из разработчиков будет безнадежно отставать поначалу)
___>Останавливать что? Если речь идет об ASP.Net+MS SQL, то во всяком случае изменения в СУБД делаются налету. А веб-сервер, что пхп, что аспнет — здесь в одинаковых условиях. ___>Шарпом овладеть на начальном этапе не сложнее пхп особено если использовать возможности уровня пхп. Так шта...
Может я невнимательно читал, но про ASP там ничего не нашел, потому и предположил про бинарники ...
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>>Свобода рисовать интерфейс таким, каким хочется, а не таким, каким разрешено правилами 1С — тоже много значит. S>>есть FormEx от Альфа http://www.dorex.ru/?projects&formex S>>До кучи http://www.1cpp.ru/forum/YaBB.pl?num=1150707341 DTW>FormEx и 1C++ во многих случаях конфликтуют, поэтому формэкс используется по минимому, но используется.
Здравствуйте, Figaro, Вы писали:
F>Позвольте не согласится по поводу 5.... Перестает работать нормально 7.7 на 30 одновременных... Плюс задница начинается если база ~ 4 Гб и выше...
Это Вы про типовые? А так вполне видел 1с77 конфигурации с 200 пользователей (одновременно) и 50Г базы...
SQL, разумеется.
Не не типовые... навороченные от одной конторы У меня был извращенный вариант: 30 баз ~8 Гб каждая, 4 терминальника Citrix + 1SQL сервер, все четырех-процники... Порядка 300 коннекшинов одновременно... Хреновастенько выдерживали...
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Необходимо определиться с выбором средств разработки: DTW>- 1С DTW>или DTW>- локальный сервер Apache + php + FireBird + ajax
Вообще вопрос скорее для форума "Архитектура ПО". Не могу похвастаться очень хорошим знанием php, но у меня такое впечатление что он не очень подходит для разработки приложений enterprise-уровня. Ну, чтобы далеко не ходить — http://wiki.rsdn.ru/php-defects.ashx и далее по ссылкам на обсуждения.
Так что если уж выбирать именно строго из 1С 7.7 (как я понял с восьмеркой вы работать не можете?) и php — я бы скрепя сердце выбрал бы 1С (хотя и постарался бы рассмотреть возможность перехода на восьмерку).
Если же не ограничиваться этими двумя альтернативами, то имхо есть варианты гораздо лучше — и на вашем месте я бы попробовал их рассмотреть не отметая сразу. Если вас смущает необходимость переучивания специалистов — по моему опыту затраты времени на изучение командой более эффективных инструментов окупаются достаточно быстро.
Здравствуйте, lazymf, Вы писали:
L>Здравствуйте, Dmitry The Wing, Вы писали:
DTW>>Необходимо определиться с выбором средств разработки: DTW>>- 1С DTW>>или DTW>>- локальный сервер Apache + php + FireBird + ajax
L>Вообще вопрос скорее для форума "Архитектура ПО". Не могу похвастаться очень хорошим знанием php, но у меня такое впечатление что он не очень подходит для разработки приложений enterprise-уровня. Ну, чтобы далеко не ходить — http://wiki.rsdn.ru/php-defects.ashx и далее по ссылкам на обсуждения. L>Так что если уж выбирать именно строго из 1С 7.7 (как я понял с восьмеркой вы работать не можете?) и php — я бы скрепя сердце выбрал бы 1С (хотя и постарался бы рассмотреть возможность перехода на восьмерку). L>Если же не ограничиваться этими двумя альтернативами, то имхо есть варианты гораздо лучше — и на вашем месте я бы попробовал их рассмотреть не отметая сразу. Если вас смущает необходимость переучивания специалистов — по моему опыту затраты времени на изучение командой более эффективных инструментов окупаются достаточно быстро.
Почитал статью по ссылке и могу высказать свое мнение:
Такие косяки (в примерах) можно найти в 99.99% языков, начиная с с++, и в большинстве случаев это не косяки, а не умение "готовить" язык, т.е. самое обычное отсутствие устройства "прямые руки".
Мне приходилось работать с большим количеством языков и сред программирования.
Если получится перейти на восьмерку, то скорее всего именно ее и будем использовать, а вот про "варианты намного лучше" хотелось бы услышать подробнее.
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>В итоге шарп генерит бинарники, а это означает, что все равно будут иметь место ситуации, когда систему придется останавливать, пусть и на пару порядков реже, чем с 1С, но будут.
Это ровным счетом ничего не означает. Обновление сайта что с пхп, что асп.нет практически одинаковое время и для пользователя практически незаметно.
DTW>К тому же шарпом овладеть несколько сложнее, чем тем же пхп. (Один из разработчиков будет безнадежно отставать поначалу)
Как языком? Наврядли, в пхп больше тонких моментов, имхо. Самая большая проблема овладеть фреймворками на которых вы будете работать, а вот тут как раз .net фреймворки выигрывают в простоте интеграции, совместимости между собой, интуитивности и логичности API.
Впрочем если никто в команде не писал на асп.нет, но все писали на пхп — пишите на пхп, или пару месяцев продакшен кода не ждите. Если все же рискнете очень рекомендую не париться с освоением asp.net контролов, а писать используя ASP.NET MVC фреймворк, порог вхождения ниже, все параметры приложения гораздо лучше будут. Даже если не станете тестировать контроллеры сейчас, останется возможность написать тесты потом, когда приложение достигнет критической массы.
Здравствуйте, Figaro, Вы писали:
___>>Бэкап на горячую в 1С невозможен и автоматики никакой нет. 1С не годится как система энтерпрайз уровня. Так для бухгалтерии из 5 бухов максимум.
F>Позвольте не согласится по поводу 5.... Перестает работать нормально 7.7 на 30 одновременных... Плюс задница начинается если база ~ 4 Гб и выше...
Ну да, ну да... Только какой ценой? На серверке эдак за 300 килорублей
1С очень плохо масштабируема. Поэтому народ и извращается с терминальными доступами и прочее. ПО сервера терминалов тоже денег стоит.
Здравствуйте, Dmitry The Wing, Вы писали:
___>>Останавливать что? Если речь идет об ASP.Net+MS SQL, то во всяком случае изменения в СУБД делаются налету. А веб-сервер, что пхп, что аспнет — здесь в одинаковых условиях. ___>>Шарпом овладеть на начальном этапе не сложнее пхп особено если использовать возможности уровня пхп. Так шта...
DTW>Может я невнимательно читал, но про ASP там ничего не нашел, потому и предположил про бинарники ...
Ну дак ASP.Net приложения тож на шарпе пишутся. Там и не должно быть что-то про ASP. Здесь как-бы воля твоя — хочешь пиши трехзвенку, хочешь двухзвенку.
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Почитал статью по ссылке и могу высказать свое мнение: DTW>Такие косяки (в примерах) можно найти в 99.99% языков, начиная с с++, и в большинстве случаев это не косяки, а не умение "готовить" язык, т.е. самое обычное отсутствие устройства "прямые руки".
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Почитал статью по ссылке и могу высказать свое мнение: DTW>Такие косяки (в примерах) можно найти в 99.99% языков, начиная с с++, и в большинстве случаев это не косяки, а не умение "готовить" язык, т.е. самое обычное отсутствие устройства "прямые руки". DTW>Мне приходилось работать с большим количеством языков и сред программирования.
Ну, дело ваше конечно, если считаете что php для вашей задачи подходит идеально, а все претензии к нему происходят из неумения готовить — вперед
DTW>Если получится перейти на восьмерку, то скорее всего именно ее и будем использовать, а вот про "варианты намного лучше" хотелось бы услышать подробнее.
А тут все интересно Потому что как только вы избавляетесь от необходимости выбирать строго или 1С или php у вас появляется возможность сначала определиться с архитектурой приложения, а уже исходя из планируемой архитектуры подбирать средства реализации. Вот если забыть про 1С и php, с вашей точки зрения вам что больше подходит — двузвенка или трехзвенка? С веб-интерфейсом или с толстым клиентом?
Здравствуйте, Dmitry The Wing, Вы писали:
DTW>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, Serginio1, Вы писали:
S>>>По поводу 7.7 можно добавить ускорение для SQL ввиде 1С, для ДБФ можно сгенерить классы для прямого доступа.
___>>Если есть SQL — (в данном случае) нафиг нужна 1С?
DTW>Видимо это опечатка. Serginio1 имел в виду 1С++ ... оно действительно на порядок ускоряет работу с данными, позволяя использовать sql-запросы к dbf, используя внешние драйверы, однако это все равно не сравнится со скоростью доступа к данным полноценных БД.
Да имел ввиду 1С++, спасибо. По поводу дбф, то по ссылочке http://1c.proclub.ru/modules/mydownloads/personal.php?cid=115&lid=2019
скорость ооочень удовлетворительна, при чем по сравнению с SQL ты можшь прменять более оптимальные алгоритмы группировок и агрегации, но больше ручного труда. Единственный минус, т.к. за движок был взят BDE есть несовместимость с записью. Чтение идеально.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Dmitry The Wing, Вы писали:
S>> Почему??? Можешь использовать Tcp/Ip для связи с 1С. У меня ТСД через Wi-Fi работает под определенным юзером. S>>Многие кстати используют прямую запись и чтение в БД.
DTW>Как-то страшно даже представить ... у 1С есть свой веб-сервер? если нет — то его реализация будет намного геморнее, чем взять тот же апач
Имел ввиду получаешь данные на вэб сервере, а полученные данные записываешь в 1С либо через ВК как клиент Tcp/Ip.
Либо напрямую в файлы. В былое время когда не было терминалов использовал прослойку через DCOM, но TCP/IP мне лично больше нравится.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Serginio1, Вы писали:
S>>по сравнению с SQL ты можшь прменять более оптимальные алгоритмы группировок и агрегации Z>
Поэтому поводу всегда привожу пример найти время нахождение товара за период, не учитывая периоды с нулевыми остатками.
Навигационным способом, складываются время с момента становления остатка больше нуля и при возникновении нулевых остатков, или с конца периода, сгруппированных по дням. По группировкам, при прохождении по таблицам в порядке время возрастания нужен поиск только ID товара, т.к. для него организуется стек, где последнее значение это нужный день, иначе добавляется новое значение.
Итд.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Поэтому поводу всегда привожу пример найти время нахождение товара за период, не учитывая периоды с нулевыми остатками.
Я не понял задачу
S>Навигационным способом, складываются время с момента становления остатка больше нуля и при возникновении нулевых остатков, или с конца периода, сгруппированных по дням. По группировкам, при прохождении по таблицам в порядке время возрастания нужен поиск только ID товара, т.к. для него организуется стек, где последнее значение это нужный день, иначе добавляется новое значение.
Поэтому решение тоже не совсем понтяно, можно более детально, со структурой таблиц?
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Serginio1, Вы писали:
S>> Поэтому поводу всегда привожу пример найти время нахождение товара за период, не учитывая периоды с нулевыми остатками.
Z>Я не понял задачу
Найти время нахождения товара в продаже, Например в январе с 1 по 10 , и с 21 по 30, товар был в наличие. За период с января по декабрь.
Этих дней получается 20. Навигационным путем получаем остаток на 1 число, ставим дату начало продажи на 1, если остаток больше 0 и проходим по данным движения данного товара (или группы).
Сравниваем текущий остаток с 0 и ставим дату окончания продажи. При поступлении товара если остаток 0 сравниваем дату с с окончанием продаж, и если они не совпадают вычисляем время нахождения в продаже, добавляем к общему счетчику, ставим дату начала и так до конца.
Нет ни каких группировок по дням. Всё очень компактненько и быстро.
S>>Навигационным способом, складываются время с момента становления остатка больше нуля и при возникновении нулевых остатков, или с конца периода, сгруппированных по дням. По группировкам, при прохождении по таблицам в порядке время возрастания нужен поиск только ID товара, т.к. для него организуется стек, где последнее значение это нужный день, иначе добавляется новое значение.
Z>Поэтому решение тоже не совсем понтяно, можно более детально, со структурой таблиц?
Просто ты строишь хэш таблицу, с валуе равным стеку состоящего из полей дата, и количество.
Например Группировка продаж по дням (или неделям итд), учитывая индекс выборки. У тебя нет затрат на поиск по дате, так как она либо последняя, либо нужно добавить.
и солнце б утром не вставало, когда бы не было меня
Да в общем то никто. Тем более, что новые сервера новые возможности.
Мечта программиста хошь применяй навигацию, хошь SQL и все это на сервере без таскания данных туда сюда.
Идеальное размещение для модулей проведения причем в объектном представлении.
Уже мечтаю свалить с 1С, на что то более прогрессивное.
Здесь разговор шел об 1С версии дбф и SQL (там, кстати даже не Sql 2005).
И приведены возможности для дбф даже быстрее чем аналогичный SQL.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Ziaw, Вы писали:
Z>>Здравствуйте, Serginio1, Вы писали:
S>>>по сравнению с SQL ты можшь прменять более оптимальные алгоритмы группировок и агрегации Z>> S> Поэтому поводу всегда привожу пример найти время нахождение товара за период, не учитывая периоды с нулевыми остатками.
Извините, я правильно понял задачу — есть таблица (или представление, или запрос), в которой мы имеем название товара, остаток и дату остатка, и по этой таблице (или представлению, или запросу) нам нужно получить сколько дней у нас остаток каждого товара был отличен от нуля? Ну, тогда для оракла, примерно так:
select itemname, sum(days) as days from
(select itemname,
case
when itemqty <> 0 then
lead(changedate, 1, trunc(sysdate)) over (partition by itemname order by changedate) - changedate
else
0
end days
from test1)
group by itemname;
S>Навигационным способом, складываются время с момента становления остатка больше нуля и при возникновении нулевых остатков, или с конца периода, сгруппированных по дням. По группировкам, при прохождении по таблицам в порядке время возрастания нужен поиск только ID товара, т.к. для него организуется стек, где последнее значение это нужный день, иначе добавляется новое значение. S>Итд.
Я правда не помню есть ли подобный функционал в MS SQL, если мы про связку 1С и MS SQL говорим.
Здравствуйте, lazymf, Вы писали:
L>Извините, я правильно понял задачу — есть таблица (или представление, или запрос), в которой мы имеем название товара, остаток и дату остатка, и по этой таблице (или представлению, или запросу) нам нужно получить сколько дней у нас остаток каждого товара был отличен от нуля? Ну, тогда для оракла, примерно так:
не совсем. в 1С есть остатки на период и движение. То есть мы должны вычислять остаток на каждый момент.
Идея хранить остаток на каждое движение плоха т. к. придется пересчитывать все остатки при проведении задним числом (но пересчитыватся остатки по периодам в большинстве случаев месяц).
Причем в течении дня остаток может менятся от 0 и в обратную сторону.
Но суть не в этом, так или иначе речь идет о навигационном подходе, против стандартного SQL
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, DarkMaster, Вы писали: DTW>>>- локальный сервер Apache + php + FireBird + ajax T>>Мы делаем на Python + PyQt + FireBird — классно получается. DM>И сколько времени вы уже делаете? Вопрос обучаемости и 2-х исполнителей у вас не стоит?
Делаем уже больше 2х лет.
Перешли с Delphi + FB.
Сразу наблюдалось ускорение разработки больше чем в 2 раза.
Сйчас написано некоторое количество утилитного кода под наиболее частые задачи, так что скорость ещё возросла в 2-3 раза.
На начало разработки python знал только 1 человек в команде.
Через неделю остальны стали уверенно писать стандартные места.
Через месяц обращений за помощью стало меньше чем было до переода.
П.С. Пока нет времени, но как только появится, мы собираемся выложить свои наработки в свободный доступ.
