Когда желательно переходить на SQL? #237221

Когда желательно переходить на SQL версию 1С. В чем преимущества работы базы на SQL серевере...?

Желательно - сразу. Обязательно - когда размер какой-нить таблицы достигает 800мб+.Преимущества основных два:1) полная НЕЗАВИСИМОСТЬ СКОРОСТИ работты ОТ ОБЪЕМА ДАННЫХ;2) отсутствие необходимости переиндексировать таблицы при аварийном завершении работы.

Не соглашусь! База меньше 1 гига - смысла нет (имею в виду суммарная ДБФ). А больше - однозначно! Хотя, если юзеров 3-5 то вполне нормально летит!

1) Когда в фирме будет достаточное количество квалифицированных специалистов по 1С+SQL. Ни в коем случае не ранее!!! (Будет много горя).2) Преимуществ нет. Одни недостатки. Шутка.Основных парочка:а) Возможность работать с базами такого размера, с которыми ДБФ просто физически работать не может;б) Возможность реализации прямых запросов к базе, минуя 1С (т.е. без участия 1С).

К п.2 к сожалению это не шутка, если не переписывать базу на прямые запросы, то ДБФ порвет SQL по скорости, причем, чем больше строк в документе, тем при проведении преимущества DBF выше.P.S. А разве прямых запросов у ДБФ версии нет?

2: Ты читать чтоли научись (или просто повнимательнее читай): в нету ни слова про размер БАЗЫ, умник....2:по п.1.: Ну не скажи. Мульён просто клиентов, у которых "поставлено фиг знает когда и пашет". Единственно что выгрузки не у всех - но это подправляется сразу по приходе.по п.а: это следует из п.1 (просто не сказано о само собой разумеющейся особенности работы с файловыми версиями - а именно что начиная с определенного размера файла данных скорость замедляется пропорционально ЭКСПОНЕНТЕ увеличения размера файла).по п.б: нафиг-нафиг (ходить в ДБФ-ки фокспрохой тоже можно)...2: 1) не "порвет" по скорости - хоть до определенных объемов данных и будет работать быстрее; 2) а начиная с определенных объемов ДБФ-ка сама порвется нафиг.

Скорость на запись у ДБФ выше, чем у SQL, поэтому если мы не говорим о базе, в которой работает 2 человека и которые проводят в день 10 документов по 2 строки, то в ДБФ версии документы будут проводиться быстрее, чем на SQL. Причем разрыв в скорости будет пропорционально экспоненте от количества строк в документе. При условии, что ДБФ не наткнется на ограничения в файлах.С другой стороны имея базу на SQL, можно от 1С оставить один интерфейс и тогда во первых можно избавиться от транзакций, во вторых скорость работы будет на порядок выше, чем в обычном режиме

>Ты читать чтоли научись (или просто повнимательнее читай), умник.Я тебя тоже люблю...;)))

Но уж что не дурак - точно. По крайней мере другие так говорят. Извини, дорогой ... СуперУмник.

Все понял... Одновременно работающих пользователей 5-6 чел... база распределена... Суммарно в центре получеается 300-400 док в день после загрузки... База 900 мег... Наверно все-таки пока не стоит переходить, так все как работает в терминале и довольно шустро... а SQl я еще н разу не ставил...Всем СПАСИБО!

2 Демон, это еще не все1. Избавление от переиндексаций2. Типо большая секретность3. Лучшая надежность4. Администрирование + супер-мега быстрые бэкапы без выгонялоки т.п.ЗЫ. А переходить имхо лучше зимой, т.к. меньше хочется на улицу

жжешь

Скажите, а дбф базу можно каждые 10 минут бэкапить, не выгоняя юзеров?А откатить потом на любой момент назад?

Я всегда делаю бекап не выгоняя юзверей.Знаю, что возможнна потеря инфы и придётся потом переидексировать.Бекаплю не только данные, а всю папку с базой.(Внешним архиватором).Переиндексация 1Гб базы происходит за 1,5 минуты.

А что я там потеряю.Базопузомер показывает у меня ~ 200 доков в день.Я делаю бекап 2 раза в день.Ну потеряю я документы за последних 5-10 минут(те что находятся на раме мользователей).В случае краха нужно будетвручную восстанавливать за полдня.

Я тоже в раздельном режиме базу копирую и в чем проблему ты тут увидел? Что-то за много лет я не узрел в этом разницы.Про SQL так думаю, Если база за год растет до пределов DBf или по своей специфике ее не обрежешь, то без SQL не обойтись. В других случаях, не особо принципиально т.е. на свой вкус и цвет.

Сколько раз приходилось восстанавливать базу, наверое не скажу. Скажу что много, и не одну ночь провел за этим делом, но такого чтобы не запустилась, токого не было ни разу.Аргументы мои таковы: Документов колбасят за день много, поэтому архивируется база несколько раз в день. Я примено исхожу из того чтобы копию можно было восстановить часа за два. В восстановлении самое хреновое это найти документы по которым можно восстановить базу и добить их, поэтому отсутстве в базе ну десятка документом которые не попали в базу, потому что были не закрыты на момент архивации, это мелочь.А то что база не запускается после архивации, трудно сказать, мож архиватор такой, который в раздельном режиме не работает.

+1Запускал скопированные в разделённмо времени СОТНИ раз и ни РАЗУ проблем не возникло.

+21Сорр+1Запускал скопированные в разделённмо времени СОТНИ раз и ни РАЗУ проблем не возникло

То есть не было ситуаций, когда архивируется дбфка с шапками документа (DHXXX.dbf) и документ еще не записан (шапка не попала в архив), а к моменту архивации дбфки со строками документа (DTXXX.dbf) документ уже записали (строки попали в архив) у тебя не было? В лотереии с таким везением не пробовал играть?

Меня это никогда не интересовало.Я утверждаю лишь то, что никаких граблейс запуском заархивированной внешним архиватором базы работающей в разделенном режиме не было.

То есть ТиИ после восстановления не выявляло никаких косяков?

+25Вообще-то у меня не было никаких проблем с ЗАПУСКОМ базы даже при снесении всех дбфок.

Сейчас запущу ТИИ.

Э, так не пойдет....Для чистоты эксперимента - сначала сделать ТиИ, убедится в отсутствии косяков.Запустить пяток юзеров в базу, чтобы колбасили документы/справочники.Запустить архивирование.Убедится, что во время архивации пара/тройка доков была создана/удалена/проведена/снята с проведения.Разархивировать.Сделать ТиИ.Вот как-то так....Так что до завтра, наверное.

+28Да, чуть не забыл.После архивации новые доки не набивать.Снять остатки по регистрам и проводкам.Сверить с разархивированной базой.

Долго врм. нет.Как нибудь попробую.

честно говоря сам ни разу не пробовал...но ИМХО для ДБФ-ки пройдетНачатьТранзакцию--скопировать всю базу.--ОтменитьТранзакцию--А вообще SQL рулит.. :)