Вход | Регистрация

  1  2  3   
1С:Предприятие ::

Метки: 

работать в тестовом или в рабочем конфигураторе?

Я
   ASimonova
 
23.10.17 - 10:44
у нас скульная база с 10-20 постоянно рабочими пользователями. я программист, всегда работала в рабочем конфигураторе, потом в конце рабочего дня принимала все изменения. переехали на новый сервер, появились ошибки СУБД, теперь админ мне говорит, что так нельзя и надо работать в тестовом конфигураторе, а рабочий вообще не открывать пока пользователи в базе.
у меня очень много мелких изменений, в т.ч. в структуре баз данных, так что временно'й целесообразности в этом нет: принятие этих изменений в рабочем конфигураторе займет столько же времени сколько и в тестовом. насколько прав наш админ? действительно все работают в тестовом несмотря ни на что?
 
 
   vi0
 
101 - 23.10.17 - 15:32
(98) а причем здесь хранилище?
   Segate
 
102 - 23.10.17 - 15:35
(98) походу кто-то тут не представляет, как работает хранилище )
   vde69
 
103 - 23.10.17 - 15:39
(97) не верю...

не однократно встречал проблемы с хранилищем, даже на ровном месте, банально падает оно периодически при частом совместном использовании (как минимум раз в год его пересоздавать надо), а уж про "потеряли мои изменения" и не говорю, это вообще песня постоянная ...
   Segate
 
104 - 23.10.17 - 15:40
(103) за 8 лет работы лично у меня было ровно одно падение хранилища(восстановили из бекапа) и пара тройка проблем с данными, но только по моей или еще чьей нибудь глупости...
Рил ток, синк эбаут ит xD
   AlfaDog
 
105 - 23.10.17 - 15:42
(103)

Если будут технические проблемы я думаю надо проинформировать 1с, я не думаю что они Ваши проблемы не решат.

У меня лично проблем не было.

А так и базы бывают падают. Бэкапы никто не отменял.
   Smile 8D
 
106 - 23.10.17 - 15:44
(103) На 8.1 и 8.2 регулярно были такие проблемы с выходом из строя хранилища. На 8.3 уже несколько лет работаем и (тьфу тьфу тьфу) никаких проблем с потерей данных или выходом из строя базы хранилища не было.
   akronim
 
107 - 23.10.17 - 16:05
(85) "без обновления в режиме предприятия можно было поставить под замену(изменить текст выполняемого кода) любую процедуру, любую форму"

Выполнить(СтрокаВ10кб) ??
   Segate
 
108 - 23.10.17 - 16:08
(107) тип того.
   _Дайвер_
 
109 - 23.10.17 - 16:12
(0) Давай познакомимся) Я тебя буду оберегать, и будем учиться друг у друга;)
   Segate
 
110 - 23.10.17 - 16:13
(109) я все думал, как скоро появится пикапер который глянув на фоточку тс начнет ее клеить.
 
 Рекламное место пустует
   _Дайвер_
 
111 - 23.10.17 - 16:16
(110) Красивые и умные девушки прекрасны! Особенно если она еще программист)
   _Дайвер_
 
112 - 23.10.17 - 16:18
А по теме, я лично работаю в тестовых конфигурациях, и потом обновляю при помощи Сравнить/Объеденить
   Mr_Best
 
113 - 23.10.17 - 16:24
(96) как, как, вот так Коллеги, осторожно, версия 8.3.10.2580

Но от хранилища подключенного к рабочей отказываться не хочется, так как если руки прямые + сама 1С не глючит, это крайне удобно. Проверено годами. Заморачиватся с поставкой какой смысл, если ты конфигурации для своей конторы пишешь ?
   Mr_Best
 
114 - 23.10.17 - 16:27
По моему опыту с хранилищем подключенным к боевой работать можно и нужно. Единственный риск - это кривые руки разработчиков платформы, из за которых хранилище может дать сбой как по ссылке выше.
   sapphire
 
115 - 23.10.17 - 16:53
(114) да, да, да, конечно.
Еще git поднять, сервер сборки, сервер тестирования, сервер публикации релиза...

(0)
1) работать в рабочем конфигураторе моветон.
2) разрабатывать на разработческой
3) тестировать на тестовой.
   spiller26
 
116 - 23.10.17 - 16:55
(114) 2 раза на грабли наступал при динамическом обновлении.
Больше не охото, работа становилась на пару часов пока чинил.
Если ляжет порвут первые это бухи, потом и другие подтянуться.
Лучше используйте регламентный час, для обновления и разработку вести на сервере разработчиков, чтобы не мешать пользователям.
На боевом серваке тестить тоже зло, не есть хорошо.
   dmpl
 
117 - 23.10.17 - 17:05
(101) Читаем (66) до просветления. Подсказка: где будет храниться недоделанный функционал, и как будет обеспечиваться актуальность этого места.

(102) У вас же недоделанное хранится не в хранилище. Забыли уже?
   dmpl
 
118 - 23.10.17 - 17:06
(107) Можно внешней обработкой.
   Segate
 
119 - 23.10.17 - 17:08
(117) я помню =) и знаю что с конкретным объектом в один момент времени работает один программист. Он, по завершении кладет изменения в хранилище, следующий при захвате объекта получает эти изменения и продолжает разработку. не получить их он не может, это стандартная процедура при работе с хранилищем. и я не вижу в какой момент могут потеряться данные )
   DexterMorgan
 
120 - 23.10.17 - 17:34
(119) Я точно не вспомню, но возникали проблемы при динамическом обновлении какой-то конфигурации (не рабочей) подключенной к хранилищу, приводящие к потере изменений. Как гарантировать, что какой-то программист не задинамится?
А нужно ли это вообще? Ну и опять же наглядность изменений при сравнении-объединении не бывает лишней никогда. В какой-то мере это частично решает проблему хотфиксов. Я честно не вижу плюсов подключения рабочей к хранилищу, вообще никаких, кроме некритичного увеличения скорости обновления
   Mr_Best
 
121 - 23.10.17 - 17:42
(119) ну когда у тебя 30 баз однотипных, то падения скорости обновления + количество человеческого фактора без использования хранилища очень заметно возрастает.

Но все же, тут нужно выбирать по ситуации, если 30 баз и в каждой по 1-2 пользователя работает, пожалуй можно и подключить. Если одна база на 300 пользователей и 500 гиглв, наверное лучше не рисковать, баги бывают. И т.д. ...
   _Дайвер_
 
122 - 23.10.17 - 17:42
(120) Для групповой разработки норм, но не для того чтобы внести изменения и обновить потом основную
   Mr_Best
 
123 - 23.10.17 - 17:46
(122) основную одну ? а если их 30 или 50 ? Гораздо быстрее через хранилище. Повторюсь, вся проблема вопроса "использовать или не использовать хранилище с рабочей" исключительно из-за того, что хранилище работает через раз)))) И в этом вина не программиста 1С, а программиста С++ написавшего хранилище. В остальном, проблем не вижу. Если релиз платформы стабильный, то проблем не вижу.
   DomovoiAtakue
 
124 - 23.10.17 - 18:05
Вот тут пишут о работе 15 программистов в одной базе. Один программист во многих базах это почти везде и это понятно. А что делают 15 программистов в одной базе? Что за задачи они решают? (мне просто интересно для себя)
   DomovoiAtakue
 
125 - 23.10.17 - 18:23
К чему вообще приплели хранилище? ТС работает одна, зачем ей хранилище? Хранилище - глючная вещь и если у кого-то за его практику не было глюков, то просто повезло или у вас мало опыта, читайте мисту. Хранилище вообще ставят только студентам, профессионалы итак знают какие объекты им нужны будут и в чужие не полезут.
Кстати тут упоминали динамическое обновление - табу, может полететь база или побиться.
   0xFFFFFF
 
126 - 23.10.17 - 18:33
(0) админ врет. В тестовой разрабатывают только трУсы, пороха не нюхавшие.
Настоящие мужики пишут сразу в боевой. Тем более когда очень много мелких изменений. Ну там реквизит добавить в справочник/рег сведений на пару миллионов строк или например расчет цен поменять - тестовая-шместовая - нафиг эти прослойки, долго это все.
Девиз настоящего одинэсника - куяк куяк и в продакшн.
Будьте смелее, не бойтесь своих желаний.
   DexterMorgan
 
127 - 23.10.17 - 18:41
(124) А что такого? Представь внедрение УТ11 на овер 300 пользователей: там продажи (возможно розница), маркетинг, закупки, склад, фин отдел. Не говоря уже про обмены с сайтами, бух и проч.
   DexterMorgan
 
128 - 23.10.17 - 18:46
Сам не работал, но слышал, что ПЭКе овер 20 прогов)
   Mr_Best
 
129 - 23.10.17 - 18:48
(126) +100500
   Йохохо
 
130 - 23.10.17 - 18:51
(126) на РИБе из кабака в ночь на понедельник
   DomovoiAtakue
 
131 - 23.10.17 - 19:07
(127)Смешно:) С каких пор функционал для 10 или для 300 пользователей разный стал?:) Ну 2 прога на допилку функционала, 1 на обмены, ну если очень захотеть то 2 - остальным то что делать?
   dmpl
 
132 - 23.10.17 - 20:35
(119) А зачем ему их захватывать? Он в своей копии делает все, прежде чем вносить изменения в хранилище. Там этого управления тупо нет.
   Новиков
 
133 - 23.10.17 - 22:06
А как вы без хранилища (если это зло и фи-фи-фи у вас) смотрите историю изменения объекта в конфигурации? +100500 cf'ников сравнивать между собой? Им какие-то еще видимо имена нужно давать соответствующие типа cf_22_10_217?

Мне правда интересно, как без хранилища можно жить, при этом иметь историю изменений конфы?

Кажется, слухи о смерти хранилища сильно преувеличены.
 
 
   Филиал-msk
 
134 - 23.10.17 - 22:29
(133) Классическим велосипедом они пользуются - комментариями в коде. Что данный фрагмент изменил Петров Вася 12 апреля с 42 размером ноги. Вот тут начал, а вот тут прекратил. Предыдущая версия кода трогательно комментируется блоком. И так раз 10...
При этом всем возмущенно рассказывается, что эта зелёная плесень в коде очень сильно помогает.
   youalex
 
135 - 23.10.17 - 22:30
(0) Админ прав. Ты тоже - права. Но работать лучше в тестовой базе, изменения на рабочую накатывать с тестового сф-ника (как хороший вариант - через поставку из хранилища, к к которой подключена твоя тестовая база)
   rudnitskij
 
136 - 23.10.17 - 23:28
(39) "Лет 5 назад, когда на фикси работал, подключал хранилище к рабочей УТ. Иногда ВДРУГ пропадали внесенные ранее в рабочую изменения. С третьего раза я все понял и далее рабочую обновлял только через cf." - я вот с третьего раза понял, что надо сперва последнюю версию из хранилища получить и уже ее ковырять. А изменения ВДРУГ пропадают обычно потому, что вносишь их не в последнюю версию конфигурации
   rudnitskij
 
137 - 23.10.17 - 23:30
(98) "2 программиста в своих базах правят один объект" - если один прогер захватил объект в хранилище, второй его редактировать не сможет
   jsmith82
 
138 - 24.10.17 - 00:07
Это больше вопрос религии
   dmpl
 
139 - 24.10.17 - 08:13
(137) А теперь читаем (66).
   DexterMorgan
 
140 - 24.10.17 - 09:26
(131) Мне тоже смешно тебя читать) Ларечник детектед
   aka AMIGO
 
141 - 24.10.17 - 09:29
140 постов, и 140 мнений.
Резюме: разрабатывайте, как вам удобно, а уж жизнь откорректирует вас, с вашим методом, как ей нужно.
   Новиков
 
142 - 24.10.17 - 09:33
(141) когда "без_хранилищники" ответят на (133) тогда и разговор будет. Пока ответа нет. Его кстати и не будет. Но само решение, конечно же, есть. Но оно по трудоемкости в разы (если не в десятки раз) сложнее, чем с хранилищем. А эти разговоры - рабочую базу не подключать к хранилищу, имеют место быть очень давно, с момента изобретения оного. Однако если вы не разработчик типовой и отраслевой, то подключение хранилищу рабочей базы, единственно простой и быстрый способ обеспечить коллективную разработку с последней редакцией конфы. Про всякие новоделы аля гит и прочее мы сейчас пока умолчим.
   Шаман
 
143 - 24.10.17 - 09:57
Админ твой прав , в тестовом работай.  а после ухода всех сотр домой вноси изменения в рабочую ,не забудь архив копии делать
   Шаман
 
144 - 24.10.17 - 09:59
я динамически вношу изменения в базы , у бухов вылетает окошко обновить .их это достало особенно в период сдачи отчетности
   DomovoiAtakue
 
145 - 24.10.17 - 11:29
(133)Бекапы перед внедрением все равно делаете, вот вам история на крайний случай. Но как правило никакой истории изменений не надо.
   DexterMorgan
 
146 - 24.10.17 - 11:32
(142) Да никто не отказывается от хранилища, вопрос только в подключении его к прод
   DexterMorgan
 
147 - 24.10.17 - 11:33
(142) что мешает вести коллективную разработку в хранилище, не подключенном к проду?
   DomovoiAtakue
 
148 - 24.10.17 - 11:38
(140)Так что ж делают остальные?
   Fish
 
149 - 24.10.17 - 11:45
(148) Не поверишь, но разрабатывают. Про внедрение в (127), конечно бред написан, но полно нетиповых или отраслевых конфигураций, в разработке которых участвует целый отдел программистов. Лично работал с конфой, где было 6 разработчиков, и это была не сильно большая контора.
 
 Рекламное место пустует
   Timon1405
 
150 - 24.10.17 - 11:57
(148) 3-5 на упр учет/(5-15) если производство
+2-5 регл учет+ 2-3 на обмены+ поддержка 1линия отдельно. +РП, бизнес-аналитик, архитектор, эксперт по тех части(это разные люди).
в вашем примере 10-300 юзеров фиксированная по количеству человек в отделе разработки остается только часть кроме разработчиков. по мере усложнения системы, нужно расширение именно в количестве рабочих рук.
   DexterMorgan
 
151 - 24.10.17 - 15:07
(149) Да ладно? И в чем бред? Я послушаю и приведу пример тебе на 10 разработчиков в УТ
   DexterMorgan
 
152 - 24.10.17 - 15:20
(149) Оптовая/розничная торговля автозапчастями, 11 магазинов + бэк, все в одной базе, 700+ активных подключений (ну по крайней мере на момент ухода), 250 000 позиций номенклатуры:

Розинца - 1, Продажи - 2, Закупки - 1, Склад - 1, Бух/Фин - 1, Обмены/выгрузки сайты/бух/антор/WMS/проч - 2, Логистика/Обеспечение - 1, ведущий (в основном постановщик/производительность) - 1
   DomovoiAtakue
 
153 - 24.10.17 - 15:23
(150)Я думаю конечно что это ерунда какая-то а не работа, но спорить не буду, допустить могу что имеет место найтись такой случай когда сели куча прогов и быстро стартанули конфу и предусмотрев нужды клиента допилили ее. Но в теме как я понял приводят примеры постоянной работы кучей прогов в одной базе.

Не показательно конечно, но вот столкнулся я в этом году по совместной работе с организацией, в которой сидит около 8 прогов в одной базе. Это просто фиаско. каждый знает какой-то кусок в базе и когда возникает вопрос апгрейда - вместо 15 минут неделю решают как дорабатывать функционал, про скорость доработок я уже молчу. В итоге они в 8 человек работают в раз 100 медленнее и совсем не качество чем я один. Но как я сказал это совсем не говорит о том что много прогов в одной базе это точно будет плохо. Интересно узнать как без кучи прогов не обойтись в одной базе.
   DomovoiAtakue
 
154 - 24.10.17 - 15:25
+(153)Точнее в каких базах и при каких задачах необходимо много прогов?
   DomovoiAtakue
 
155 - 24.10.17 - 15:38
(152)Это переход с одной конфы на другую?
   Fish
 
156 - 24.10.17 - 15:40
(151) Бред в том, что разработка и внедрение готового продукта несколько разные вещи. Для ВНЕДРЕНИЯ типового решения разработчики не нужны, нужны внедренцы. И их количество не зависит от количества пользователей базы.
Другое дело - доработка типовой. Но тут опять же - количество разработчиков никоим образом не зависит от количества пользователей в базе. Поэтому я и написал, что фраза "внедрение УТ11 на овер 300 пользователей" - бред, т.к. к количеству разработчиков они никоим образом не относится.
   ildary
 
157 - 24.10.17 - 15:41
(153) есть еще такой вариант - программистов много, потому что персонал совсем буратинистый и приходится каждому подтирать сопли (помогая найти ему кнопку выбора периода), а также для написания сотрудникам 100500 вариантов отчетов (у меня совещание через полчаса, а у меня цифры не готовы).
   Fish
 
158 - 24.10.17 - 15:46
(154) В основном в самописных или в сильно переработанных типовых (где типовая была взята лишь за основу). И это, как правило, не БП и не ЗУП, и обычно про обновления от поставщика в таких конфах можно забыть, т.к. в них идёт постоянная доработка.
   DexterMorgan
 
159 - 24.10.17 - 15:46
(156) пфф, назови г0вно-розой пахнет все равно г0вном, речь шла о количестве программистов (ок, пусть внедренцев). От пользователей базы зависит косвенно, как правило, чем больше пользователей - больше и сложнее бп и больше хотелок.
   DexterMorgan
 
160 - 24.10.17 - 15:47
(155) изначально да, с аксесса, древнейшего и кучи баз
   DexterMorgan
 
161 - 24.10.17 - 15:48
(156) Опять же от количества пользователей зависит производительность, иногда чела выделяют, иногда бегут к Гилеву
   Fish
 
162 - 24.10.17 - 15:49
(159) Да не зависит от кол-ва пользователей. Совсем. У нас была своя разработка на основе одной отраслевой конфы (перепиленная на 90%). Когда добавилось ещё несколько филиалов, для нас абсолютно ничего не изменилось - в новых филиалах те же самые бизнес-процессы. И кол-во программистов зависит не от количества УЧАСТНИКОВ бизнес-процессов, а от количества САМИХ бизнес-процессов.
   Fish
 
163 - 24.10.17 - 15:50
(161) "иногда чела выделяют, иногда бегут к Гилеву" - Такой человек называется сисадмин, и к программистам, а тем более к конфигураторы не имеет отношения.
Конечно, если вы используете запросы в цикле, то вам и отдельный программист на оптимизацию кода будет нужен :))
   Fish
 
164 - 24.10.17 - 15:52
(159) "чем больше пользователей - больше и сложнее бп" - А вот и нет. 1 человек вполне может выполнять сложный бизнес-процесс, а 100 - простейший. Никакой зависимости тут нету.
   DexterMorgan
 
165 - 24.10.17 - 15:52
(162) 5 и 1000 одно и тоже?

Я же написал тебе зависит от кол-ва пользователей 1.Производительность
2.Косвенно зависит, тк увеличивается объем хотелок и сложнее БП
(163) БУ_ГА_ГА, это называется "Эксперт по тех вопросам"
   DexterMorgan
 
166 - 24.10.17 - 15:53
(164) Мля, в ларьке один чел и закупщик, продажник и логист.
   DexterMorgan
 
167 - 24.10.17 - 15:54
(164) Кароче еще один ларечник детектед
   DexterMorgan
 
168 - 24.10.17 - 15:56
(163) походу запросы в цикле - это все, что ты знаешь о проблемах с производительностью? А про проблемы с параллельностью не слышал? А что такое ЦУП, сервисы Гилева для чего?
   DexterMorgan
 
169 - 24.10.17 - 15:56
(168) + это тоже должен админ уметь?
   Fish
 
170 - 24.10.17 - 15:56
(167) Конечно ларёчник. Только вот пока доводилось работать в ларьках от 1,5 тысяч человек численностью и более. :)))
Но ты видно в более крупных корпорациях работал, куда уж мне :))
   DexterMorgan
 
171 - 24.10.17 - 15:57
(168) Распараллеливание в несколько фоновых заданий проведение по партиям - это тоже к админу?
   DexterMorgan
 
172 - 24.10.17 - 15:57
(170) Да-да-да, по диалогу заметно сразу))))
   Fish
 
173 - 24.10.17 - 15:59
(168) " А что такое ЦУП, сервисы Гилева для чего?" - По мне, так бесполезная фигня это. Мы как-то и без них обходились прекрасно. Но кому-то, возможно, не хватает умения без этого обойтись.
   DexterMorgan
 
174 - 24.10.17 - 16:00
(173) без комментариев, с тобой все понятно =)
   Fish
 
175 - 24.10.17 - 16:01
(174) Если ты не можешь обойтись своими силами и знаниями без Гилёва, это не значит, что он жизненно необходим всем :)))
   DexterMorgan
 
176 - 24.10.17 - 16:03
(175) Ты просто не сталкивался с проблемами крупных внедрений
   DexterMorgan
 
177 - 24.10.17 - 16:05
(175) Я не говорю, что он необходим, я говорю о проблемах возникающих в высоконагруженных системах, напрямую зависящих от количества пользователей
   Fish
 
178 - 24.10.17 - 16:05
(176) Сталкивался, и вполне успешно решали их самостоятельно. Без привлечения сторонних "оптимизаторов" типа Гилёва. Рекомендации его, конечно изучали, для общего развития, но далеко не всё из его рекомендаций для нас были новостью.
   Fish
 
179 - 24.10.17 - 16:06
(177) Открою тебе ещё один секрет: для увеличения производительности системы тоже не надо увеличивать штат программистов. Достаточно повышать квалификацию существующих :)))
   DexterMorgan
 
180 - 24.10.17 - 16:07
(178) Мля, да без ЦУПа и сервисов невозможно решить проблему с параллельностью
   Fish
 
181 - 24.10.17 - 16:08
(180) Правда что ли? Ты серьёзно? А как по-твоему, их решали ДО появления ЦУПа? :)))
   DexterMorgan
 
182 - 24.10.17 - 16:08
(179) Причем тут это? Представь есть задачи, под них выделено X программистов. Всех все устраивает, но вот начинаются проблемы что выгрузка идет 4 часа, что расчет сс за ночь не выполняется ну и т.д. Вот берут в штат еще чела под это
   DexterMorgan
 
183 - 24.10.17 - 16:10
(181) Другими инструментами. А если про 1с, то раньше она и поддерживала такие объемы, как сейчас
   Fish
 
184 - 24.10.17 - 16:11
(182) При том, что разговор изначально шёл о необходимости работы нескольких программистов в одной конфигурации. И не более.
" но вот начинаются проблемы что выгрузка идет 4 часа, что расчет сс за ночь не выполняется ну и т.д. Вот берут в штат еще чела под это" - Опять неудачный пример. Такие проблемы надо решать максимально быстро, а новому человеку понадобится время на изучение. Не взлетит.
   DexterMorgan
 
185 - 24.10.17 - 16:11
(181) Не ну конечно, если ты эксперт по скл, то тогда тебе они не нужны, но я что-то в этом сомневаюсь
   DexterMorgan
 
186 - 24.10.17 - 16:12
(184) Ерунда, для того, чтобы решить проблемы с производительностью, в логику самой выгрузки вникать, как правило, не нужно. Ты просто нихя не понимаешь в этой теме
   Fish
 
187 - 24.10.17 - 16:13
(185) Сомневайся. И да, я не эксперт по СКЛ, но работал в команде, где таковые присутствовали.
   Fish
 
188 - 24.10.17 - 16:15
(186) Ну конечно, я ничего не понимаю. У тебя же всё просто: чем больше штат программистов, тем выше производительность. Придёт новый "варяг" и всё тут же поправит, не вникая. У нас таких "спецов" даже на порог не пускают :))
   DomovoiAtakue
 
189 - 24.10.17 - 16:17
(182)Наверное надо дать задание на переделку тому кто недодумал или скосячил. А смысл нанимать нового прога, которого нанимать может пол года будете, потом пока он въедет во все еще пол года. лучше дать текущему чтоб за час ну или день разобрался и поехали дальше клепать новые задачки.
   DexterMorgan
 
190 - 24.10.17 - 16:19
(188) Ты перевираешь смысл моих слов. Я говорил, что от количества активных подлкючений прямо и иногда косвенно зависит количество требуемых программистов
   DexterMorgan
 
191 - 24.10.17 - 16:20
(189) Если проведение по партиям - это типовой механизм и виновных нет? Просто он перестал за ночь выполняться
   DexterMorgan
 
192 - 24.10.17 - 16:22
(189) Поверь мне, не все программисты могут оптимизировать свой код, я те, кто могут справедливо хотят за это больше денег. Посмотри сколько спецов по платформе и сколько экспертов, это не зря так
   Fish
 
193 - 24.10.17 - 16:22
(190) Косвенно - возможно, но очень косвенно. А вот прямой зависимости нет и быть не может. Если, конечно, на программистах не лежит функция службы техподдержки - тогда да, чем больше пользователей, тем и программистов понадобится больше. Но я бы это решил созданием службы поддержки без увеличения штата программистов.
   DexterMorgan
 
194 - 24.10.17 - 16:23
(193) Я тебе ответил на это уже
   Fish
 
195 - 24.10.17 - 16:26
(194) Ах, да. Я и забыл, что говорю с экспертом мегакорпораций. У нас, ларёчников, как-то проще всё. А главное, не раз проверено на практике и работает в жизни, а не в теориях :))
   ac13
 
196 - 24.10.17 - 16:26
А как обновлять? Нетиповая конфа, днем в ней больше 100 юзеров. Когда её обновлять?
   Fish
 
197 - 24.10.17 - 16:28
(196) Ночью/вечером, вестимо.
   Ymryn
 
198 - 24.10.17 - 16:35
Хранилище по факту всем хорошо и удобно, кроме двух пунктов.
1) Файловый вариант может повреждаться. И в моей практике несколько раз было потеря изменений, а один раз даже повреждение конфигурации, что при получении изменений из хранилища в базе повреждалась конфигурация. Лечилось пересозданием хранилища.
2) Если брать более надежный вариант с серверным хранилищем, то начинается проблема с платформами. Что если тестовый сервер решили поднять на платформу повыше, чтобы протестировать поведение базы на новой платформе, то вы уже к хранилищу не подключитесь. Ибо несоответствие версий.

Но как бы альтернатив хранилищу я все равно сейчас не вижу. Обновление cf-ником сейчас уже выглядит настолько топорно и неудобно, что чур-чур-чур.
   DomovoiAtakue
 
199 - 24.10.17 - 16:38
(191)Тогда весь ваш отдел нафиг не нужен:) Вся ваша работа ради того чтоб работал партионный учет в первую очередь.
(192)Это не программисты.

В общем итог таков:
Хранилище - для студентов.
Наняли 15 студентов, посадили их за компы, поставили над ними руководителя, подрубили их к хранилищу, что б они своими корявыми руками друг другу работу не портили и вперед. И сидят они по 10 раз одно и тоже переделывают, т.к. опыта нет и дальновидность страдает. Если что, как нам сказали, при доп проблемах быстро нанимается еще один прог: норм прога фиг найдешь, а студента конечно быстро и по той же схеме вперед.

Если говорить о написании функционала, то вот это все "Розинца - 1, Продажи - 2, Закупки - 1, Склад - 1, WMS, Логистика" программирует один человек, максимум под wms можно выделить еще одного. Вы задумайтесь где ларек, а где нет.

На предприятиях не возникает с такой скоростью количество задач, чтоб загрузить 15 программистов. Это образно каждый день надо требовать по 2-3 абсолютно новых отчета или новый документ.
   vis_tmp
 
200 - 24.10.17 - 16:44
200

  1  2  3   

Список тем форума
Рекламное место пустует Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует