DBF и SQL преимущества #483490

Подскажите пожалуйста, что почитать на тему "Преимущества sql перед dbf". Когда стоит осуществлять переход, когда нет ? По запросу: преимущества dbf sql site:forum.mista.ru ничего внятного не нашел Спасибо

sql надёжней и объёмы бОльшие держит. А в правильных руках ещё и быстрей.

Ёмко. Спс

SQL - это надежность и работает там где DBF просто задыхается.

Основное преимущество SQL в том, что за сохранность базы данных отвечает не сама 1С, а SQL-сервер. Соответственно, заботится о бесперебойном питании можно только для машины, на которой установлен SQL-сервер. Если что-то откажет, то SQL-сервер просто "откатит" транзакцию. Второе преимущество - SQL поддерживает большие объёмы, а для DBF-файла размер более 1 гига оказывается смертельный. Остальные преимущества появляются, когда в SQL лезут напрямую, но это уже к 1С не очень-то и относится.

ну, размер файла для дбф давно уже 4 гига, если что.. Преимущества дбф - быстрее запись.

Переход надо осуществлять сразу, как только появляются деньги на сервер.

брехня.

в лучшем случая, скуль обеспечивает лучшую надежность и всё..

+ А терминальный уже есть?

Я написал, что главное преимущество - сохранность данных. DBF без терминала использовать боязно. А быстрее не запись, а даже чтение - просмотр формы списка справочника на DBF будет быстрее, чем на SQL.

А то ещё и надо денег сразу на терминальный сервер.

SQL можно попробовать и без терминала "гонять". Опять же вопрос - что планируется делать, и сколько будет пользователей, а то, может быть, там и сервер, как таковой, не нужен.

Ты говоришь только про работу штатными средствами или вообще?

Автор в поиск, обсуждалось тыщу раз.

, - я не разбраю отдельный случай. Просто хотел спросить у спецов, когда переходить, а когда не перехолдить по поиску не нашел я (упомянул выше)

Внештатными средствами из 1С вообще можно в ACCESS лазить или куда-то ещё за данными. P.S. а про цену SQL-версии почему-то никто не вспоминает.

@можно в ACCESS лазить или куда-то ещё за данными@ - b xnj& Yt cjdctv gjyzk/

+ Блин... "можно в ACCESS лазить или куда-то ещё за данными" - и что? Не совсем понял.

А цена похоже вообще не интересует.

Разговор о том, что база данных может быть DBF, а сами данные жить вообще где-то в другом месте, то есть для пользователя остаётся только привычное окно 1С (ну уж очень они к ней привыкли).

Ну некоторые ещё до сих пор под знамёнами "Великого Роджера".

:)и бочонок рома

"Бочонок рома" обычно отделу К выкатывают, чтобы не было обидно.

4) Вопрос Общий заголовок: "Когда лучше использовать SQL версию 1С или что лучше dbf или SQL" а) Собираемся внедрять 1С Торговлю и склад. Количество ползователей 15. Примерно 200 документов в день на всех. В каждом документе примерно по 20 позиций. Какая версия предпочтительней в данном случае с точки зрения устойчивости, скорости и стоимости владения? Не хотелось бы потом коней на переправе менять. Насколько фатально зависание одной машины в DBF базе? Насколько будет меняться скорость работы в зависимости от количества пользователей? б) У клиента 50 рабочих мест. Количество выписываемых документов в день — 400. Само-собой много всякого рода справочников, отчетов, журналов. Кроме того, есть куча всяких журналов, отчетов и справочной информации. Потянет ли все это платформа 1С SQL? Хотелось бы увидеть примеры из жизни. Есть ли у кого такого рода клиенты? Какая у них техника стоит? в) Ув. коллеги. Проблема предельно проста — бухи жалуются на низкую скорость работы = 1С 7.70.014 (сетевая версия), три пользователя, незагруженный НТ сервер и нормальное железо. SQL версию 1С я в глаза не видел. Увеличится ли реально скорость работы при переходе на SQL версию, я так понимаю, что на рабочие станции передается только "копия экрана". Для сравнения, есть такой софт — RS-BANK, так он дал выигрыш в 10-15 раз. Заранее благодарен (играться просто некогда, я один, без ансамбля). Ответ а) SQL предпочтительна. На таком количестве пользователей может быть выигрыш в скорости и не проявится. Но самое главное это устойчивость. У нас при таком количестве пользователей и DBF-базе несколько раз в неделю приходилось посреди дня изгонять людей из базы и переиндексировать, а после этого еще долго звон в ушах стоит. Сейчас SQL юзеров порядка 50 и система спокойно переживает скачки напряжения с отваливанием всех клиентов. Был случай, когда случайно выключили сервер и всё ОК. В DBF отваливание одного - другого, третьего клиента вызывало необходимость переиндексации. Считается что dbf способна жить с базой до 1Гб, выше,— производительность падает. Учти, что файл-сервер предъявляет требования к сети и к рабочим станциям, в то время как сиквел — только (в основном) к серваку. У каждой платформы - свое предназначение. Например, с типовой конфигурацией ТиС 8.Х на DBF больше 5 юзверей просто погибают от тормозов, при условии, что непрерывно лупят документы. Правда, если 200 доков равномерно распределены по времени, то выживут и 10-15. Но если железо и квалификация позволяют, то ИМХО, предпочтительнее SQL. Альтернатива SQL — терминальный доступ... можете хоть с 386-й работать и отваливание пользователя безболезненно и для юзера и для окружающих... 15 пользователей - однозначно SQL. Стабильнее, надежнее. "Навороты" — это же только плюс. Хочешь — применяй, хочешь — нет. Нравится TSE — ставь его в связке с SQL. Хочешь работай так-хочешь по другому. Сырость - есть такое. Но сырость не критичная. Если контора оформляет 200 доков — деньги на SQL уже найдутся. Третий год работы с 1С под SQL. Полет нормальный. До этого семилетний опыт работы с MS SQL и десятилетний опыт работы с самыми разными базами данных. Заявляю: при прочих равных политических и технических услових эксплуатации 1С не вижу сколь либо серьезных преимуществ работы с DBF взамен SQL. Обратных преимуществ вижу много-много десятков. Лично я перехожу на SQL версию начиная с четвертого-пятого компьютера в сети. Ни разу об этом не пожалел. Реальный пример — загрузка базы данных из "выгрузки" (27 метров ZIP~a) в дбф (комп P3-700/256mb винт ATA100) — ~ около 40 часов. Загрузка в SQL того-же самого (комп P2-350/192mb винт скази — старый (второй что-ли)) ~5 часов. Тест 2 удаление из базы ~20000 документов - 1-й ~18 — часов, 2-й около 6-ти PS: обьём базы в SQL — 2.2 гига. ИМНО нужно пробовать (если есть возможность) в конкретной ситуации. Знавал базу под ДБФ более 1 Гб с более 10 юзверями, переиндексировали раз в день, утром. Перевели под SQL выигрыша по времени не получили (ничего хорошего не получили ;) надежность!? и так было нормально. Так и оставили! А еще одну базу знаю. Живет под SQL (приближается к 1Гб), работают 5-6 человеков. При выгрузке в ДБФ (для конфигурирования, тренировки и т.п.) замечено, что отчеты формируются в разы быстрее. Но в большинстве случаев SQL помогает. Мое соотношение где-то 15% к 85% (из опыта ИМНО). Вот только с ЗиК никак не определюсь, советовать клиентам или нет? Зик +SQL? б) Лучше все делать не в одной информационной базе, а в нескольких связанных.          Верхний уровень — Бухгалтерия. Остается настроить передачу данных. Еще можно поэкспериментировать с репликацией (для получения отчетов из зеркальной базы). Я лично делал систему, где работали 10 операторов, и все работало. Сейчас делаю более крутую, где будет порядка 40 пользователей, из них 15-20 активных. Пока скорость удовлетворительная. Но: все отчеты и все запросы к регистрам по проведению я делаю только прямыми запросами на Rainbow. На 25 пользователей не надо ни двух баз, ни OLAP (если не нужна статистика, анализ и пр.), ни репликация. Все живет совершенно нормально на PIII-600, 512ОЗУ, RAID-5, 100мб сеть. Правда без бухгалтерии и с приличными ресурсами клиентских машин. Любые разделенные базы - повод для гемороя. Сихронизировать их в реальном режиме практически невозможно. Доводы о том, что оперативность не нужна не состоятельны для управленческого учета. Я рекомендую установить MSSQL7.0 на базе Windows NT 4.0. Интеловские платформы а-ля STL2 с двумя процессорами 750-800 P3 256-512 мозгов. Стековый хаб-свитч с несколькими портами с поддержкой транка на 1Гб к серверу. На сервер несколько гигабитных карт — 2 будет достаточно. Хаб тоже интеловый можно взять. Подробности по проекту на почту. TSE тоже может пойти — но не оптимально — всетаки 50 мест. Скорее даже не пойдет. Многое завистит и от самой конфигурации, точнее от ее оптимизированности (например понятно, что в данной ситуации типовая комплексная работать просто не будет). С первой частью согласен (MS SQL 7), а вторая просто вызывает недоумение: ИМХО если контора серьезно собралась автоматизировать 50 мест, то одним сервером здесь не обойтись — 1 под SQL и 1-2 под ферму Сitrix TSE ... в) Ты перепутал божий дар с яичницей. "Копия экрана" — это TSE. SQL — это из другой оперы, при которой никакой пользы не получишь. На трех пользователях, естественно. Народ! Вы хотите сказать, что 3 (!) места могут так нагрузить? Не верю! Какая база? Объем? Сколько документов вбивают в день? Посчитать легко - нумерация имеется... Блин. Сейчас обработку напишу чтоб статистику давала... SQL дает прирост по скорости это однозначно (если правильно настроен)!!! Я сравнивал 1С Однопольз ДБФ против 1С+SQL на базе около 700 мегов. У ДБФ быстрее идет запись на диск, у SQL быстрее рассчитываются итоги (в нескольок раз). Кроме этого переиндексация и пересчет итогов в ДБФ это просто головная боль. На трех юзверях, при условии отсутствия роста количества оных, поставь TSE 4.0. Преймущества: — загрузишь ресурсы сервера; — скорость будет конкретная (при условии достаточности ресурсов железа); — бухи больше доставать не будут; — будет время на поиграться (я не про игры); Однозначно. СКЛ для этого — как из пушки по ма-а-а-леньким таким комарикам.

хм.. Опыт небольшой, но поделюсь соображениями: 1. На SQL платформе базы значительно быстрее загружаются (пара сек) 2. Немного разный механизм для выборок, в sql в основном пишу через черные запросы, на dbf просто выборка с циклом. Производительность не сравнивал, но, имхо, sql в отчетах шустрее будет (говорю как человек разрабатывающий конфу без регистров и проведенных документов, т.е. всё построено на запросах к документам, а так же запросам к внешним БД). 3. На мой взгляд сложнее управляться с самой базой.. Если dbf - это кучка файликов на диске, то sql это уже файлы SQL Server. Значит, к примеру, копию базы ты просто так за две минуты не сделаешь. 4. На sql платформе забываешь, что такое индексы вообще Вот пожалуй и всё. Про железки и прочие тонкости в хорошо написано, зачитаешься)

+ P.S.: 5. Ежедневные бэкапы средствами SQL Server - тоже большой плюс.

Спасибо всем, особенно за

устаревшая статья шо ппц..