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

Форумы на Кубань.Ру


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

Метки: 

Вот беремся за задачу

Ø
Я
   }{мурый АСУшник
08.09.00 - 20:36
Хотим вот SQL комплексную запустить на 50 рабочих местах.
Серверочек будет такой:
2XeonIII
1GB RAM
RAID-5 4*18GB
2*100 Мбит карты
И еще документ по оптимизации MS SQL 7.0 от Microsoft.
(ну очень уж большие у нас объемы - больше гига за год)
Потянет?
 
 
   Читатель
1 - 08.09.00 - 21:14
Интуитивно можно придти к заключению, что автоматизацию учета на предприятии такого масштаба вряд ли удастся оптимально решить внедрением программы, которая стоит 1360 у.е. Скорее можно заполучить проблем на сумму на порядок или два больше.
   Даин
2 - 09.09.00 - 02:01
При таких объемах и затратах на железо купите (или качните) Oracle, например, и в течение 9-12 мес. дружный коллектив Хмурых АСУщников накропает прикладнуху для любого учета (а может и быстрей, но вряд ли).
Я тАк думаю.
З.Ы. это не реклама. Можно попробывать какую-нибудб другую RDBMS, ну в смысле Базу с Большой буквы.
   БТР
3 - 09.09.00 - 03:01
Зависит от модели учета. Комплексная требует очень правильного документооборота и дисциплины при его ведении. Шаг влево - шаг вправо грозят постоянными перепроведениями. У нас база 500 Мб за 1.5 месяца, перепрведения идут ночами... Правда и учет дикий - больше трех сотен розничных точек, налог с продаж по каждой с группировкой по налоговым инспекциям, приходные накладные бьются всегда с опозданиями.
Сервер PII-450 x 2, 512 Mb RAM, на том же сервере еще 12 БД попроще. Но многие документы уже переписали и поубирали почти все регистры.
   Николай Бурдули
4 - 09.09.00 - 10:28
ИМХО: Комплексная - сук на котором сидеть нельзя. Его рубить сразу надо!.
Лучший Вариант - своя объединенная конфа для Бух и Торговли + стандартная ЗиК. За основу своей можно взять либо типовую торговлю, либо бухгалтерию (Что больше нужно сразу, по вкусу :-))))
   Тот
5 - 09.09.00 - 12:09
2Читатель: Решить можно. Работать будет. Я думаю, что Хмурый АСУшник понимает, на что идет по части учета. Его интересует комфортность работы, а не проблемы эксплуатации системы в целом. Могу сказать, что подобный опыт внедрения имеем. С клиента уже сняли за полтора года тысяч семдесят баксов. Но клиент доволен... Т.е смелее надо! Проблемы надо решать по мере поступления и ничего не бояться. Конфигурацию все равно придется оригинальную делать. Я считаю, что с нуля в этом случае написать будет проще, чем подстроить "готовую", Т.е. с Николаем Бурдули согласен полностью.
   Читатель
6 - 09.09.00 - 12:35
Не ясен статус Хмурого АСУшника. Если Хмурый АСУшник - заказчик, то ему надо посмотреть на предмет использования прочие пакеты типа Галактики или забугорные (за 70 штук зеленых, наверное, можно к ним подступиться). А если он занимается внедрением 1С, то совет Н.Бурдули оптимален.
   Тот
7 - 09.09.00 - 12:48
2Читатель: На 1С все равно будет намного дешевле. А за 70 зеленых не очень подступишься. Я думаю, что на 1С и за 20 зеленых кое-что получить можно. А вот с такой суммой подступиться даже к Галактике толком нельзя.
   }{мурый АСУшник
8 - 09.09.00 - 16:57
натурально, предлагали нам систему на Btrieve SQL с нуля писать. Запросили 50 Килобаксов.
   }{мурый АСУшник
9 - 09.09.00 - 17:00
Даин, а вы не в курсях, что SAP на MS быстрее SAP на ораклях? Ну и дешевше.
   }{мурый АСУшник
10 - 09.09.00 - 17:12
БТР, свяжись со мной, пожалуйста, по почте. Если в Москве, заработаешь.
 
 
   Тот
11 - 09.09.00 - 22:22
Про SAP тоже кое-какую информацию имеем. Проблемы те же, что и при 1С. Вопросы комфортности работы, вроде, лучше решаются. Но организовать учет - какая разница. Самым главным ее достоинством считаю цену. Бухгалтер понимает - при такой цене - либо он будет работать с этой системой, либо она будет работать без него. А с 1С в этом плане проблемы на уровне капризов бухгалтеров... Слишком уж дешево получается...
   Mx
12 - 10.09.00 - 15:10
Хмурому
А "больше гига за год" - это чего?
Ты лучше скажи количество документов в месяц (есть ли большие, больше 100 строк), доля оперативного учета и будет ли массовое забитие документов задним числом. У меня работают базы 500 мегов за год и на SQL и на DBF, пользователей ~30.
   БТР
13 - 10.09.00 - 23:20
2 Хмурый АСУшник. Вообще-то работаю в Питере, но если интересуют конкретные траблы, перечисляю.
1) Очень серьезно нужно продумывать и моделировать реальный документооборот. Нельзя допускать движений задним числом (хотя бы потому, что в действительности таковых быть не может - просто порой приходится сначала приход делать фиктивный, а потом корректировать)
2) Максимально разносить оперативный и бухгалтерский учет, а в "тяжелых" документах даже выносить из проведения все операции не требующиеся сей момент
3) Все оперативные индикаторы выносить в отдельные справочники и регистры и отображать их оперативно в документах или обработках, без лишних обращений к большим отчетам, иначе все начнут умирать
4) Максимально сворачивать (выносить в архивы и т.п.) всю детализацию из прошлых периодов, иначе могут начать сыпаться итоги по периодам
5) Строить четкий график для ВСЕХ длительных операций (более 30 секунд, в течение которых производятся изменения в базе), потому что 1С плохо разделяет транзакции
6) Стараться не использовать монопольный режим более 10 минут. Кроме всего прочего, 1С криво захватывает БД на сервере (любое обращение к БД способно выбросить монопольную 1С с ошибко - невозможно открыть БД в однопользовательским режимом , т.к. она уже занята)
7) Максимально оптимизировать по скорости все обработки и отчеты, не обращая внимания на размеры (правда на каждый мегайбайт БД SQL требует около 100-150 Кб физической оперативной памяти)
Пока все - если что, пиши.
   (небритый)
14 - 11.09.00 - 09:01
2БТР... Я так думаю, приведенная Вами выжимка из методологии была бы весьма ценна в более развёрнутом виде... и пригодилась бы не только автору данной темы... Скажем, если глянуть на развернутое рассмотрение Вами данного вопроса можно было бы на сайте ВайлдХера (прдн зп транскрипцию))), это обрадовало бы не меня одного!...
(в любом случае - мерси за интересные мысли)))
   Вадим
15 - 11.09.00 - 11:11
То БТР. Не согласен с п.6. Я не видел, чтобы при обращении к БД в монопольном режиме, проходили такие ошибки. Всегда корректно обрабатывала это и говорила, что база занята. Возможно, это зависит от версии. У нас DBF. Не болле 10 минут в монопольном режиме не выйдет. Только переиндексация занимает мременами от 15 до 30 минут. Зависит от размера базы и закрузки сети и от выполняемой задачи. Если бухгалтеру приспичит перенести ТА, то прийдется ждать, а сколько...



Список тем форума

Форум Территория 1С

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