Уже стало привычкой перед окончательной публикацией показывать свои литературные опусы читателям мисты и инфорстарта. Коллеги, прочтите и покритикуйте? Что пропустил замыленным глазом, а в чем допустил ошибку.
--
http://legion-service.org/sposobi_optimisasii_1c77dbf.html
--
Спасибо заранее.

"аж в 1999 году. " -  замени на "в далёком"

Инструкция по изучению аромата гомна мамонта? Круто!

"Если вы еще не используете – то используйте" - тафтология

А почему все способы сводятся к администрированию?

ИМХО, если "Работа пользователей в вашей базе сопровождается тормозами, зависаниями, транзакциями при попытке блокировки самых разных таблиц " то дефрагментация и выделение каждому пользователю свой каталог врядли помогут

(4) почему все? не все.

(5) а ты проверь прямо сейчас на самой большой базе клиента....

(6) А какой из советов не относится к администрированию? Ну может только про индексы регистра и константы

(7) А если вынести профели (темпы) на рам диск - то все летать будет. Но где же найти такой сервак у которого куча свободной памяти

Алексей у тебя ИМХО а я перепробовал все мыслимые и немыслимые способы в попытках оживить базу в 11 гигабайт.... результаты в статье

(9) Алексей. Ты невнимательно читал статью. Там черным по белым написано - RamDrive не советую....Извини но не опровергать собеседника даже не прочитав его труд - неуважительно

У меня работает база dbf 11 гигабайт в результате с приемлемой скоростью и почти без транзакций. Не доказательство?

(10) да нахера это все? не проще ли заюзать SQL + 1С++ и не мучаться?

(13) к (12)

+ к этому же - давай-ка начнем с документооборота / количества юзеров и тп?

(0)
хм... 3 года назад работал в Астрахани - на работе УПП крутилось(то есть вроде как не медвежий  угол), а у тебя такие извраты с 7кой... = не того на выборах выбрали?)) экономика региона рухнула?

конечно проще)))) sql это тема следующего разговора. сейчас я хотел разобрать по полочкам dbf

(15) давай. 70 юзеров, 2500 документов в день

(17) вообще смысл всей этой галиматьи с 11-гиговым ДБФом? ты протрахался, потратил N человеко-дней... проходит 3 месяца, база становится 15 гиг и все возвращается на круги своя - опять N человеко-дней и тп...

тут реально вопрос глобальнее - либо 7.7 SQL с почти полным перелопачиванием модулей либо 8.х

(16) да при чем здесь экономика? у меня стояла задача разобрать по полочкам оптимизацию 7.7 dbf. Как набрался материал из нескольких опытов -  обобщил в статье

(20) ты франч? почасовка?

(19) смысл этого всего исключительно в том что я лучше понял недостатки 7.7 dbf. и кстати очень доволен этим опытом

(21) другу помогал))) какая почасовка

(20)
" да при чем здесь экономика?"
смотри (19)

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

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

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

(25) по той простой причине что такие базы только в терминале еще могут жить. иных способов заставить их существовать - нет

(28) бредятинка... если ты не знаешь этих способов, это не значит, что их нет...

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

+ если пишешь про константы, почему про периодику не пишешь?

(30) прочитай пост № (0)... там найдешь ответы на свой вопрос

(29) ловлю тебя не слове виртуальный хам. в двух словах изложи пожалуйста эти способы

(32) в посте (0) автор обратился к цивилизованной аудитории. Ответа на мой вопрос там нет

(33) 1sqlite устроит?

+ самое главное - автор настолько цивилизованен, что его даже сфоткать некому? самому себя фоткать приходится?

файл-серверный режим + 1sqlite? правильно я понял?

+(37) Азат верно я тебя понял????

(37) а объясни деревни, что означает "файл-серверный режим" в концепции 1С 7.7?

(39) пожалуйста. когда приложение 1С запускается на клиентской машине и тянет данные в виде файлов с сервера. Это файл серверный режим в любой концепции

(40)
сомневаюсь что и 1С так считает...

(40) а с примером можно?  что-то не допонял

а то что оно так и есть - это ничего?

(42) Это когда на компьютере с XP расшаривают папку с базой и обpывают этот компьютер Server. И другие подключаются к этой базы по пути \\Serve\Base\Buh

(44) это файловый или серверный режим работы?

+(40)
как я понимаю концепция 1С предполагает что "файл-серверный режим" использует   дополнительно СУБД SQL, Postgree или что  то  ещё

(45) файловый с файлами на сервере, поэтому и файл-серверный :)

(46) нет. то о чем вы говорите в концепции 1С называется "клиент-серверный режим"

(11) Почему не советуешь? У меня другая практика

(48)
ну а то что в (44)  - это файловый режим с сетевым/общим доступом...

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

(50) Вы уж терминологию не изобретайте. Это классический файл-серверный режим.

автор, сори. Не обратил внимание на dbf. Мне после гига в свое время было стремно юзать дбф. А ты молодец - 11 гигов - и еще оптимизировать можно.
Проделал неполохую работу.... Только есть подозрение что зря. Но это имхо.
И ни в коей мере не умаляет твоих заслуг.

(49) быстрый жесткий диск после дефрагментации во многих случаях работает не хуже RamDiska с вынесенными на него темповыми файлами. А то и быстрее (если конечно на рамдиск не вынесена вся база)

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

(52)
хм...  вобщето на сайте 1С для таких случаев используется термин "файловый  режим"

(0) Файл с расширением xml исключать из обработки антивирусом.
Слышал вроде, есть вирусы в xml коде.
Да и этот файл 1с-ка создает только в отчетности, не часто.

(5) Там вся фишка в скорости доступа. Т.е у рам диска  она на порядок выше и при случайном чтении (не линейном) разница в скорость заметна не вооруженным глазом

Или расшифруй термин "быстрый жесткий диск"

(59) да про ram disk уже все разжевано в инете. и многими опробовано. Не буду, скрывать, в своих изысканиях пробовал я этот способ. Недостаток этого способа в том что выносом темповых файлов на рам диск не добиться большого увеличения скорости. Максимум процентов 20. Дело в том что основные затраты времени затраченные 1С приходятся на извлечение данных из DBF-ок, которые лежат на жестком диске. Поэтому увеличение скорости работы с темповыми файлами дает небольшой прирост. Вот если всю базу положить на рам диск - другой разговор. Но это экстрим, и нет таких экстремалов кто на это пойдет. А вот устранением дефрагментации dbf-ок можно получить прирост скорости в разы....

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

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

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

после "транзакции при блокировке" читать не стал. Автору нужно штудировать терминологию, иначе...

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

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

...п.с. бывает, г... случается...

Графомания. Причем тупая.
франч, куле...

таки, потому такие перлы?? ориентированы не на специалистов, а на бухов и руков, которые не шарят в терминологии, но видели слова "блокировка", "транзакция", DBF и тд?? ну тада да, понять и пгостит нужно..

(63) Про временные расчеты писать не стал, это верно

(64) спасибо за мнение

(66) ну каждому своё. допускаю вполне что у Вас ни один метод не приведет к ускорению)))

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

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

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

(67) +100, да ещё и снеговичок по-ходу

(0)
1. 10-12 гигов в дбф - это мелкая база
2. Про отключение отборов - это бред
3. нет ни слова об оптимизации базы и об ускорении..
так, набор слов , которые не приведут ни к чему.
Разве что работы hogik пригодятся и всё.

(0) >Другие скажут – автор неправ, и предел для базы платформе 1С 7.7 DBF – это 1-2 гигабайта.

Не для базы это предел, а для одного файла. Оптимизируй-не оптимизируй, а 2 гб рано или поздно наступит.

(74) Влияет не столько сложность индексов, сколько их вариативность (что, собственно, и продемонстрировано в совете "оптимизации расположения измерений")
(73) А что касается графоманства -  дело не в "стиле изложения", дело в том, что статья "ни о чем", решений нет (кроме разве что рекомендаций по ромиксовской поделке, да решению от Hogic'а)
---------------
ну и что касается "Надеюсь что из данной статьи смогли почерпнуть максимум информации все три категории читателей:" - из данной статьи что-нибудь ценное может почерпнуть только откровенное ламерье...

(77) я ни одним словом не обмолвился о том что считаю что 1-2 гигабайта предел всей базы а не одного файла. Я ясно и четко написал в статье что для 1 файла dbf предел 1 гигабайт, а для всей совокупности файлов - размер 10-12 гигабайт не предел. Сколько лет в инете но каждый

Сколько лет в инете, но каждый раз раздражают такие всезнайки, которые вскользь прочли автора и бросаются вопить - ату его, он ламер!

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

простите, а Вы кого то определенно ламерите?? Рабочий день не закончился, но силы на деликатность пока есть))

(78) ну а вы то - Mikeware чего раскипятились? Человек пришел, сказал - так и так, написал статью популярным и несложным языком, рассказывающую о сложном - попросил оценить стиль и ткнуть на ошибки. И чего в результате? Вопли - да ты автор ламер графоман, и вообще снегурочник. Конструктива ноль. Такая среда (форума энтого) только и способна породить Фиксиных и подобных. Подозреваю, что не по адресу пришел узнать мнение суперов, чтобы потыкали носом в косяки. Хотя, тут суперов немало, если не свалили на другие форумы

(82) да ладно чего там. давай уж заламери мой опус по полной)))

(82) да никого. как и вы - не дурак, и знаю правила общения на таких форумах))

У меня была мысль придать статье более прикладной уклон. то бишь расписать всякие методики допроведения документов, прямого доступа к данным. только в канву статьи это не впишется. она написана в простом популярном стиле и такие техники там неуместы.

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

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

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

в общем "транзакции при проведении документов" - так и популярно и технически ну почти верно

Проведение документов есть транзакция, суть- атомарное действие. Транзакция - это благо для бухгалтера, а не беда.

очень многое зависит от построения работы и выбора структуры данных. Если говорить об оптимизации и ускорении - то один из вариантов - УХОД ОТ ТИПОВЫХ РЕШЕНИЙ. грамотно написанная самописка под кокнретно свои задачи без лишнего - будет себе шустро крутиться...

(79) у тебя русским по белому в первом абзаце говорится про размер базы. А если имеется ввиду размер файла, то, наверное это следует явно написать :)

Я то думал что статьи по оптимизации 7-ки  SQL писать моветон а тут оказывается еще про 7-ку DBF пишут:) Мое мнение что немного сейчас неакутально.

(93) + а вообще, в (0) ты сам попросил покритиковать и на аргументированную критику (даже если ты не согласен с ней) яд выпускаешь. Наверное книжки по психологии нужно почитать, чтобы адекватнее на мир реагировать ;)

Что тут можно сказать:
Во-первых, дефрагментация файлов для любой базы данных вещь важная. Просто в случае dbf у файлов больше фрагментов.
Но, можно дефрагментацию не делать, а просто периодически выполнять копирование базы на новое место (чтобы файлы создавались с минимальным числом фрагментов) - просто дефрагментация ntfs - это отдельная тема.
Во-вторых, директорию временных файлов лучше задавать свою для каждого процесса и нещадно чистить, чтобы в ней было как можно меньше файлов - тормоза бывают только из-за поиска файла в TEMP-директории, если там тысячи файлов.
Что касается блокировки - то робот-проводитель спасает от этих проблем очень хорошо - только приходится переписывать проведение и взаимодействие.
В остальном - про 1С сказано очень поверхностно - методы оптимизации из ничего - могут позволить получить прирост производительности, но кардинально проблему не решат.
Нужен анализ узких мест, но его, как раз, стоит начинать, когда простая "оптимизация" уже выполнена.

(93) читайте внимательней.

(94) неактуально. но поизучать этот вопрос стоит. так как 7.7 все еще занимает немалый сегмент

(94) Владимир а вот кстати зря бросили писать про оптимизацию 7.7 sql. Брожу периодически по старой памяти по вашему сайту, но там практически ничего не изменилось за последние 5 лет.....

(0) кг/ам. Бред, ИМХО. В чем оптимизация не вкурил.
Вцелом, для 77 все очевидно.

(94) там много бреда с заумным видом.

100-101 надеюсь ваши изыскания гораздо менее бредовы) а я буду дальше ковыряться в своем болотце)

(102) Однобоко как-то. Да и подход мне ... далёк что ли.
Надо уменьшать время блокировки таблиц, каких известно, способы пережеваны здесь не раз. ИМ способы те приводят к куда бОльшей оптимизации. Гибкие блокировки не предлагать або их автор Лично приезжал к нам в компанию, просидел ночь и воссторженный укатил восвояси.

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

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

+(105) более дремучих вещах

(105) не будь профаном, используй нормальную терминологию.
в 77 серверного режима нет, есть только использование другого движка СУБД

(106) то-то ты в них блуждаешь

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

(107) друг мой я отлично ориентируюсь в терминологии. В 7.7 реализован классический файл-серверный режим (7.7 dbf), и несколько уродский но тем не менее полноценный клиент-серверный режим (7.7 sql). Моя терминология правильна, а вот вы в ней видимо ориентируетесь хуже

"в 77 серверного режима нет, есть только использование другого движка СУБД" - вы похоже вообще не поняли о чем я))))) учите матчасть, прежде чем под личиной знатока критиковать якобы ламера))))

(110) свободен, как в поле ветер, гони волну дальше.

(112) ну что ж вы так. давайте подискутируем, я не против. Итак в чем вы считаете меня неправым? В чем мои суждения относительно клиент-серверного режима профанские?

(110) что есть клиент-серверный режим в твоем понимании?

Лично мной придуманного определения клиент-серверного режима у меня нет. Есть общепринятое толкование клиент серверного режима. Клиент-серверный режим заключается вот в чем: клиентское приложение формирует запрос к серверу - сервер принимает запрос, обрабатывает его и высылает клиенту уже результаты. Суть режима - если коротко - заключается в том что клиент посылает запрос серверу и от него получает уже готовый результат. В случае 1С 7.7: экземпляр 1С клиент посылает запрос серверу MSSQL, тот возвращает результат клиентскому приложению 1С, приложение отображает результаты

В случае файл-серверного режима (кстати многие софтины в 95-96 годах так работали) экземпляр приложения 1С тупо открывает файлы базы данных с сетевого диска сервера.

(115) в случае 77 хрен редьки не слаще - возвращается зачастую тот же набор данных, вот в запросах по-части кода 1с - там да, разница имеет место

(116) и?

(117) я и сказал что этот режим в 7.7 несколько уродский. но терминология у меня верная поверьте

к чему вся это некрофилия?

(118) что и? Я пояснил вам что такое клиент-серверный режим? Больше недоразумений относительно того что я якобы неправильно пользуюсь терминологией не будет?

ты еще вспомни про ограничение на количество отрытых файлов, глюки мокселя и прочее

(120) Совершенно ни к чему. Только к тому что я хотел услышать мнение всех о этой как некоторые тут говорят некро теме

(119) ну конечно, старый баян, если база на сервере - значит клиент-серверный.

(124) не заставляйте опять мне начинать объяснения заново ((( если не владеете темой - уж лучше молчите

(124) не заставляйте меня опять начинать объяснения заново ((( если не владеете темой - уж лучше молчите

(125) прежде, что бы разговаривать со мной подобным тоном, ты бы воспользовался поиском. Я сопровождал одну из самых больших баз 1С в РФ. Статья однобокая и никому она полезна не будет, ИМХО.

(127) Да мало ли что вы сопровождали. От ваших суждений волосы дыбом встают. примеры - "база на сервере - значит клиент-серверный", "в 77 серверного режима нет, есть только использование другого движка СУБД". Знающие люди поймут что вы в этой терминологии ни в зуб ногой

Мне то конечно понятно откуда "ноги растут" у такой неграммотности. файл-серверный режим как таковой давно не используется программным обеспечением. молодежь начинает уже путать классические режимы с терминологией принятой в 8-ке))))

(126) Если не сложно, приведите пример НАСКОЛЬКО эффективно ускорится работа при соблюдении всех указанных условий?
Предположим у меня 0-raid из самых шустрых SSD размер 1SJOURN = 3 GB одновременно копошаться 30 пользователей, в среднем 15 транзакций в минуту. ФС индексирована, внутренняя сеть гигабит.

(129) ты кого молодежью назвал-то?

(130) Понятия не имею))) я не знаю способа заставить 7.7 DBF работать с файлами размером 3 гб

(131) вас я назвал, вас)

(133) когда я впервые сел за комп, вы милейший еще титьку сосали

ФС индексирована - что вы под этим подразумеваете то?

(134) мне жаль что у вас не нашлось времени усвоить основные термины. Обратите внимание - вы обвинили меня в неуместности терминологии. А я доказал что путаетесь в ней как раз вы

(136) ты ни разу не упомянул программное сокращение времени транзакции

(136) Зачем мне весь этот бред усваивать. Раз ты такой копрофил найди статью на ИТС от 2002 года. Там всё было разжевано.

не упомянул. верно. такая информация не для популярной статьи.

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

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

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

(142) инфа на сайте как бы в основном и есть для админов и "бушек"... выдавать инфу с позиций знатока уровня МуМу я не стану. Не те знания пока

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

(143) Ок, а расскажи-ка мне, дорогой товарищь, вот при свертке БД программным способом не предпринмая никаких действий в конфигураторе, как именно изменится размер БД ДБФ?

(143) мда...все таки вы не оставляете попыток выявить во мне дремучего ламера)))
Никак не измениться)))) т.к. записи физически останутся в таблицах будучи помечеными на удаление))))

Бросьте вы это))) аж смешно))))

(147) давайте еще вместе по-смеемся, вы ни разу не упомянули про архивирование журнала регистрации, и кстати, раз вы так знаете про дбф, что ж в статейке не упомянули?

Хотите я вам как знатоку тоже задам пару вопросов про DBF? Выгрузили данные из базы DBF, хотим загрузить в SQL, появляется сообщение об ошибке и загрузка не производится. Назовите 3 самых частых сообщения об ошибке их их причины?

(148) "так знаете про dbf" - что вы хотели этим сказать?
Про журнал регистрации не упомянул по той причине что если файл журнала регистрации неповрежден то, будь он хоть 1-2 гиг, на скорость работы его размер практически не влияет) жду еще вопросов)) мне экзамен устроили))))

(149) нарушена уникальность индекса
     преобразование к типу datetime не может быть выполнено
     поле, по которому выполняется сортировка должно входить в группу. Встречал и еще, но уже слабо помню

Сапфир, я программирую в 1С уже почти 10 лет. вы вряд ли сможете выявить что то что я не знаю в 7.7. в 1С 8 запросто сможете

(151) ну да. вижу вы с dbf тоже поварились

(152) Да, а я 15 лет. Дальше что?

(154) да ровным счетом ничего. у меня нет претензий к вашему опыту. это вы пытаетесь выявить во мне ламера. а так все норм

(155) Если статья для недоадминов и прочей полу-пользовательской братии, ИМХО, стОит убрать сведения о программерских делах.
О прожектировании... Константах и прочей муры, дабы обслуга не влезая в код могла воспользоваться Вашим бесценным опытом. ИМХО

я уже призадумался что таргетирование может нужно подправить. С другой стороны, я вот заметил такую тенденцию - молодое поколение восьмерочников даже той мишуры о 7.7, что описана в статье могут не знать. а семерка еще попадается. Хоть и древность 7.7, а знать пока всю эту тряхомундию еще не помешает

(103) > просидел ночь и воссторженный укатил восвояси.
- и чем он так восторгнулся?

(157) Возможно, что не знают.

(158) Количеством одновременно работающих пользователей, транзакций и объемом документов. Ну и, времени транзакций.

Какой из авторов и каких гибких блокировок то? МуМу или Павел toysql?

(160) а поподробнее? чат в скайп Zlopun? - прсото интерсено, ну и почерпнуть полезное надеюсь.. для меня 7-ка пару лет еще будет актуальна стопудово...

(161) Паша. Это было в 2005.. летом, кажись в мае

у МуМу блокировки подороже были... Возможно его версия взлетела бы удачней

а! ну да! и сапфир и секубан - вы еще навернео про программированиеи не задумывались, когда я уже программил ;-)

а к нам МуМу приезжал в 2004)) не восторгался был мрачен) сделали его ребята свои блокировки - на тот момент результат был неплох

я вот смотрю на свои мелкие потуги по оптимизации рабоыт типовой - емае... если бы это реальные спецы делали - да вообще бв все еще торпедистей летало.. ;=)

да у меня бывает еще круче))) моя прошлая ошибка в оптимизации проявилась в торможении типовой комплексной относительно производительности типовой чистой))) лучше бы не лез)) хорошо парни местные обозвали ламером и я осознал косяк)

да у меня бывает еще круче))) моя прошлая ошибка в оптимизации проявилась в торможении МНОЙ ОПТИМИЗИРОВАННОЙ типовой комплексной относительно производительности типовой чистой))) лучше бы не лез)) хорошо парни местные обозвали ламером и я осознал косяк)

Крупные специалисты мелких ошибок не делают.. если уж косячнут - то мало не покажется.. ;-)

Парниша, послушай совет от Иллиты как я.

Ты мог просто написать - не делайте файловые базы, а делайте SQL. Всё.

SQL на много быстрее работает. Быстрее восстанавливает данные.

Даже к тому примеру, есть база 4 гига, которая 4 дня загружается в файловом варианте и 2 часа в SQL варианте.

Опять же в SQL варианте и в 1С 8 реализовали базу в одном файле, а в файлово варианте 1С 7 тонна файлов dbf которые и тормозят систему

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

"Индексные файлы будут воссозданы заново." лучше "созданы"

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

для уменьшения фрагментации файлов базы я ставлю размер кластера на разделе этого диска на максимум - 64кб

(175) А я перевел последних своих бухов под снеговик. Все, клюшки больше не обновляю. Как пел Высоцкий - "я от восторга прыгаю..." ;-)

(177) Документооборот какой? (объем)

(0) в статя слишком целеуказующая, а большенство пунктов по оптимизации весьма и весьма сомнительны и бездумно их нельзя применять,

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

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

(178) Маленький. Ну так меньше сотни документов в месяц. А что ?

еще можно добавить про настройки сервера, про использование файлового кеша, отложеной записи, индексации.
далее указать какие файловые системы подходят и чем они лучше/хуже
про диски ssd и другие "железные" ускорители наверно нужно написать

Кстати бывают случаи(хотя и достаточно редко) когда переход на SQL(не важно с гибкими блокировками или без них) очень трудоемок. Это бывает когда из конфигурации и DBF движка выжимают все по макимуму. То есть когда большая часть функционала заточена под DBF.(как правило это делают действительно профессионалы) Причем это касается больше не документов а именно отчетов,обработок, форм подбора. В этом случае при простом портировании соответсвующий функционал начинает тормозить. В этом случае необходимо серьезно все переписывать.
Вот на эту тему статейка(писал не я).
http://softpoint.ru/article_id413.htm  
Я видел случаи когда на DBF умудрялись работать более 300-т пользователей одновременно. Там конечно было все заточено и оптимизированно. Но в конце концов у них вся система стала колом. Причем очень жестко.

+(182) А востановление последовательности в монопольном режиме в DBF при правильной реализации всегда будет оставлять за собой MSSQL. Так что везде есть свои ньюансы которые нужно учитывать.Для этого впервые пришлось разрабатывать свой координатор блокировок и применять многопоточное востановление последовательности, иначе никогда не вышли бы на требуемые показатели.

(182) ТОЧНО !!!!!

по этому я однозначно против всяких "ускорителей" и т.д.
Система должна быть девственной :)

в любом случае нормально сделаная оптимизация - по деньгам стоит дороже перехода на 8.х, по этому я просто не понимаю зачем это нужно сейчас.

Везде где я бываю я всегда по возможности выгребаю всяких телепатов, формексов, прямых(кривых) запросов, и все работает.

(182) Во-во, если существует хоть теоретическая вероятность падения дбф-базы при больших объемах - то ну его нах эту дбф.
Автор пропагандирует именно поддержку дбф в рабочем состоянии, хоть бы объяснил: для чего?

(174) можно написать "возрождены заново" :-)
(175) о чем, собственно, выше и сказано топикстартеру.

(183) Это требует радикальной переработки. Которая просто не может быть продумана (или даже понята) топикстартером.
(185) не у всех большие объемы. Вон, мне один товаристч вопрос задавал - "может ли SQL версия работать с гигантской базой (6 ГБ) и огромным количеством пользователей (30 человек)?"  :-))) Ну вот что тут ответить?

(184) Я не согласен с этим утверждением.Все зависит от ситуации. К примеру  только сейчас веду пару проектов каждый из которых более миллиона долларов. К тому же для бизнеса важна непрерывность работы. Видел компании которые теряли бизнес из за олухов от ИТ которые так криворуко внедряли 8-ку(и не только)что регулярные простои системы приводили сначала к потери доли рынка а потом к потери бизнеса. Для бизнеса не важно система девственна или нет - важно что бы она работала качественно и бесперебойно.:) А какими целями это достигается это уже второй вопрос. Основная проблема когда переходы с больших ИТ систем планируются и реализуются на глазок, без применения проектных подходов. Типа ну а чего там перейти с DBF на SQL? - Это же типовая операция! Да вот только есть ньюансы:)

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

(184)
Простите, но "телепат" - никоим образом не работает в режиме предприятия, и "выгребать" его для ускорения работы программы бессмысленно. Вот для замедления работы кодера - имеет смысл :).

Зачем на ТС наехали? Ну баян... ну не все моменты рассмотрены... Так в заголовке сразу было указано для каких условий статья. И В рамках поставленных условий все описано почти корректно. И некоторым, которые мнЮт себя спецами, а за работу ДБФ знают только что это "ацтой и дерьмо мамонта" - очень полезно.

+(188)Переход с одной системы на другую это вообще отдельная тема. К примеру в одном из проектов натолкнулись сразу на 5-ть ошибок платформы(8-ки, предпоследний релиз).(утечка памяти по 4GB,100% загрузка rmngr при входе, вылет на деадлоке всех пользователей на v8users, две ошибки ключа).  Причем все ошибки плавающие просто так не моделируются, но при этом критичны. Возникают только на больших объемах инф. потоков.Все ошибки локаизовали и разобрались как обходить. Подойти бы к проекту без нагрузочного тетсирования и многих других мероприятий и сразу можно сесть в лужу.

(188) ну сдуру и хер сломать можно, конечно ЛЮБЫЕ рекомендации и подходы нужно применять с умом, ну и конечно всегда есть исключения :)

(189) Админы не справятся, бухи тем более. Того, кто не знал написанного - подпускать к базе просто нельзя. тот, кто может оптимизировать работу - знает гораздо больше ТС.
смысл статьи - в самой статье. Типа, "я опубликовал чёткую штуку, и ее прочитало 100500 человек - я неимоверно крут." Т.к. это даже не реклама горе-обдимизадера, да и собственных мыслей нет  - это чистой воды графоманство.

+(191) Года два назад пришлось перегонять данные из фоксовской программы (ДОС 2.6) в восьмерку. Так франевый спец протрахавшись неделю с переносом выдал перл : "пока не перешли на 1С - сделайте доступ к базе по сети и работайте". Абсолюно не озаботившись тем, что файлы фоксовской программой открывались монопольно. После того как ему объяснили этот ньюВанс был выдан очередной перл : замените по тексту EXCLUSIVE на SHARED и "не делайте мне моск". Парень опять жеШ не учел необходимость блокировки записи перед записью в случае открытия файлов в режиме SHARED. И снятия блокировки после.

А вы говорите "баян"...

(97) >"читай внимательней"
"предел для базы платформе 1С 7.7 DBF – это 1-2 гигабайта. "

хз, что тут внимательнее читать, русским по белому написано, что предел БАЗЫ - это 1-2гб :)

(194) тык он не въехал, что есть "графоманство". Почитал ночные разбоки у кого длиннее - ржака. Но стойко стоит на своем, хотя было уже не раз сказано - статья ни_о_чем

(197) ну, если у него длинный - он и стоит на _своем_...
:-))

(0) надеюсь, ты не сделаешь статью в виде краткого описания и посыла скачать статью в прикрепленном файле?

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

(196) Сударь, Вы не правы!
Предел не базы, а файла ДБФ или его индекса.

(203) После этого будет написана другая статья, продолжение этой.

(2) > Инструкция по изучению аромата гомна мамонта? Круто!
Мамонты вымерли в отличие от v7.

А почему еще нет голосовалки?

1. Статья мне поможет жить правильно.
2. Статья не раскрывает тему Сисек.
3. КГ/АМ
4. ??????
5. Профит

(206)В некоторых отдаленных местах, даже крутится 1С 6 :)

(207) Точно, я бы выбрал 5-й пункт.
Все равно, автор старался, тратил время, а его тут гнилыми помидорами.

(209)А я бы № 3 :)
Ибо старания по онанизму не засчитано

(171) Спасибо улыбнуло

>>> SQL на много быстрее работает. Быстрее восстанавливает данные.

Все, все на SQL, и побоку, что 7.7 заточена на DBF, как ни крути :)
Главное, что сказал, какой-то FREEEEs :DDDDD

(204) Так это я цитату из (0) привел :)
из первого абзаца по ссылке в (0):

"Другие скажут – автор неправ, и предел для базы платформе 1С 7.7 DBF – это 1-2 гигабайта."

БАЗЫ, базы предел написан, а ТС упирается, утверждает, что корректно написано. Видимо лень ему исправить эту фразу для однозначности трактовки :)

(213) Уф. Видно требуется перевод с русского на русский. в том месте статьи написано что автор считает что 10 гигов для базы не предел. автор это утверждает затем, чтобы оспорить мнение тех кто считает что предел для гомна мамонта 1-2 гб. далее в тексте автор уточняет что единственное важное ограничение - это предел размера одного файла в 1 гб.
---
Но водятся же фокусники которые выдрав фразу из контекста статьи - "Другие скажут – автор неправ, и предел для базы платформе 1С 7.7 DBF – это 1-2 гигабайта." - радостно вопят - ааааа, автор соврамши, и не знает что предел 1 гб не для базы а для 1 файла)))
--
Умеющие читать сейчас посмеются абсурду вместе со мной)))))

(214) Никто радостно не вопит. Ты просил покритиковать, я тебе аргументированно покритиковал. Не хочешь слушать (да еще и бесишься), зачем критику заказываешь? :)

так критика не должна быть бездумной. хотите сказать что из той фразы явно следует что автор считает что предел базы 1 гб?????

Дело в том что на форумах полно вопросов о том что база у чувака достигла 1-2 гб и чувак боится что - все, предел. Вот в том и смысл той фразы - что нифига не так!

ладно, речевой оборот в той фразе наверное действительно тяжеловат для восприятия. Критику осознал

(194) "тот, кто может оптимизировать работу - знает гораздо больше ТС." - Этот "тот"  - Вы? Бегло опишите методики о которых я не знал, и не смогу осознать. Я готов признать себя ламером если вы назовете такие методики. В противном случае жду того же от вас. Поехали?

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

я жду ....

(221) Да расслабься это уже не интересно.
Джентелмен шоу был убогим и нет смысла его вспоминать. А вот сейчас рули камеди клаб. Хотя тоже УГ. Лучше уж КВН вечный.

(221) НУ в целом молодца за старнаие. Хотя подносить сняряды в конце боя уже нет смысла.

(219) Да более чем легко! навскиду:
1. Вынос некритических расчетов при интерактивном проведении за транзакцию.
2. Замена штатной периодики - другой, например, регистром
3. отказ по максимуму от строк неограниченной длины в связи с похабной реализацией ее именно в дбф.

4. отказ от глобальных переменных и процедур. переход на локальные контексты везде где только можно.
5. отказ от использования неразделяемого общего журнала документов.

6. Переход на использование объекта "Периодический" (если нельзя от штатной периодики отказаться)

7. вплоть до разделения однотипных сущностей на разные объекты учета - на каждый склад - свой регистр.

(223) Масса фирм и фирмочек юзают 7.7 (у нас в мухосрани например)
Да притом какую-то древнюю ТиС, что аж подташнивает... и ничего
Правда обычно при больших объемах уже SQL присутствует... ибо гимор еще тот

(224) хрень собачья. хрень именно в том смысле что наивно полагать что ТС не знал того что вы описываете. см. 222

(228) эээ а как обрезание базы повлияет на скорость..? и на скорость чего?

(231) Мне всегда помогал обрезание базы.
База 7-8 гиг иногда даже 4-5 гиг режем оставляем год или два. база превращяется в 1-2 или 3-4 гига. И все начинает шустрее работать. Правда в основном в скуле это я делал. Но думаю даже в дбф такая же песня.

Ну база меншье таблиц меньше таблица итогов меньше индексы и прочее.

(0) Взгляд в прошлое, или Способы оптимизации больших баз 1С 7.7 DBF. 10 гигабайт для базы DBF не предел!

Алексей у тебя ИМХО а я перепробовал все мыслимые и немыслимые способы в попытках оживить базу в 11 гигабайт.... результаты в статье

Автор темы молодец.
Когда его база достигнет 12 гигов. будем ждать статью "11 гигабайт для базы DBF не предел!" и далее :-)

(230) ТС это даже не упомянуто. Ну а то, что единственный способ оптимизации, упомянутый в статье - это изменение порядка полей в соответствии с вариативностью - и позволяет утверждать (не "полагать", а "утверждать"), что ТС упомянутого в (224) банально не знал...
(232) Если индексы строятся нормально (по вариативности полей), то время, затрачиваемое на добавление  в индекс будет достаточно мало, (добавится страница а перебалансирование дерева не потребуется). Величина таблицы итогов тоже не сильно влияет, т.к. работа в основном идет с последними итогами, а там первичное поле индекса - период.

А что можно хранить в базах по 200 гигов - я ваще не понимаю. Порнушку разве что.

(235) База за 3 года при нормальных объемах - легко достигает 50Г. Особенно если учет достаточно расширенный. Если куча автоматизированных периферийных розничных точек - то и 200Г достигнется без проблем.

(236) Да шутил я. Киргуду.

(237) сам ты Бамбарбия. :-)

(236) В таких базах, наверное, имеет смысл автоматическая свертка/архивация прошлых периодов с выгрузкой в большую архивную для аналитиков. Один фик вымывание ассортимента идет. Я по той же одежке сужу - 4 коллекции в год и больше не повторяется. За 3 года номенклатура 100 тысяч. А по факту на складе только 5 тысяч. Ну это так, треп.

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

(240) в статье фактически один абзац про оптимизацию. остальное - обслуживание.
Ну и ". Не используйте строки неограниченной длины в качестве измерений регистра. Если вам все же крайне необходимо использовать измерение с таким типом – размещайте его последним в списке измерений. (Последнее касается всех объектов с типом строка неограниченной длины. В частности, в списке общих реквизитов документов, реквизиты с упомянутым типом должны находится в конце списка)" - просто убивает

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

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

(244) И все-таки это "ж-ж-жжжжжж" неспроста. Это пчелы, а значит мед. (с)

(243) Угумс.
Меня, например, убила фраза: "ИТ-специалисты, которые хотят понять все недостатки платформы 1С 7.7, для аргументированного принятия решения о переходе на платформу 1С 8.2"
ну кто ещё, кроме франча, мог такое выродить?
Автор: у тех кто работает с более-менее большими базами давно всё оптимизировано, и в штате отсутствуют сотры лоббирующие переход на снеговика, а франчей с такими предложениями гонят взашей.
У счастливых обладателей мелкого бизнеса и так всё летает без оптимизаций.
Ещё раз: статья ни_о_чём, так как нет целевой аудитории, которая может потребить с пользой сабж

(246) И все-таки некое уныние статья и ветка навеяли. Похоже, рано или поздно снеговика учить придется.

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

Добрый вечер мои тщащиеся в поисках ламера для издевок друзья ))))) Я с радость возвернулся к вам ибо рабочий день кончен)))

//1. Вынос некритических расчетов при интерактивном проведении за транзакцию.
поможет но не сильно
2. Замена штатной периодики - другой, например, регистром
//периодику и так неприемлю. использую по минимуму
3. отказ по максимуму от строк неограниченной длины в связи с похабной реализацией ее именно в дбф.
// ну про это я писал
4. отказ от глобальных переменных и процедур. переход на локальные контексты везде где только можно.
// можно. можно еще компоненту turbobl воткнуть. прирост незначительный
5. отказ от использования неразделяемого общего журнала документов.
// смысл? физически все документы все равно в одном файле
6. Переход на использование объекта "Периодический" (если нельзя от штатной периодики отказаться)
// уже писано выше
7. вплоть до разделения однотипных сущностей на разные объекты учета - на каждый склад - свой регистр.
// вот это идея неплохая. но увы опробованная
(0) Не рассмотрели самый действенный способ - обрезание базы ;-). На самом деле достаточно сделать архивную копию базы, и обрезать основную.
// ну это само собой)))

Ну а теперь поделюсь теми методами которые использовал (к ужасу Mikeware мечтающего найти во мне ламера):
1) Отпочковываем от рабочей базы новую периферийную. Пользователей разделяем на 2 группы: а) группа забивающая документы на ТА - работают в старой базе б) пользователи строящие в основном отчеты, и иногда забивающие документы как на ТА, так и прошлым числом - в свежеиспеченной переферийной базе. Раз в полчаса автообмен

2) способ. Похож на способ предложенный Злопчинским. Способ условно можно назвать - дублирование регистров. Суть способа состоит в том что в конфе заводятся новые регистры - дубли существующих. Выбирается день Х. На начало дня Х делается "снимок" итогов регистров остатков и заносится в соответствующие им дубли. В код конфы вносятся такие изменения что все документы начиная с дня Х проводятся по новым регистрам, отчеты тоже изменяются - для отчетов по регистрам оборотов в код запросов просто дописывается второй регистр. Отчеты по регистрам остатков переписываются так что до дня Х отчет формируется по старому регистру, со дня Х - по свежесозданному дублю этого регистра. Недостаток: Сформировать отчет с начальной даты = (ДеньХ-1 день) по конечную дату (ДеньХ+1) конечно же нельзя.

а вообще Mikeware вы наверное слишком молоды. Странно так искать в других незнание и глупость, когда повода нет. Сублимируете что то признайтесь?

"и не дятлами типа данного статейпейсателя." - опять Mikeware вы пыжитесь. Попробуйте улыбнуться людям и увидеть в окружающем мире что то хорошее. Если вас кто то обидел - то безуспешными попытками обидеть другого человека - вы ничего не добьетесь. Давайте попробуйте улыбнуться)))) Ну?)

(250) п.1  помогает как раз лучше всего. правда, использовать его надо очень аккуратно. Как, собственно, и ГибкиеБлокировки от софтпойнта.
2. приемлешь или нет - вопрос вкуса. а вот использоваить ее надо . в ламеростатье о замене штатной периодики ни слова.
3. ога-ога. поделись еще способом использования неогр. строк в качестве измерений - штатно систем не дает такой возможности. не поленился, специально файловую развернул, проверил...
4. прирост ощутимый.
5."в одном файле" - не "все документы", а лишь предопределенные реквизиты, и общие с отбором. Поэтому сгенерировав определенное количествро "пустышек", можно легко и непринужденно создавать документы без блокировки общего журнала. И даже "проводить" (правда, в файловой не пробовал, пробовал только в сиквельной - но как сделать - знаю)
------
так что опять ламеризм свой вы выставили во всей красе

(251) Тоже ничего нового, широко использовался в начале 2000-х, когда не было других решений.

(0)Взгляд в прошлое...
вы рассматриваете свои фикалии?

(255) мой угрюмый друг в статье я написал о том что посчитал нужным. Не вижу необходимости задыхаясь вываливать все что знаю)))

(256) мой угрюмый и злобный друг - а я что обещал что то новое?)))

(253)
Ну, во-первых, "молодость - это такой недостаток, который со временем проходит"©
А вот глупость - она только усугубляется. в 30 лет ума нет - значит, и не будет...
а во-вторых, программировать я начал примерно в то время, когда вы только учились говорить. так что как раз наоборот, "с высоты прожитых лет..." :-)))
а до маразма мне еще далеко :-)

(260) дурачок ты молодой и злобный)))

(259) ну, "написал статью" - все-таки претензия на что-то оригинальное. или по крайней мере, на обобщение. а получился - высер.

(261) не, молодой дурачок - это как раз ты :-)

(262) да нет же - получилась самореализация))) к моему удовольствию) а злобный высер - это у вас увы(((

(257)Он не только их рассматривает - он их выкладывает на всеобщее обозрение, и при этом ими еще и гордится...

(264) т.е. графомания.

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

(255) хм....а давайте ка вы мне расскажете что из общего журнала то бишь 1sjourn.dbf можно исключить некоторые документы "сгенерировав определенное количествро "пустышек", можно легко и непринужденно создавать документы без блокировки общего журнала"? Вот это действительно интереснооооо )))) Опишите ка?

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

(269) вот я и рад что вы наконец смогли покритиковать конструктивно и указали на ошибку))) Спасибо !

(268) Да в общем, все достаточно понятно описано. Нормальный человек - поймет и реализует. а дятел не поймет, зато ничего не испортит.

(255) Эх, придется вспоминать каково экзаменовать стажеров... Mikeware расскажите ка мне чем отличается Общий журнал от Обычного журнала и от Дополнительного журнала?
P/S/ Ха, походу снегурочник попался))))

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

Наводка - как вы считаете верно ли утверждение "в общий журнал всегда включаются документы всех видов"?

(273)Mikeware - хорошо, я уже понял что вам нельзя волновался и нервничать))) Пусть я буду для вас ламер))) Все равно белое не станет черным даже если его так называть

(272) вспоминатель... :-)
а вы знаете, как они устроены "внутри"? :-)

(276) неоднократно открывал dbf-ки))) так что знаю)

(275) не "для меня". ламер - он всегда ламер. независимо от того, кто на него смотрит...

+275 и спец всегда спец независимо что о нем говорят неуравновешенные))))

(277) а причем тут dbf-_ки_ ? :-)))
собственно, она одна :-)))

(279) согласен. только "спец" - это не про вас :-)

(276)Mikeware открывайте 1sjourn.dbf любым редактором и жду от вас объяснений как реализовать то чудо о котором вы говорили)

(282) в (255) п.5 все описано в достаточном для специалиста объеме. Можешь, например, спросить ... ну, Злопа - он тебе ответит, понял он, или не понял. :-))

секубан. не суетись.
статья - она либо обзорная чтобы завлечь, либо полезная - чтобы почитать и применить.
у тебя в статье середина наполовину. ни то ни се и сбоку бантика даже нет.
.
как для самореализации - пойдет.
для остального - нет. ибо все уже на 8-ке или остались на 7-ке и знают гораздо обольше чем в статье. а если не знают все глубоко - то и статья неинтересна - ибо полезного в ней - только очевидное и общеизвестное.
.
автор, пиши еще!

Подождите, почитаю что там в 255, мну про журналы интерсено

(284) с таргетингом статьи определенно есть проблема. это обсуждение выявило это. буду править что делать

ладно ждем Злопчинского

(255) идея про пустышки в общем журнале - интересная. но имхо это уже суперизвращение.. ;-)

(288) Будь другом поясни что наш супер спец имел в виду? А именно как создавать и проводить документы без блокировок 1sjoun?

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

(288) Но ведь несложно, правда? :-))

(291) да хрень собачья))) невозможно избежать блокировок 1sjourn)))

(289) как как.. как я понял - ЗАРАНЕЕ СОЗДАЕМ пустышки с нужными наборами. а проведение - это всего лишь взвод отдельного флажка.. ;-).
.
босюь что я все-таки чего-то недопонял...
.
но если придется оптимизацию делать таким способом - это все, стреляться можно. мне кажется что гораздо больший эффект дадут организационные меры.
.
и вообще - при поточной работе - 95%проблем уйдут. все проблемы при конкурирующей работе. во многих случаях ее тупо можно свести к поточно-линейной.

(293) это вроде как мне тоже понятно. Блокировки 1sjourn все равно то останутся

(290) а второе по существенности - уменьшение оставшегося времени блокировки.
третье и четвертое  - делят работа с 1сконст (константы и периодика), и правильная организация индексов.
это примерно 90% всей оптимизации

(225) "5. отказ от использования неразделяемого общего журнала документов." - не понял ты о чем?

Кстати Злопчинский вот тебе кое что. Проверь у себя. Скачай утилиту ConfigNT. На закладке Memory Managment установи галку Maximize Throughput for file Sharing и галку Use large system cache. Перезагрузи сервер и проверь с какой скоростью работает конфа...

(296) да он ушел от этого вопроса. Если начнет отвечать ... то я выиграю это шоу. Он знает это

(295) Это все дает малосущественный прирост. Мне кажется вы не оптимизировали такие базы. Вся затыка в файловой dbf базе - это в скорости дисковых операций. Только это может реально ускорить базу. Я это уже понял, а вы пока нет. читай (297) и проверь у себя на dbf базе

(0)ГЛАВНАЯ ПРОБЛЕМА БОЛЬШИХ БАЗ 1С 7.7 = DBF.

300 -> 299

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

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

(302) не люблю понты и тех кто говорит не подумав. Все кто прочитают твою идею про журнал поймут все что нужно ...

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

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

(304) ну так я и сказал в (271)- у кого мозги  есть, те поймут. вам понадобилось разъяснение человека с мозгами - Злопа...

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

(306) правильно. даже не пытайтесь спорить. чем больше спорите, тем ярче показываете свой ламеризм.

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

(309) и это 44 года.... надеюсь я в 44 года не буду таким.....

(308) Ну, штатных объектов в 7.7 кот наплакал. Поэтому приходится использовать документы. а они хранят заголовки в журнале. увы.
не, были, конечно, как помнишь, реализации учета "на справочниках"... Забавно, но не более того

(311) естественно. я ж сказал выше - если в 30 лет ума нет, то и в 44 не появится...

(313) А у вас ум есть? Ответьте мне если не сложно

да фиг с ним. для среднечайниковского уровня по йдет статья - вроде и полезная вроде и  нет. по сути собран минимально необходимый набор действий по начальной оптимизации. франчи этим не занимаются. фикси на ставке - этим не занимаются ибо давно сделали. от фриланса которые мечется как электровеник - вреда больше чем пользы. пойдет для тех кто ВДРУГ присосался к 1С.
.
автор пиши еще, пойдет. критиковать могут все. писать - меньше ;-)

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

(314) спроси мнение (315), например...

(315) то что написано в 297 тут пояснять не буду - в статье распишу подробней, для чайников.

(317) Я не зря спрашиваю вас а не его. У вас ум есть?

(311) я в твоем возрасте тоже не верил во многое. а сейчас - такой же как Макивара. И ты таким же будешь. даже еще хуже. Ибо сумма разума на планете - величина постоянная, а население - все растет. Макиваре и мне в 44-46 досталось явно больше чнем останется тебе в твои когда-нибудь наступящие гремящие сороковые.

(318) статью только снова сюда слей... следующий раз уже народ пар повыпустивши будет...

(321) вот этого то я и боюсь. имея семью, детей, хорошую работу и буду таким в 44? Нет, не могу в это поверить. Я и сейчас то не такой. Ну пытаюсь по крайней мере

+(321) только в пятницу. он зарекомендовал себя как "шоумен". ну, или просто клоун.

(323) можно уточнить "он" - это я? Вы уверены что я.......?

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

(324) абсолютно уверен. более того, вы сами об этом сказали чуть выше.
Клоун, и не более того.

(325) что, так и не поняли? этого и следовало ожидать. тут копипастерство не поможет, тут думать надо... немного, правда. Но надо.

(327) вы ж сами в (307) радовались что я понял благодаря объяснениям Злопчинского... Этот факт вы решили проигнорировать чтобы писать как в (327) Неловкая игра)))

(327) Дедушка (ведь вам 44 и я вас намного моложе) у меня к вам вопрос помимо вопроса о уме. Скажите а вот у лайт-модераторов есть некий кодекс благородного поведения на форуме?

(329) Нету, помимо неприкосновенности ничего нету

(330) жаль. был бы я Волшебником я бы первым делом ввел кодекс благородного поведения для модераторов. Хотя может ему выгодно что среда породившая Фиксина (действительно шоумена и клоуна), и его изгнавшая - кстати, сама мало от него отличается...

Посмотрите во что превратилась тема. Шоу. Причем шоу делалось модератором. Грязными приемами.....

отклонились от темы )

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

я так и не понял на что рассчитывал ТС))
те кто давно на 8 - будут лишь плеваться от 7.7 на dbf
те кто на 7 и сейчас наверняка знают больше чем ТС у которого опыт ограничен "помощью другу"

(335) я еще в (19) поднимал этот вопрос, но ответа на него так и не было

(335) опыт ограничен 10 годами программирования на 1с...
ТС рассчитывал на критику и указание ошибок. Что и получил даже

(328) Просто я полагал, что вы несколько поумнее. Что все-таи с подсказкой, но дойдет. Похоже, я вам польстил...
(329) ну, вы то меня "слишком молодым" считаете, то "дедушкой"... вы уж как-нибудь определитесь...
А кодекс поведения модератора... я считаю, что право называть вещи своими именами (т.е. дурака - дураком) вполне вписывается в правила поведения...
(332) то, что вы организовывали шоу - вы сами признались в (298)
(337) то, за "10 годов программирования на 1с..." вы дошли лишь до такого уровня понимания используемого инструмента - достаточно хорошо показывает ваш уровень.

(338) ТС написал в своей статье лишь то что хотел написать. А вы, простите, всегда стремитесь вывалить сразу все что знаете?))))

(338) ладно. объясню попроще что я хотел сказать. Я хочу чтобы вы описали свою супер идею про журнал документов тут сами. Своим языком. Хочу чтобы люди прочли вашу безумную идею и убедились что она ваша. А не с моих слов. Не поверят же))) Поняли теперь?

(338) а как вы считаете назвать дураком дурака может тот кто ведет себя недостойно? Нет ли тут ошибки как считаете? Логично предположить что тот кто ведет себя достойней как раз таки не дурак...

а что недостойного было?

ЗЫ, а забаньте автора кто-нить?

(342) а вы считаете поведение Mikeware достойным? Ну почитайте какие комплименты он мне щедро отвешивает.

(337)
я конеч меньше с 7ой работал - лет 5 и только на SQL, но ИМХО описанное в статье это регламентные операции, а  оптимизация - это что то вроде прямых запросов и т.п.

(343) я, например, просто считаю, что ты - му**ак упертый до нереальности... проще стенку убедить, чем тебя...

(340) идея не "безумная", а вполне реализуемая. Не без геморроя. Но при необходимости - возможна программистом квалификации чуть выше средней.
описывать ее подробно нет необходимости. Спрси, например, Азата - он тоже наверняка понял, "в отличие от" :-)

(342) Да не забанят. Дело в том что такое шоу - автор которого модератор, выгодно форуму. Больше читают. Больше приток посетителей. Не исключено что модераторы и приближенные СПЕЦИАЛЬНО хамят и провоцируют конфликты. Шоу интересно не только в телевизоре, но и в инете. Это специальная линия поведения модераторов и приближенных (а вы Азат тоже сотрудник - инженер знаний). Скрываемая от наивной публики полагающей что автор действительно воспринимает Майквара всерьез.

(346) Ну чтож. Ваше право считать меня хоть имбецибелом пишушем скрюченными ручками из специализированного интерната))) Истина от этого не пострадает.

(347) ни*уя себе, а чей я сотрудник? у меня трудовая дома лежит, я так-то безработный на территории РФ вообще :D А почему Майквара не воспринимать всерьез? Он мне лет 5 назад очень неслабо помог))

(349) Инженер знаний у вас стоит в профиле. Молодец что помог. Значит он хоть и невежлив и невоспитан - но способен на что то хорошее

(344) об этом ТТСу и было сказано неоднократно, в т.ч и мной в (242), например, или Злопом в (220)

(349) Не воспринимать всерьез его шоу по дискредитации оппонента. Вот что адекватный человек почитав эту тему не станет делать. А как специалист он - сложно сказать - но может и неплохой

(349) чем помог?

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

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

(353) у меня с СКЛ сервером траблы были, я тогда полдня голову ломал, не взлетало никак....

(352) для вас и вашей контооры дискредитация - это т.н. "статья", и устроенное вами шоу, демонстрирующее ламеризм...

(354) так и есть. Директор молодой развивающейся компании. А сотры не читали, они и так это знают))))) Смеятся не будут, т.к. работать бок о бок несколько лет - вот что помогает узнать человека, а не рекламная статья)

(357) Вы кстати я так понимаю читаете её периодически? Я сейчас дописываю в ней кое что. Допишу скажу вам!

(358) ну все, после этого понятно, откуда ЧСВ такое нереальное... еще небось ездишь на чем-то вроде Н2 или Эскалейда, чтобы солидно выглядеть))

(355) уж что-что, а "груз знаний" вас точно не тяготит :-)) Ввиду отсутсвия...
никто не запрещает вам писать всякую куйню, но будьте готовы к тому, что куйню назовут куйней...

(360) ну нет что ты. Откуда такие деньжищи на Н2. Отечественный у меня авто

вы все оптимизацией  занимаетесь??. ну, оптимизируйте 77, комплексная, входные данные следующие: база больше 50 гектаров, иногда проведение завешивается систему на более чем час-два, простейшие отчеты крутятся более получаса, проблема в размере таблицы 1СКонст...

(359) да одного прочтения хватило... Я столько смеяться не могу...

(363) ужас, срочно к автору, он однозначно соптимизирует за 10 копеек базу!

(361) точнее сказать будьте готовы к штурму неадекватов? Проходили мы уже это, знаем все. Без этого миста не миста)))

(364) ну вы если передумаете - читайте завтра или в пятницу. Ок?

(365) да нет. SQLные базы куда лучше соптимизирует Муму или Toysql.

(365) ле, тормози))) я еще одну вводну не дал))

(393) Комплексная, 102Г. (архивная). Тормозит. Но работает. Основные тормоза были при расчете оборотно-сальдовой за 2-3 года :-) Решено.
Ну а работу с 1сконст - нужно смотреть, что именно. в принципе, и это решаемо :-))

(369) Да, мне тоже что то кажется сомнительным что проблема только в таблице констант

(367) в пятницу, конечно!

(372) ну вот и прекрасно. Самыми лучшими друзьями становятся искренние враги)

(370) ну вот с констом - канеш про регистр - тема интересная... я эту хреноту ток выносом во внешнюю SQL таблицу решал...

(375) Не переживайте я как нибудь перенесу ваше общество)

(370) Хех ... Ну достал из штанов, так достал )))

(373) "пятница" - это волшебное слово)) лучше в пятницу ничего не обновлять))

(370) да валюты, что еще может быть, ну и др периодические)).. ща я выкачу последнюю вводную))

(379) давай уже, все напряглись

база в шестерке?

(380) генерал сказал "да фигня какая, 30 минут можем и посидеть"))).... оптимизацию я им сделал))

(377) Есть базы и побольше. мерялись... у меня только 10 или 12 место в рейтинге :-) хотя и это тоже неплохо...

(376) вы мое - несомненно. а вот я вашей "дружбы" - побаиваюсь....

(384) думаю, поддержка таких баз вылетают в неимоверную копеечку для владельца..

(385) каких "таких"? и какая "поддержка"?
собственно, у нас сейчас больше поддержки требует УПП, нежели оперативная семерка.

(386) за 100 гиг... если у "вас" не станет "вас", то думаю у этой отстатыщ базы будут проблемы.. или не будут??

(387) эта база - уже архивная, сейчас фискальный учет в УПП.
оперативная база всего немного более 50. В принципе, обслуживания особого не требует - регламенты делаются на автомате. в текущем виде по моим оценкам, она будет способна переваривать до 140-150 тысяч в месяц. Чего не могу победить - непонятные тормоза после входа примерно 75-го пользователя...

некрофилы :)

респектабельная для админов база. при более 100 еще и 75 пользователей держать..
это чистый 1С, или приблуды от тойскл и тд и тп??

поправил чуток статью. разбил её на разделы 1)Советы по предварительной настройка программного окружения 2) Советы по оптимизации конфигурации 1С 7.7 DBF
---
1 раздел дописал парой пунктов. думаю там более дополнять нечем.
2 раздел дополню завтра или в пятницу

(391)  в пятницу ненадо..

(392) надо Федя надо! )

(392) еще же четверда вроде, не? :)

(390) оперативная база - всего 50.
прямые запросы - в основном отчеты, олап-кубы, всякие фишки типа Контроль выполнения заказов на уровне производства (148)(149)

(394) дак в пятницу я сам буду развлекаться)) а пока время сурьезных дел. Критику учитываю потихоньку и правлю статью

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

а чо стало то?? в чем проблемс?? миста все решит))

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

"Впрочем, последний релиз платформы 7.7 действительно выпущен в далеком 1999 году." - да латна, 7.70.027 вышла 18.12.2006... пестабол...

ЧЕТЫРЕЗЗЗЗЗЗТА

(399) такого человека называют ламер, ламерюга, ламо

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

Чайник - не понимает и не лезет
Ламер - не понимает, но лезет

(0) жесть, учебник русского языка срочно в руки

(401) когда "не знает - но понимает, что не знает" - это вполне нормальный человек. Возможно, просто "чайник". Пока "чайник". Но "плох тот чайник, который не мечтает стать самоваром"©
а вот когда не знает, но делает вид, что знает - это уже ламеризм.

(401),(404) сублимируйте мои друзья не стесняйтесь))) вечером почитаю ваши излияния)

Mikeware вы что то подрастеряли задор, не? Кричим ламер сильнее дружнее !!))) А ведь вы сами ламер....я это не хотел озвучивать на публике, но не удержусь чувствую...

Симптоматично то, что Mikeware, как он сам признался в каком то из постов - почти не оптимизировал файловые базы DBF. Смешно не правда ли?))))) На критику он горазд))) Тем более знает же теоретически какие способы оптимизации бывают. А вот какие из них действенны - ни в зуб ногой) Но критиковать мы любим

>>>> Правило №2:
1. Учитывая реалии современной жизни, а именно тот факт, что жизнь современной операционной системы без антивирусной программы немыслима – проводим тонкую настройку антивируса. Никогда не используйте в настройках исключений антивируса – исключение всего каталога с информационной базой 1С. Нужно задать исключения только для файлов с масками: $lk, *.cfg, *.mlg, *.ert, *.efd, *.log, *.upd, *.md, *.dbf, *.cdx, *.xml. Все остальные файлы в каталоге базы 1С антивирус должен сканировать. Тем самым вы "убьете двух зайцев": избежите “торможения” базы 1С из-за антивируса, и не позволите вирусам спокойно плодится в укромных подкаталогах каталога информационной базы 1С.

Автор ЛаМЕР!!!  :)
Ты еще забыл поставить в исключение базы SQL

(407) ... На критику он горазд))) ....  Но критиковать мы любим
тогда в чем смысл: "v7: Покритикуйте пжлста - "Взгляд в прошлое, или Способы оптимизации больших баз 7.7 "
может стоило: "Покритикуйте чутка, не жестко ... " или "Скажите мне, что в общем все клево, но ..."

(408) речь об оптимизации ДБФ-ных баз, при чем тут скуль? О_О

(410) А у Вас молоко убежало (опять сервер упал)

(410)В топку DBF, писать, дак все сразу :)

>>>> Еще одно узкое место платформы 1С 7.7 – это константы. Методологически разработчиками 1С для констант отводилась роль хранения часто используемой, но редко изменяющейся информации (поэтому, наверное, разработчики 1С сочли возможным объединение всех констант в одну таблицу). На практике же, программистами часто допускается ситуация, когда в константы часто пишется некая информация. Такая методика приводит к печальным последствиям.

Жаль, что не пятница "поэтому, наверное, разработчики 1С сочли возможным объединение всех констант в одну таблицу", не знаю чем они там думали, но не головой, разве что только головкой :)

+(412) Там же, ниже автор приводит много фраз "Блокировка", но текст не дает понятия, что делать или не делать. Полная лажа. :)

+ Никогда не было мысли, в константу писать все время ;)
...Автор еще забыл сказать про периодические реквизиты...

(411) не, серваки - в норме, енто домен заартачился, от и маюсь от безделься ... Боссы колдуют че-то с ним)

(413) бывает и нужно, когда счетчик сторонний организовать нужно - проще, чем справочник-пустышку юзать

вообще-то некоторые советы описаные в статье дадул улучшение только для локальной базы, а если она в виде сетевой шары то они приведут к УЖАСУ...

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

ихмо автор пишет статью исходя из личного опыта ОДНОГО КОНКРЕТНОГО СЛУЧАЯ !!!

>>> Правило №2:
1. Используйте константы по назначению. Недопустима, например, такая ситуация, когда при проведении каждого документа в некую константу записывается информация.

"Доктор, а я буду жить?" :)
Пункт бред

(415) Классический пример - МОД организовал счетчик создаваемых объектов в константе и создал очередь к 1sconst.
Нужно и проще - не значит, что нужно именно так.

(407) Да, с мелкими базами я практически не работал. Да, я знаю теорию, и мне не надо подбирать способы оптимизации методом тыка. а тем более - не надо тупо копипастить чужие методики. Собственно, и тут, на форуме, советов по оптимизации я давал людям гораздо больше, нежели вы. так что..

>>> Примечание: для платформы 1C 7.7 SQL существует более эффективный инструмент – “гибкие блокировки”, но в данной статье платформа 1C 7.7 SQL рассматриваться не будет.

Ой, нашёл про SQL и магические фразы "Гибкие блокировки", но что за этим стоит, автору невдомёк :)

(417) житьь-то будешь. Только ты попрофилируй обращение к константам... ужаснешься.

(413)(420) у меня сложилось ощущение, что он не понимает, зачем нужна блокировка журнала при проведении...

>>>> 1. Т.к. вы работаете с информационной базой DBF, приближающейся к предельному объему, не искушайте судьбу – записывайте документы не более 1 документа в секунду.

Все, я в ступаре, автор, подскажи, как пользователю записать за секунду больше одного документа. При том, что он его еще должен заполнить :)

...пояснять, надо, что речь об обработки группы документов, но порой проще без пауз записать 100 документов, нежели с паузами, епаться, пару суток :)

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

(422) да вообще снять все блокировки, изменить уровень изоляции и будет все летать!

вот это я понимаю ОПТИМИЗАЦИЯ !!!

:)

>>> Рекомендую иногда проверять размеры файлов 1sjourn.dbf и 1sjourn.cdx (журнал документов). В норме размер индексного файла должен быть примерно в 1,5 раза больше размера файла dbf. Если у вас соотношение размеров этих файлов кардинально другое (например индексный файл меньше файла dbf - чего быть никак не может) – то это один из признаков неисправности журнала документов.

Как правило, если это произошло, то странно что еще не выросли регистры или журнал проводок, а тем более журнал расчетов :)

Сколько не видел БД, так у них журнал документов не превышал 1 Гб :)

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

(426) приезжай дарагой - пакажу)

>>> ГЛАВНАЯ ПРОБЛЕМА БОЛЬШИХ БАЗ 1С 7.7 DBF:

Главная проблема больших БД, это неправильное решение поставленной и постановка задачи :)

Если БД, разрастается, а отрезать нельзя, а в статье пользователь не сказал об свертки БД, которую по правилам необходимо делать.

+ Итого:

Решение автора статьи разделить на два пункта, автору не помогло, тормоза так и остались :)

(425) Ну что ты мне-то рассказываешь? :-) я это и так знаю. И ты знаешь. И ты знаешь, что я знаю. И Я знаю, что ты знаешь. :-))))
вопрос в том - знает ли это пейсатель...

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

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

(432) "в споре рождается истина") а читал бы ветку внимательно - на начало пути не поставил бы
хотя согласен - я нуб - и енто клево)))

(433)Сверт DBF БД - это регламентная операция :)
Проводится раз в год, как правило...

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

(433) + Вертай... причем тут вообще, свертка БД, это не полное удаление, а чистое архивирование, т.е. Сворачиваемая БД остается доступна пользователям.

Если ты свернул, и удалил копии прошлых продаж, то это твои проблемы :)

(433) срок исковой давности - 3 года. за это же время все взаиморасчеты болжны быть либо произедены, либо списаны за счет резервов. да и товар, пролежавший 10 лет - проще и дешевле принять не по той цене, по которой отпускали, а по бросовой. Либо вообще списать в убыток.

(433)+ в справочнике уже более 5,000,000 элементов

А 5 000 000 элементов, это не предел ;)
Так то их намного больше ID поле содержит 36-тиричный формат числа, состоит из 6-ти символов.

И того максимум элементов 2 176 782 336

(435, 436) не проканает - это теоретически клево - на практике засекали - частое обращение к данным 5-10 давности.
на счет другого ПО - хотелось бы Оракле, да зуб не ймет

(439)Это все проблема разработчика Конфы, как написал, так и тормозит :)

(438) конечно не предел - я тесты гонял на 120,000,000 перед внедрением - пришлось графы из справочников создавать - чтобы увеличить скорость доступа - запросы тупо садились в ж...

(441)А это уже проблема того кто выбирает программное обеспечение.
Так то 1С 7.7 для малого бизнеса :)

+ Семечками торговать, в ларьке...

+ В Акцесе это дело не быстрее будет работать :)

+ К тому же, автор хотел трезвый взгляд, на его статью, то он её получил. :)
Статья отстой и мало, что может, ему еще писать и писать :)

(442) Наивный) Дали 1С 7.7 сказали нужно сделать - а как - не ипает - лишь бы работало
в принципе это тестовая наработка - никто не знал что понадобиться - скоро на 8.2 все перетянем

(445) рано ему еще писать. мозгов-то нет. Разве что статьи умных людей перерабатывать...

(445) не судяй жестока - чел обидиться) для локальных ДБФ-ок покатит, особенно для начинающих)

(446) волшебное слово "восьмееееерка" :-)))
зы. "такой большой, а сказки веришь"©

(447) известное правило

если ты сам не умеешь работать - иди учи людей как надо правильно работать!

большенство преподователей (в том числе и ХОРОШИХ) сами чистейшие ламеры

(449) не скажи, юзал, много чего клевого, но есть и ... как во всем, но запросы по сравнению с 7-кой - афигенные, правда ресурс жрет невменяемо - скуль-то встроенный

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

(448)

вот его рекомендации

3. Запускаем утилиту ConfigNT. Установливаем на закладке Memory Management галку в чекбоксе "Maximize Throughput for File Sharing". Тем самым мы дадим знать операционной системе сервера, что желаем, чтобы для использования файлов выделялся максимально доступный объем памяти. При данной настройке, операционная система не будет сбрасывать долго не используемые страницы оперативной памяти на диск, т.е. в виртуальную память.
4. Устанавливаем на той же закладке галку в чекбоксе "Use large system cache". Установка данной опции сообщит операционной системе сервера о том, что под кэширование дисков нужно выделить максимум оперативной памяти.
5. На закладке Other устанавливаем галку в чекбоксе "Update last access time on NTFS". Установка данной опции сообщит операционной системе сервера о том, что не следует обновлять время последнего доступа к файлам.


а теперь попробуй их выполнить для сервера 2000 и для 2008 (хотя-бы найди где эти опции), а про результат я вообще помолчу, ибо например большой кеш на на разных ОС по разному освобождает блокировки, тоесть вполне реально получить тормоза вместо ускорения

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

Народ а не лучшее ли средство оптимизации большой ДБФ-ной базы - переход на скуль?

(453) он тупо копипастит, не понимая смысла.

(455) он денег стоит. а в свете текущей лицензионной политики 1с - лучше на файлового снеговика...

(457) файловый снеговик - это чисто тестовая УГ, особенно с новыми типовыми рельсами.

снеговик - только трех звенный!

(457) в таком ракурсе - согласен: на скуль лучше не разоряться - сразу 8-ку брать ...

(455)Поверь, НЕТ :)
SQL - решает только проблему объема, но в минусе, уменьшается скорость.

+ Потом появляются потребности в скорости, но их решают только прямыми запросами к SQL :)

(459)Это верно. Если что, 8-ка может работать не только на SQL :)

(460,461) подробнее плиз ... на счет того что скулевая база тормзнутее аналогичной ДБФ-ной

(463) при прочих равных - значительно тормознее.

(460) SQL решает следующие проблеммы

1. Размер базы
2. Надежность базы
3. Не требуется переиндексации после кривого выхода (на больших базах может идти по часу и более)
4. SQL ный лог и возможность отката на любой моент времени
5. Возможность использования прямых запросов (в нормальном понимании это термина)
6. Возможность делать ХП и Тригеры
7. Возможность делать анализ скорости и блокировок средствами скуля

мало? могу еще накидать :)

(441) У Вас там поштучный учет изделий, наверное. Штампанули деталюшку - занесли новую строчку в номенклатурник. Еще бабульки какие-то наскипидаренные с ТСД на роликовых коньках носятся и в очередь к компу сливать информацию. Так на Вас никаких Ораклов не хватит. Готовый сценарий для фильма.
ЗЫ: шутю

(464) конкретизируй примерчиком, плиз
то что в скуле 2000 косяки есть - знаю, поэтому на 2005 перешли

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

(467) сравнения проводились еще году в 2004-2005. Ищи. мне лень.
а "косяк" 2000 с временными таблицами успешно обходится с 2004 года...

+(466) кроме того особо одаренные придумали схему - берут допустим 1000 изделий во время сезонных скидок (есть и 30-50%), потом по обычной цене - 100 изделий и пытаются возвратить все по-обычной, утрировано конечно, но единчное штрихкодирование изделий позволяет быстро принять товар по той цене, по которой он отпущен

(470) Увольняйся и едь в Москву. С чудаками на "м" работать - сам со временем чудаком станешь. Это заразно - по себе знаю.

(470) Вопросы возвратат тоовара по цене продажи и не больше чем было продано поднимались и решались не раз. Ваше решение самое изысканное.

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

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

+(474) да и оправдала она себя из-за больших объемов возвратов, потому как продукцию под реализацию отпускали, ну или когда на Выставки-ярмарки в Питер или Москву фуры отправляем, назад - 70% товара возвращается порой из которого. как правило 80% без упаковок.

(471) судя по некоторым его постам - ты несколько запоздал с предложением :-)
правда, насколько фатально - не знаю.

а вот в инете нашлось настоящее фото сикукана на работе: http://mimimi.on.ufanet.ru/freaks.gif

Приветствую всех! как тех кто симпатизировал мне, так и тех кто занимался открытым троллингом. Кстати, именно поэтому я не счел нужным комментировать все что было написано за время моего отсутствия))
---
Спасибо всем кто внес конструктивную критику. Благодаря вам статья действительно стала лучше. Обновленную версию выложил!

(478) вот согласись, что некоторые тут - непозитивные!

.. Вы думаете я страдаю манией величия? Я ей наслаждаюсь!

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

Так как особо не рублю в теме, то могу покритиковать только за опечатки:
"Советы по предварительной настройкА программного окружения"
))

(465)+ ты еще забыл упомянуть, при переходе на SQL, все что ты перечислил еще нужно допилить, дописать и отточить :)

+ По дефолту оно этого не умеет :)

+ Я про 1С

"Рекомендую безжалостно его удалять этот файл" ...

Да и вообще по тексту пунктуация страдает.

(478)Да без проблем... твоя статья отстой, жаль, что ты не внял нашим словам :)

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

имха канеш - автор полез еще больше в дебри, еще больше запутался и пппц...