Товарищи! Подскажите плз, на SQL 1С работает быстрее чем на .db ф-лах?

Смотря что...

(1)+ и смотря где

Вы имеете в виду, что в зависимости от конфигурации?
Если да, то что-то не очень понимаю...

Мы имеем в виду что у вас - терминал, сеть, а может быть виртуальный компьютер?

У меня нет конкретной ситуации, это любопытство, которое может пригодится в дальнейшем, если Вы знаеете про быстродействие во всех вышеперечисленных примерах, мне бы было интерестно знать :)

(3) А чо тут понимать... SQL придумали чтоб распальцованых лохов на бабки разводить...

Может у кого-то есть какае-то литература по этому поводу?...

(5) Хотя бы скажите какую задачу тестируете? Клиент-серверное приложение и что? *.db если не ошибаюсь - это же формат Paradox? Чем к базам подключаетесь - родными средствами или через ODBC?

:) Фраза прикольная!
Т.е. быстрее никак не будет?

Быстрее всего локальный дбф, он же терминал затем с ростом юзеров sql будет обходить сетвую версию.
А так - какие задачи. На запись - дбф шустрее будет, на чтение - sql

(8) родными средствами

(11) Через BDE что-ли?

(10) Хорошо, а если стоит комплексная база, которая работает через терминал, и ее необходимо ускорить, есть варианты, по мимо обгрейда сервера?

(12) Да

(14) Значит речь совсем не об 1С :)

(15) Б-р-р, че-то я потерял нить :)
Речь идет об 1С

Сколько пользователей сейчас? Планируете ли увеличивать?

Пользователей около 20, пока не планируем увеличивать

(0) dbf всегда быстрее. sql всегда надежнее.

Думаю, что в вашем случае на SQL работа будет более эффективной

(19) Спасибо!
(20) Почему?

(21) Потому что пользователей больше 10

Т.е. для надежности? Ссылаясь на (19)

Штурман, приборы?
Пять.
А что пять?
А что приборы?

:)
Ладно, спасибо!

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

(26) Это не для моих умов... :(
Я пока не знаю как это сделать

Ладно, спасибо за внимание, я побежал домой

(27) Ниче, раз купился на быстроту, прийдется платить за плохо пройденные повороты. А там и разберешся..

>> dbf всегда быстрее

dbf не всегда быстрее...
dbf зачастую не быстрее...

(30) +
dbf часто медленнее
dbf часто торомоз
dbf часто "экстренное торможение"

(31) dbf иногда торможение в столб)))

(1) А для терминала с 15 пользователями что лучше. Под восьмерку???

(30-32) Не вопрос.

имхо без оптимизации запросов (т.е. переход на прямые) под sql может оказаться как минимум не быстрее. 20 юзеров - это немного, база, как я понимаю, тоже не сильно большая: если все так, то оставлял бы dbf, но в терминале и на правильном железе (шустрая дисковая рулит). если база от двух гиг хотя бы - тогда можно уже посмотреть на скуль, но имхо переписать придется немало.

Так, крикунам, которые кричат, что SQL быстрее, а ДБФ тормоз.
Я допускаю, что при каких-то условиях SQL быстрее будет, но практика показывает обратно. База на дбф в терминале с 60 рылами работает на порядок быстрее, чем эта же база на SQL в которой работает не более 10 рыл. (Скорость проведения документов => транзакции. Проводили эксперемент, в воскресенье, когда нагрузка на базу минимальная, перевели базу на SQL).
Вот только не надо рассказывать, что с 1С++ и прямыми запросами на sql будет быстрее, чем на типовой версии на дбф.

Если размер базы позволяет, то лучше дбф.

(33) У 8-ки нет нормальной файловой версии, только жалкое подобие, которое ужасно тормозит (особенно с RLS) и глючит (тупо пропадает движение у документов после проведения), если в базе работает более 5 пользователей и база более 1-2 гигов. Так что на 15 человек однозначно SQL, другого варианта нет, ну кончено если это не УТ. Регистры накопления работают на порядок быстрее регистров бухгалтерии, поэтому в принципе при небольшой базе в УТ 15 человек может и в файловой версии поработать.

Все сказанное выше ИМХО, основанное на наблюдениях :)

(36) Условия эксперимента?

(37) Какие условия интересуют? Температуру и влажность воздуха не скажу, а остальное спрашивай, если интересно.

(38) Для начала - конфа, объем, железо, настройки (расположение баз, прочая нагрузка на сервер на котором сиквельник) сиквела...

(38) Каким образом имитировалась нагрузка?

конфа - когда-то очень давно была типовая комплексная из ВК используется только управление приоритетами. объем ~ 2.5 гиг, железо серверное примерно одинаковое. Расположение: Отдельный сервер где лежит дбф база, там никто не работает, других задач он не выполняет. пользователи заходят на терминал (отдельный сервак). и запускают апликейшин. То же самое и с SQL отдельный сервак, больше ничем другим не занимающийся кроме SQL. На sql только одна - наша рабочая база. Все соединено гигабитом.

Взяли дбф базу, сконвертировали в sql и запустили туда работать людей. Это было в воскресенье, народу бало порядка 10 людей. Итого скорость проведения документов на порядок меньше, чем когда в базе работают 80-100 рыл (пиковая нагрузка). Соответственно одна сплошная постоянная транзакцию.

(41) Раз "когда-то очень давно была типовая комплексная", значит пейсатели непейсакали пользуяв основном перебор.
2.5 г - не объем И непонятно, что ж там делают 80-100 рыл...

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

(41) Т.е. народ колбасил все, что ему вздумается, а не некий тестовый набор данных? А проверяли вы исключительно только скорость проведения?

Правильное юзание SQL сервера в многопльзовательском режиме всегда быстрее, в однопользовательском всегда быстрее файловый вариант - это факт..

(0) Если нужна конкретика - конкретнее и спрашивай..

(44) Нет народ колбасил в обычном рабочем режиме. Т.е. нагрузка была раз в 10 меньше максимальной. При этом документы проводились ой как долго. Т.е. когда ставили товар на приход, все курили в сторонке, я уже молчу про загрузку документов (обмен по моду с филиалами).

Это торговая база, для отчетов у нас есть другая база 8-ка на скуле. А главное требование к торговой базе - это скорострельность, зачем мне база, в которой я не могу загрузить обмен, потому что менеджеры колбасят заявки?

Эксперимент проводился на живой базе в рабочее время. Просто народ в один прекрасный день зашел не в дбф версию базы, а в sql, и работал в обычном режиме.

(47) Все-таки что-то непейсакали там не то... И комплексная 10Г с 25 рылами крутилась, и торговля 15 с 40-50 юзверями и регулярным обменом крутится...

(47) Надо было сначала курить прямые запросы, а потом долго писать и писать их

(47) У меня в последнее время слова "ставили товар на приход" вызывают судороги :)

(37) Да чего лохматить органы? Верю ему на слово :)
Подбор в большой форме списка, штатное проведение документов, etc.
Отчеты они, наверное, не попробовали... тут есть нюансы
Если прилепить правильные запросы к ДБФ - будет мегажесть

таки ж, апологеты DBF-а
расскажите мне, как ускорить базу, которая на скл-сейчас крутиться..
поможет перехода на DBF, если база занимает "всего то" около 20ГБайт??.
ась?..
вот то то ж..

(50) Будем "класть" на приход?

(52) Кури прямые запросы

мне и без "прямых запросов" комфортно..

(53) Да я о своем...
(52) Ну дык... объем обязывает все же...

(55) Ты же сам спросил как ускорить базу на SQL, щас говоришь об обратном - не поймещь тебя..

Еще раз. Мы говорим про типовые средства, без прямых запросов и т.п. мы говорим, что если взять типовую базу (или что то подобное) и положить ее на скуль то в 99% она будет работать медленее, чем эта же база на ДБФ. Прямый запросы работают прекрасно и на скуле и на дбф (на дбф нельзя только писать в базу, а читать пожайлуста). НО с другой стороны когда размер базы не позволяет использовать дбф, тут уже придеться переходить на скуль и оптимизировать ее под скуль.

Поэтому когда мы говорим что на скуле будет работать быстрее, все почему то умалчивают, что при условии что базу придеться всю переписать.

(58) Совершенно верно в рамках 7-ки

(56) эт точно - обязывает..
(57) таки ж, я постебаться решил..
(58) ну ка ну-ка, и как быть в случае с (52) на dbf будет быстрее??

(60)
Цит. "НО с другой стороны когда размер базы не позволяет использовать дбф, тут уже придеться переходить на скуль и оптимизировать ее под скуль."

(60) Чукча не читатель, чукча писатель?
"НО с другой стороны когда размер базы не позволяет использовать дбф, тут уже придеться переходить на скуль и оптимизировать ее под скуль."

Размер базы 20Гиг позволяет использовать дбф?

(58) Еще раз: База (дописанная, но не переписанная, без прямых запросов) комплексная, 10Г, 25 рыл, крутилась на сиквельнике...
Ищите затыки в своих дописках-переписках

(47) "Нет народ колбасил в обычном рабочем режиме" - ты вероятно не совсем понял разницу между экспериментом и экскрементом. Результаты твоего "эксперимента" нужно не на форум выкладывать, а в унитаз сливать.

Сколько документов в день, сколько строк в документе максимальное и среднее значение.

Она работает замечательно при условии что строк в документе не более 5-10. Когда строк в документу больше 100 начинаются тормоза при записи, и чем больше строк, тем по экспоненте уменьшаться время проведения документа, по сравнению с дбф.

Поэтому многое зависит от документооборота.

(61)(62) вот вот.. если есть "но с другой стороны.." на больших базах, неча и с DBF сравнивать....

(64) А я и не выкладываю, я просто делюсь наблюдениями, это во первых, а во вторых, вы хотите сказать, что при 10 человек база работает медленнее чем при 50, но если все 50 человек зайдут и начнут работать в базе, то от этого база будет быстрее работать? Смысл проводит эксперимент при полной нагрузке если результаты при минимальной нагрузки нас не удовлетворил?

(65) ну-ка, нука... дафайтЭ результаты.. бум глядеть в натуральном виде, и затем сами сделаем выводы..
PS таки ж, вот ж Ларри возрадуется, когда поймет, что MS SQL в сравнении с 1C+DBF фигня на постном масле... ведь тогда он не должен будет отдавать Биллу те миллион долларов, что он в свое время проиграл...

(67) очень даже большой смысл...
SQL не почувствует разницы между 5 и 50, в то время как DBF "прогнеться".. вот и весь смысл...

(65) Здорово похоже на кривые дописки. Я бы отладчиком сделал замер производительности, где именно затык.

(68) Давай определимся. сам MSSQL достаточно шустро работает на больших базах, впрочем он для этого и предназначен. Но 1С с ним работает через ж..пу и как результат - мы имеем то, что имеем.

Я видел базу более 60 Гиг на скуле, которая просто летала так, что дбф это и не снилось. НО от 1С там осталась только оболочка, т.е. только формы. Запись и чтение данных было написано с помощью прямых запросов. Поэтому к скулю я не имею претензий по скорости, а все претензии относятся к тому, как 1С работает со скулем.

(71) Кстати озвучь параметры машины на которой скуль поднимался. Насколько я понимаю там файлопомойка, терминал на соседней, когда подняли скуль нагрузка по выполнению запросов перешла на файлопомойку, ибо поднимали на ней, а тянет ли тачка?

может быть мне не приходилось видеть так называемые "шустрые базы", но (тьфу,тьфу), на 10- 20 Гигах 30 пользователей последние 3 года - и все благополучно..

(70) Откуда такая уверенность, что код от 1С это идеальный код. Его можно только "искривить дописками". Возьми типовую комплексную. Сгенерируй базу хотя бы на пару гиг и проведи документ в котором одна строка и хотя бы 2-3 тысяч строк. И сравни скорость.

(69) Может быть и не почувствует, но быстрее работать точно не будет. А скорость работы посчитали неприемлемой, поэтому смысла тестировать на полной нагрузки небыло.
(72) Это отдельная машина на которой собрана специально под скуль, для файлопомойки есть отдельный сервак, поэтому нагрузка некуда не переходила

(74) Да может и не кривые. Просто запросы выполняются как? Если это дбф, он будет выполнен на тачке с терминалом, если скуль - на тачке со скулем. Соответственно если скуль поднимался на слабой машине, то будут тормоза в запросах. В момент проведения как правило запросом выдергивают какие-либо остатки. Соответственно здесь-то и тормозит.

(75) Учитывая что скуль ставился в качестве эксперимента на один день, меня гложат смутные сумления, что под скуль была собрана тачка уровня рабочей станции.

(74) у меня, кстати, местами очень даже криво переписанная комплексная.. не жалуюсь... работал и с дбф версиями - в базе всегда работал 1 человек и на 500-600 мегабайтах база загибалась.

+(77) А нагрузка-то как раз переходила, просто очевидного не понял.

(72) под скуль была машина 2 одноголовых Intel Xeon 2.8 Ghz, под дбф 4 одноголовых Intel Xeon 2.5 Ghz. Памяти везде по 4 гига. Повторяю еще раз машины ничем другим не занимались

(80) Вроде нормалоьная, хз... Разве что может винты тормозные были, или касперец какой бесчинствовал. Короче в рамках эксперимента нужно было не только факт наличие тормозов проверять, но и найти где узкое место. Если скуль на хорошей тачке, то при работе 10 пользователей в маленькой базе разница если и будет не в пользу дбф, то все ж не настолько чтобы во время проведения курить в сторонке. Скорее наоборот, визуально не сильно заметна...

нормалоьная = нормальная

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

(83) Смахивает на многократный запрос. Вместо того чтобы сделать один запрос по всей ТЧ, зафигачили по каждой строчке.

(84) Ну т.е. по каждой строке по запросу... А это уже кривые ручки, а не скуль...

(85) Это типовая, а не кривые ручки.

(86) и как это сочетается с "конфа - когда-то очень давно была типовая комплексная из ВК используется только управление приоритетами."?

На днях была тема про 8-ку БП, когда  в типовой строились индексы по каждой строчке документа, и если строк очень много, то 1С вылетает с криками недостаточно памяти.
Просто на тот момент небыло времени заниматься поиском этих всех граблей. пошли по пути наименьшего сопротивления, обрезка баз и удаление ненужной информации, чтобы из дбф не вылететь. А для отчетов отдельная самописка, куда все данные сливаются.

+(87) В типовых многократных нет...

(88) Ну за восьмерку не скажу, в семере нет такого

8.x рулит. 7.7- старое убожество. Нафик его еще оптмизировать?

(88) фигня какаято. SQL какой был? Дай ссылку на тему.

(87) Ну не на 100% ушли от типовой. Просто много дополнительных контролев и галочек, для автоматизации процесса. к проведению это не относиться. В проведении меняли структуру регистров (удаляли неиспользуемые измерения и регистры) и уменьшали количество вложенности, к примеру формирование проводок не из ГМ, а в модуле проведения.

(92) Обычный 2005 но вылетал не скуль, а сервер предприятий. Сейчас попробую поискать

(93) Это называется к проведению не относится? :)

+(95) Кстати интересная оптимизация, переносить формирование проводок из глобальника в модуль документа. При таком подходе не сомневаюсь что косяков хватает. Зря франчам-то не дали :)

(94) из последних помню что вылетало когда текстом тут ктото пытался искать. Но это нормально, что вылетает на таком.

(96) А как по твоему что будет быстрее передавать параметры в глобальную универсальную процедуру, в которой куча условий и проверок, или в модуле проведения жестко забить счета и значения?

(92) Сылку не нашел, но там речь была о том что в БП ОбщиеМодули->Налоговый учет процедура РасчетВременныхРазницПриРазныхСпособахСписанияАктива
Там есть такие строки

ТаблицаДокумента.Свернуть("Номенклатура, СчетУчетаБУ, СчетУчетаНУ");
Для Каждого СтрокаТД Из ТаблицаДокумента Цикл
  ТаблицаПроводокБУ.Индексы.Добавить("СчетКт,СубконтоКт1");
  ВыборкаБУ = ТаблицаПроводокБУ.НайтиСтроки(Новый Структура("СчетКт,СубконтоКт1", СтрокаТД.СчетУчетаБУ, СтрокаТД.Номенклатура));
  Если ВыборкаБУ.Количество() = 0 Тогда
     ТаблицаПроводокБУ.Индексы.Добавить("СчетКт,СубконтоКт2");
...
Вобщем и дальше в таком же духе. И когда в документе очеееень много строк, мы получим очеееень много индексов, и как результат -> теряем в скорости проведения и/или вообще 1С ка вылетает с криками про нехватку памяти

(98) Примерно одинаково, так как на все эти присвоения-передачи уйдет процента два времени от всего, затраченного на проведение.

(100) Сотыга!

+(99) Зато нетрудно догадаться что стало с кодом который годами вылизывали после такой оптимизации...

очень бы хотелось посмотреть на модуль проведения дока целиком...

(36) вот уж действительно не надо рассказывать. примеры с базами, заточенными заранее под 1с++ и скуль (полностью самописыные) я приводить не стану: они слишком субъективны. приведу пример другой: типовая торговля для Украины, сильно переписанная: переписаны взаиморасчеты (ну это мелочь в сравнении с остальным), переписан полностью учет товаров, переделаны регистры (в плане типов, но не числа измерений), соотв. все отчеты тоже переписаны. измерения проводились не в монопольном режиме на одном и том же железе, попеременно формировались отчеты в обеих базах. так вот пример на некоем отчете (детали неважны):
1. фильтр по одному признаку (ну это я так называю, чтоб в подробности не вдаваться)
2. фильтр по двум признакам
3. без фильтров (самый "жирный" вариант)
это описание режимов. в регистрах флажки типа быстрой обработки движений и т.п. - не ставились. базы идентичны (просто одна сконвертирована в скуль). отчет выбирался за один и тот же период.
до доработки скуль тормозил в два и иногда более раз в сравнении с dbf, привожу результаты после полного переписывания на чистом T-SQL под 1С++, также использовлась выгрузка результатов в ТЗ методом 1с++
результаты:
Режим | DBF | SQL
1     | ~91c| ~35c
2     | ~83c| ~25c
3     |~153c| ~95c

это фрагмент тестов, конечно, но комментарии излишни, я думаю.
на сложным подборах (самописыне формы подбора с большим кол-вом разнообразных фильтров по пяти справочникам - мне долго описывать структуру) - выигрыш в десятки(!) раз зачастую. общая производительность повысилась просто невероятно.
если же еще поколдовать с флажочками в регистрах, я уже не говорю о блокировках, более тонком тюнинге и т.п. - то dbf просто нервно курит в сторонке. также при большом числе одновременных запросов - скуль себя еще лучше проявит, а файловый вариант тупо ляжет.

так что, как говорится, не надо ля-ля.

+103 измерения с учетом вывода на экран приведены, т.к. отчет большой - выводится он долго. запрос же в чистом виде максимально по времени у меня выполнялся 12-13с на скуле при полутора и более минутах на dbf.

(104) при использовании прямых запросов dbf нервно курит.. подтверждаю...

(105) несколько непонятно, если честно, сильное замедление при переходе на скуль без переписывания под прямые запросы: иногда результаты неприятно поражали. наверное все-таки работа со скулем в эске написана не просто плохо, а через одно место :(

ИМХО скуль заточен на чтение - т.е. данные из него получаются быстрее, и чем сложнее запрос, тем больше скуль будет выигрывать на чтение по сравнению с дбф. Но на запись у 1С получаться работать быстрее с дбф, чем со скулем. Поэтому для базы которая используется для отчетов, лучше будет скуль, а еще лучше 8-ка, вместо 7-ки. Но торговая база, т.е. фронт когда большая часть информации все же записывается, чем читается, то либо писать напрямую в скуль, минуя 1С, или дбф

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

в остальном же я давно понял, что на желез экономить тоже не надо, особенно на дисковой: 4SAS в raid10 на приличном контроллере с "батарейкой" - творят чудеса :)

у 1С есть узкие места в работе со скулем (например: http://www.softpoint.ru/article_id164.htm http://softpoint.ru/article_id138.htm  http://softpoint.ru/article_id163.htm и прочие) но скоростные показатели на типовых конфах не будут различаться на порядки в пользу dbf, как тут некоторые товарищи утверждают. Или некорректный эксперимент или кривые конфы

(107) Да нет, все проще - основной тормоз не в записи, а именно в чтении при получении итогов в модулях проведения. Особенно при фильтрах по спискам - а без них не обходится ни один документ. Чем больше список (читай больше строк в проводимом доке) - тем медленнее работа. Почему так  понятно - создается временная таблица, в нее ПОСТРОЧНО передаются элементы списка, а затем выполняется запрос. Причем тут еще и вторая проблема накатывается - неоптимальное использование индексов. К сожалению типовые конфигурации написаны своеобразно в плане порядка следования измерений регистров.

Запись, конечно, дает свою долю за счет того, что опять же записи в таблицу проводятся построчно, а не "пачкой". Но если не баловаться RAID5 и разместить журнал транзакций на отдельном диске, то это мизер.

Ну и еще один значимый фактор - известная ошибка работы с буфером сессии самого MS SQL. Но это больше для массового перепроведения применимо (увы, но полно "эксперементаторов", которые "сравнивают" именно по этому показателю).

(109) конфа была кривоватой: по разным причинам пришлось переделать товарные регистры следующим образом: раньше в виде товара в измерении был элемент номенклатуры, после переделки - элемент справочника, который состоял к номенклатуре в следующем отношении: Товар=Спр.Владелец.Владелец; плюс была забита жесткая иерархия групп, т.е. родители тоже имели вполне конкретную сммысловую нагрузку. короче вот из-за этих обращений через точку - скуль бодался с товарными отчетами гораздо дольше. я понимаю, что мой косяк (хотя спорно: три лишних измерения скорости на добавят), да и сделано было по частям (заказчик рожал задание пару лет в - итоге несколько сумбурная доработка, плюс малый бюджет - красивое решения "с нуля" туда не вписывалось, увы).
так что согласен конечно, но факт - есть факт: 1с++ спасла ситуацию :)

(110)+1
если лог и базу на раздельные массивы, причем лог на raid 10, а базу tempdb - на еще один массив (LUN) - тады можно тушить свет :)
P.S. как же рулит метод УложитьСписокОбъектов() при наложении фильтров! мысленно кланяюсь разработчикам каждый раз :)

А если базу на рам-диск положить вообще красота будет

(113) Шашлык из тебя будет...

(113) ну это ты уже увлекся :)

(105, 106) Далеко не всегда :)
Запросы некривые возможны и на ДБФ
(110) Построчно списки - полбеды, еще ведь и запись ТЧ документа построчно и т.п. :)

(114) не гони! нормально будет... конечно все время я бы не стал в рам-диске работать, а вот какие-нибудь тяжелые регламентные работы - это да...

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

(118) А нефиг было на УПСах экономить. Ну выключат ток, УПС скажет об этом компьютеру, компьютер корректно положит сервак. Как только включат ток, так компьютер сам и загрузиться, и где тут шашлык?

(119) Ну например не скажет компьютеру, бо ток уже несколько лет не вырубали, равно как и сервак, и никто не в курсе что упс уже год как дохлый. Да и про ток, это ж не единственная причина, любой синий экран даст тот же эффект.

(107)сервер БД, "заточеный под чтение" - это что-то новое... Напиши об этом Биллу, он наверное по глупости своей считает иначе. Ну да ладно....
Я собственно о том, что как и говорил MMF, 1C далеко не образец для подражания в части работы с сиквел-сервером. И многие недостатки в этой связке имеют корни в работе с дбф (ну не стали 1С-овцы, в обоих смыслах этого выражения) переписывать 7.7 специально под сиквел - проще им было сопровождать "сдублированную" версию..
Но даже на этой необразцовой работе типовые тянут примерно одинаково. Если разница в разы - значит, пейсатели постарались....
(119)Кроме пропадания напряжения бывают выдергивания шнуров, падения сервантов в синий экран, отсоединение сети и многое другое. В случае файловой (дисковой) работы больше вероятность поиметь данные. Хотя сама файловая структура менее надежна (чего, например, стоит требование переиндексации при авостах) нежели сиквельное.
На мой взгляд, у сиквельной версии всего два недостатка: 1)деньги на сиквельный сервер 2)Дятлы, не умеющие с ним работать