справочником.

Краткое описание проблемы - есть справочник со 110 000 элементов - при подборе тормозит просто ужасно, причем даже если получаем простой список товаров - без остатков и проч.
Знаю по поиску - народ уже боролся с этой проблемой.
Только заканчивались ветки как то не очень.
Буду признателен за оказанную помощь..

Задача конечно же ускорение подбора из такого справочника..

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

ищи, где тормозит, что тебе ещё посоветовать...

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

Зы - если в справочнике 30 000 элементов - то все нормально..

вот такие вот и грабли..

Любопытно а что за спраочник если не секрет?

(5) Товары

у мну на ДБФ не тормозит

за база большая - 13 гигов mdf
(7) у меня тоже..

Я конечно понимаю что переход на dbf был бы решением но он к сожалению не возможен в кратчайшее время - нужно быстрое решение

+(8) у меня в смысле на локально компе..

работаете с базой по сети или терминал?

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

(10) терминал, однако скуль на другом сервере..

форма списка тоже тормозит? или только подбор?

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

(13) да, форма списка тоже сильно тормозит

что значит тормозит? поиск по первым буквам / с иерархией или без / простой скроллинг списка? ...

(16) поиск по первым буквам / с иерархией  / простой скроллинг списка

(17) Отладчиком мерял скорости?

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

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

Что такое прямые запросы применительно к 1с-вским запросам я знаю..

тут дело именно в ускорении непосредственно самого справочника

Мои соваеты.
1. Сервер базы и терминальный сервкер должны быть на высоте
2. между ними гигабитка.
3. базу индекстировать и шринковать каждый день
4. удалить  все ненужные товары
5. даже если есть воможность резануть (свернуть) базу.
6. постараться боьшенство реквизитов товара вывести в отдельные подчиненные справочники.
7. если есть возможность переходить на штрх коды лучше перейти на штрихкоды.

(19) Там кроме вычисления остатков есть еще фишка с выводом на ыорму всяких реквизитов влеженных через несколько точек. И подчиненных справочников. Копай в этом направлении

(22) милая моя, было бы все так просто..
Зы не подходит

хз, у нас спр. контров хде-то 50 000, вроде нормально без ++ работает
первое открытие тормозит, но потом кеширует и работает шустро на скуле

(24) Меня ни разу не путали с женщиной :)

(23) Тоже посмотрю, может есть чего в этом напрвалении
Зы - а у тебя какой справочник?

(26)
Милая моя обработочка. Ник смени..

1. Сервак и тот и тот на высоте
2. ест-нно
3. не получится - выгрузка/загрузка занимет от 2-3 дней
4. это и собираюьс
5. см 3
6. тоже есть такой вариант
7. уже есть - но чаще нужен подбор именно через артикул..

(25) Что нибудь делали такого? кста - только что вспомнил, что на скуле не вся память отжирается - может тут косяк..

Вот кстати мой коллега: Какие возможны пути улучшения работы базы?

(27) пункты 1 и 3 не стыкуются между собой

гы. у нас притормаживает подбор из справочника контрагентов..
правда там порядка 500000-600000 элементов.

тоесть если отключить иерархический списко и набирать первые символы наименования то порядка 1-5 секунд требуется для поиска по символу...

кстати все активно используемые обработки перевожу постепенно на 1с++

(27) Я много баз переводил с ДБФ на СКЛ. тормоза в справочниках в 99% случаев как раз в выводе вложенных реквизитов. представь листаешь ты справочник и каждый раз скл приходится обрабатывать сотни мелких запросов.

Я не обработочка а обработка. С этим ником живу уже 5 лет есть вариант ert. Но это не важно.   Убери по возможности периодические реквизит торов вообще или переведи на другой справочник.

+ еще вывод периодических реквизитов на форму. Это вообще пипец быстродействию

(19) Ну так и отвечай заказчику "задачу решить не могу, есть свои тонкости".

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

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

+(37) С ускорением его..

что-то я не пойму. Я что отжижни отстал? Чтоб индекисроватьь и шринковать базу нужно выгружать и загружать. У меня стоит ночное задание авоматом в скуле все делатся.

с заранее большой заточкой
(33) ert лучше подходит - верни назад :))))

(28) скульный сервак отдельно от терминальных, связь по гигабиту
вся оперативка отдана под скуль, модель симпл, max degree parallelism = 1, awe enabled
---
кстати, а сколько длина наименования в справочнике?

(39) Так, с этого поподробнее - что там делается на mssql (стоит 2000-й 4 сервиспак)

(41) 50 длинна наименование, 50 дилнна артикул
(41) записал - в пн спрошу админа..

(43) думаю mishaPH прав, про периодику и реквизиты через точку

(39) ау. что там нужно делать? (я со скулем нечасто работал)
прошу ответить..

(44) Это я гляну обязательно

(42) 1. Простая команда переиндексации скульной базы 1С 2. Команда шринк базы тоже обычная я не на работе кка ззвучит не помню  аа вот _1sp_DBReindex а шринк не помню. часто я просто руками делаю по утрам если пришел раншье на работу при усовии если я замечу что забыл занаие включить

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

(47) я к тебе в пн стукну с твоего позволения

а размер mdf у тебя какой? у меня 13 гиктар - как быстро сделает не можешь сказать?

(49) без проблем, в скуль агенте делаешь задание и ставишь на ночь допустим в 5 00 По перенидексации вот  всего лишь одна строчка _1sp_DBReindex

а размер базы вообще никакой роли не играет.

ок, спасибо..

4 гегтара  перенидексация 8 -11 минут шринк 5-7 минут ну от сервака заисит конечно

(54) ок, в пн стукну.. еще раз спасибо :)

(52) как не играет роль? играет еще как. время перендексации у меня растет. Уже наблюдаю давно. гоигова база за пару минут, база в 2-3 гиг 4-7 минут  итп. Ну от строктуры данных тоже зависит ясное дело.

(0) начни с банального Select From

(56) Я никогда переиндексаций и шринков не делал на базах. Смысл сих действий не понятен. лог файл никогда не рос при симпл модели. переиндексацию делать вообще нафига?

(58) Для укорения выборок.

(59) Переиндексация?

(60 угу

Переходите на восьмерку. Там это реализовано (С).

(62) у вас если в машине зеркало заднего вида грязным стало вы машину меняете ?

(54) у меня реиндексация около двух часов длится, МДФ - 10 гиг...

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

(58) на счте того что шринк не ускоряет работу базы согласен но частая переиндексация восстанавливает рыхлые индексы что дает росту скрости работы базы. Конечно рост может быть мизерной.
(0) Вот команда шринка если интересно. Кстати ее автоматом можно сгенерть

DBCC SHRINKDATABASE (N'имябазы', 0)

(0) в качестве формы подбора используй табличное поле и прямые запросы из 1С++.
Для быстрого выбора номенклатуры в документах я бы порекомендовал поля быстрого выбора от Олега Садовникова (http://www.rikcenter.ru/download/Demo_RiK.rar - демо-конфа, в которой все это реализовано)

(67) ты это юзал?
(66) конечно интересно :)

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

что так часто удаляете/добавляете элементы в данный спарвочник аб ы шринком лечить?

(68) да, юзал, иначе бы не предлагал. Форму для справочника немного под себя переделал (морду лица, в основном). Быстрый выбор практически в первозданном виде затащил в конфу. Активно использую при выборе фильтров в отчетах и при выборе реквизитов в документах (причем, поиск не только по наименованию, но и по артикулу/коду, что в некоторых ситуациях на порядок быстрее)

(70) Вот такие вот траблы - пока все что смотрел - было боле менее, в форме переод. рекв. не используется, расчет остатков вроде сильно тормозить не должен
(71) Как раз поиск по артикулу и интересует..

(69) Я это тоже уже видел что ты видел. А кто это делал? ты сам?

(71) Посмотрю, авось поможет..

(73) неа.

Конечно можно сделать и нестандартный ход - сам уже думал на шарпе переписать - но может есть стандартные входы/выходы..

(0) а зачем тебе вообще форма списка?
(73) для регистров делал. На C#. Быстро.

(77) Манагерам очень удобно товар подбирать

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

(79) Дык неужели сам список так тормозить может - у нас 15000 - все летает, правда и базы ДБФ..

(80) ну, во-первых, всё-таки есть разница - 15К или 110К..
А список - да. Может тормозить.
На самом деле - форма списка при грамотной работе манагеров ВООБЩЕ, как таковая, не нужна. Это просто привычка, которой мы привыкли потакать. У тебя сейчас есть вариант с неё соскочить ;)

(81) Возможно и привычка - но всё же 110 тыс. элементов это уже смертельно по твоему?

(82) по-моему, это просто много. Смертельно или нет - я не знаю: не было у меня столько.

1.А что говорит товарищ профайлер?
2.включи на сервере автостатистику
3.Как вариант - закрепи таблицу с справочником в памяти сервера....

(84) 3-й вариант можно в студию? заранее благодарен.
да, кстати как заставить скуль видеть всю оперативу?

(85) 1. DBCC PINTABLE
2."всю оперативу" - это сколько и какой сервер стоит?

(86)
1) ок, спасибо - посмотрю..
2) 2003 винда, скуль 2000 сп 4,
имеется 8 гигов, отжирает только 4

пля. скуль 2000 сп 4 - стандарт или ентерпрайз?

(87) С самого начала если бы дал полную картину может умные ребята ответили  бы и предложили  бы более приемлемые варианты применительно к вашему случаю.
Итак озвучь народу еще раз если не трудно 1.Точные характеристики сервера базы. Разделена ли база и система на разные диски? А лог файл базы где?
2. Точные характеориститки сервера терминалов
3. объем базы
4. количество юзеров? есть ли юзеры вне терминала?
5. какая конфа вообще
6. за какой период база

(97) Твои вопросы - вторичны....

Тьфу, (90) - к (89)

(88) энтерпрайз

(89) Точные хар-ки серв.:

Сервер базы данных
ОС: Win2003Srv, MS SQL (2000 sp4)
Проц.: 2*Xeon3000
ОЗУ: 8Гб, исп. только половина ~4Гб
С дисковой подсистемой SCSI:
RAID 2*1.0 Система
RAID 4*1.0 Массив
RAID 4*1.0 Массив
Нагрузка до 90 пользователей
Преимущественно база данных торговли и производства.

3) 13 Гб
4) порядка 60-ти, таких нет
5) очень переделанная тис
6) 8 лет :))

(93) предложу банально посмотреть http://www.infostart.ru/projects/2831/

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

(93) первым делом сделай так, чтобы съедало более 4х гиг.

http://www.itland.ru/forum/index.php?showtopic=9353

но вообще 100% трабл из-за вычислений на форме.

(92) Если энтерпрайз - должен хавать всю память. Исключение - до какой-то конкретно сборки сервиспака видит ровно половину имеющейся памяти - есть статья в КБ мелкомягких. На память не помню, поищи...
---
Профайлером пытал?

(98) даже в ентерпрайзе надо включать AWE по любому. иначе не использует всю.

Если сожрал 4 - АВЕ уже включено....

(100) кстати да. видимо ограничение стоит на 4 гига.

(0) профайлером запросы на сервер при подборе отследи и нам дай.

(0) поиск по первым буквам - заменить на поиск по реквизиту через кнопку с горячей клавишей с вводом значения в диалоге/в реквизите формы, - работает точно быстрее. (такой же поиск по первым буквам - шаманить надо).
Если причина в размере справочника, по ускорению скроллинга - может, сделать типа справочника-прайса, (одно поле - ссылка на товары) + 1-2 поля для поиска? Правда, придется его обновлять.

(102) До сиквельного профайлера надо сначала попытать штатный....
(103) У Садовникова есть решение

+ (103) Если дело не в размере, - это просто проверить: уменьши в копии кол-во записей в товарах (Удалить(1)) - быстрее будет работать?

ок, спасибо!

(97)+100
200 тыс. элементов - тормозов нет.
- в списке нет никаких доп полей кроме непериодических реквизитов
- все вычисляемые поля только для текущего элемента "унизу"

(107)+
для реквизитов поиска: отбор+сортировка

(107) ок - буду иметь ввиду..

150 тыс., ТиС спр. номенклатуры, летает... SQL

Лично я бы начал с урезанрия базы. Обычно руководсву для анализа и сравнения хватает даные за последние 2-3 года. По возможности урезал бы базу до начала 9 года или хотя бы отсавил бы 3 последних года. После этого удадлил бы неиспользуемые товары. ДУмаю при урезании базы кол-во елементов может существенно сократиться. От 20-60% запрсто.

(111) Это я тоже укажу руководству. 8 лет в 1-й базе это много..

Еще раз всем спасибо за участие
(110) Вычисляемые поля есть?

(111) Плохо "ДУмаешь". Размер базы тут влияет только косвенно

(113) Что сказал товарищ профайлер? :-)

(114) Это позволит "убить" 20% точно номенклатуры..

(113) все вычисляемые поля в инф строку и только для 1 элемента.
И то. я в ТЗ запихивал все вычисляемые параметры и реквизиты. И даже при повторном позиционировании на элемент уже ничего не вычислялось

(116) Ну, убъешь 20%, и что? :-)

(115) Не смотрел я его пока - база в другом месте, я как сторонний наблюдатель - пришел, посмотрел, сделал и обратно к себе. Завтра вот набег делать буду..

(111) фигня все это, у меня была база на 8ке которая на 20тыс ном тормозила, а была база > 200тыс номенкл (тис) которая работала.

7.7 нормально тянет примерно до 500тыс в справочнике, дальше проблеммы с памятью у клиентов начинаются

(117) в смыслеты ты данные кэшируешь что-ли?

(120) Хм.. уже яснее. Значит все таки возможно :)

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

(121) ну можно сказать и так.
А то заходит оператор в справочник и начинает лазить туда-сюда что-то подбирая.
Нафига системе 2 раза что-то считать?
Позиционирование на элементе - поиск в ТЗ элемента. Если нет то рассчет и в ТЗ все что посчитал и периодические реквизиты. Если есть то и из ТЗ берем
Затем на форму вывел.

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

+ 124 и не только рассчетные данные, но и все реквизиты обобенно сильно вложенные через точку и далее.
Из ТЗ и памяти клиента по любому будет быстрее выборка чем из базы с сервера

(117) Для вычисления вычисляемых параметров можно и сиквельные функции написать :-)

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

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

(128)стандартная клюшечная периодика - зло!

(97) если в дбф-е не тормозит  - см. (8), а тормозит в скуле, то причем тут вычисления на форме? Мож я просто чего-то не понимаю?

(129) Ну, сиквел неплохо кэширует такие вещи...

(114) Не только так думаю я, так и подымал производительность работы базы в случае когда другие возможности исчерпаны ну такие как:
1. апгрейд железа
2. перевод на терминалы
3. создание уриб чтоб уменьшить нагрузку на количество юзеров.
4. оптимизация кода

(126) я делал прикольную вещь:

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

(134) Да, это я тоже уже прочитал (где то поиском нашел) - спасибки за идею, думаю поможет!
(131) у меня локально не тормозит - но у меня не вся база

(133) железо вроде неплохое, терминал уже есть. щас код оптимазю и сам скуль

(130) ну вот и приходится обходить.
(131) Дело в том, что все вычисления, выборки периодики и вложенные на скл отрабатываются запросиками. много мелких .вот и тормоза.
(132) да но сиквел сервер еще должен отработать запрос, передать по сети. и т.д.
Пусть клиент работает. СКЛ серверу есть чем занятся и без этого

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

еще раз благодарен. Как тесты будут - отпишусь

(131) если локально не тормозит, то 99% что поможет мой скрипт

(134) да тут путей творчества много.

(140) Буду все по возможности делать.. :)

(137)
1.Увы. Не захотели, уррроды, сделать 7.8 :-(((
2. Особенно если паралеллизм включен
3. Надо смотреть загрузку сервера.

(142) в том и грабли что вроде как сервак не очень загружен

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

Выше не читал, если повторюсь извиняйте

Год назад столкнулся с похожей проблемой (обсуждалось тут Медленно работает подбор номенклатуры
Номенклатуры набралось на 150т., база на SQL.
Создал свою обработку подбора, список номенклатуры
выводил в ТЗ и только ту, что была на остатках (т.к.
быстрый подбор был необходим для реализации товара)

(142) Если бы исправили все что хотели и все внешние компоненты включили . то нафига была бы 8ка.

(145) А ка к у тебя в ТЗ попадает новые элементы спр во время работы?

Используйте прямые запросы + табличное поле из 1С++ и никакой ТЗ не надо...

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

По-поводу периодики: давно отказался от типового хранения периодики в _1SConst. Там у меня сейчас хранятся только значения констант. Вся периодика лежит в отдельных таблицах, что на порядок ускоряет получение периодических реквизитов.

З.Ы. (146) Вот мне 8-ка и не нужна :)

(148)Хм. Если у тебя получаются данные "простых типов", то какой нафиг "вывод через несколько точек"???

(148) пряме запросы и 1С++ не всегда возможно использовать да и не все это могут. Но оптимизировать стандартными средствами применив кэширование и выдавая инфу только по нужному элементу - это вполне возможно.

(149) А кто мешает в запросе использовать несколько джоинов, выстроенных друг за другом? И в итоге показывать наименование последнего заджоинного справочника в цепочке.

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

(150) я вообще не понимаю, как можно работать быстро в 1С при 13 Гб базы без использования прямых запросов... тут достаточно сформировать отчет на прямых запросах и сравнить время выполнения с типовым... экономия времени сотрудников существенна.

(151) Ну это же не "через несколько точек" :-)

(153) а я не понимаю зачем нужна база в 13 гиг ???

если база большая надо структуру методанных оптимизировать а не запросы, надо бороться с пречиной а не со следствием! лично я не разу не использовал 1с++ и прямые запросы, все делал штатно.

не обижайся, но это похоже на спор 12 летних, "а мне в думе дали такую пушку, что мочу всех одним кликом". Я не против прямых запросов, я за то, что-бы ПЫТАТСЯ обойтись стандартными методами, и только когда уже ничего не помогло - стрелять из пушки.

(154) Ну давай обзовем "через несколько джоинов". Главное, что результат тот же, тока существенно быстрее, так как нет выполнения на каждую запись результата цепочки вызовов ХП _1sp_SCххх_ByID.

(152) поиск по ТЗ тоже вещь не быстрая, хоть и в данный момент быстрее чем справочник - но я думаю справочник нужно потимазить

пооптимизировать для начала..

(153) База за 3 года - 22Г. Излишки обрезаются.... А хранить менее 3 лет (в основной базе) - некошерно :-) Хотя можно выделить в "отчетный узел", но...

(155)
1. У меня документооборот небольшой, но с начала года база 4,5 Гб. Так что к концу года до 9-10 Гб вырастет. База с 2004 по 2008 год - 23 Гб.

2. Я согласен, что нужно бороться именно с причиной... а причиной в данном случае является то, что для СКЛ версии 1С принципы работы с данными как для ДБФ используются. Ради интереса посмотри что творится в профайлере при работе со списком справочника или при выводе отчета. Вся инфа выбирается курсором + для каждой записи выпоняется ХП для получения агрегатного типа данных.

3. Я не обижаюсь, но зачем трудиться, чтобы сократить время выполнения отчета/проведения документа на 10%, когда за то же время можно написать прямой запрос, который сократит это время на 90% (иногда и больше)

(160)

2. я знаю как все это работает физически :) просто в 90% случаев можно обойтись штаными методами

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

(161) вот и пытаюсь сделать пока штатными :)

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

(163) Я тоже сторонник штатных методов. Хотя снимаю шляпу над создателем нештатных примочек к 1с77. Ну и тем кто освоил нештатные методы и применяет в жизни респкет и уважуха. Сам никогда не использовал но наслышан.

(164) граница между "штатным" и "нештатным" весьма условна....

(165) Все что фирма 1 С приняло  и документиовано хоть как-то есть штатно

(0) А разбить по группам(кодам, признакам) никак? Я от SQL иду - первоначальный вариант нечто вроде "select ... from ...", а "по группам" будет "select ... from ... where 'группа = ...'". Побыстрей, все-таки. Как-то сам спасался таким вот.

во всей ветке меня насторожила фраза расчет "остатков вроде сильно тормозить не должен" в (72).

(0) Остатки присутствуют на форме? в списке на каждый элемент? если да - то покажи код функции, которая считает остаток.

(168) Сейчас к сожалению нет возможности показать - могу только от себя добавить - там все ок

большей частью

(166) Криворуких пейсателей конфигураций в 1с тоже много. Что, их перлы брать как стандарт? Опять же, не помню, чтоб "метаданные" были документированы настолько, насколько они используются в типовых (пришлось найти ЖКК и убедиться).  Однако в коде типовых- используются.
И наоборот, доступ к данным минуя механизмы 1с не использует недокументированных возможностей. А подключение этих механизмов - с помощью документированной и официальной "технологии внешних компонент".
так что граница ооочень условна

(155) А что, 13 гигов - это много? Если, конечно, не ларек автоматизирован.
Вот пример - 2.5 года работы - чуть больше 150 гигов.

(172) Да фигня это размер скл базы. тем более 13 гиг.
(168) быстро работает на дбф получение остатков на ТА. На СКЛ он медленее, но в 99% случаев тормоза не остатки - а безконтрольный и необоснованный вывод на форму в таблицы вложенных реквизитов и главное периодических.
На дбф не тормозит. а в СКЛ попа да еще когда много пользователей ибо сервер захлебывается на мелких запросах курсорами причем.

Использование прямых запросов дает ++ как правило если народ работает на клиентах а не на терминале. тут практически разница только на сложных запросах выборках по нескольким регистрам и с завернутыми группировками да и то на очень больших базах.
А долбить прямыми запросами выборки реквизитов и периодики в случае автора не будет быстрее практически

(173) О чем и речь. В первую очередь пытать профайлера.

(172) как такие объемы бэкапите? только дифференцальным бэкапом? а если полным, то сколько времени он делается?

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

(0) У меня справочник контрагенты около 100000, договора несколько сотен тысяч. Нашел решение http://www.softpoint.ru/article_id55.htm
Написано еще для радуги, но переделать для 1с++ 15 минут.
Поиск контрагента 5 секунд, договора до 20 секунд

+(177)
вот уже переделанный код
Процедура НайтиКонтрагента()
   Перем Запрос, ТекстЗапроса, СписокВыбора;
   Перем ВнутрИД, ТекВыбор;
   Перем ВремСтрокаПоиска;
   
   рс = СоздатьОбъект("ODBCRecordset");
   
   ВремСтрокаПоиска="%"+СокрЛП(СтрокаПоиска)+"%";
   ВремСтрокаПоиска=СтрЗаменить(ВремСтрокаПоиска," ","%");
   СписокВыбора=СоздатьОбъект("СписокЗначений");
   Если ПустаяСтрока(СтрокаПоиска)=0 Тогда
       
       ТекстЗапроса = "-- qryMaker:Отчет1.2009.02.13.16.20.31
       |SELECT Контрагенты.ID [Ссылка $Справочник.Контрагенты]
       |    , Контрагенты.ISMARK ПометкаУдаления
       |    , Контрагенты.DESCR Наименование
       |FROM $Справочник.Контрагенты AS Контрагенты With (NOLOCK)
       | WHERE (RTRIM(DESCR) LIKE '"+ВремСтрокаПоиска+"') AND Контрагенты.ISMARK = 0
       |ORDER BY Контрагенты.DESCR";
       тз = рс.ВыполнитьИнструкцию(ТекстЗапроса);
       тз.ВыбратьСтроки();
       Пока тз.ПолучитьСтроку() >0 Цикл
           ТекЗнач=тз.Ссылка;
           Если ТекЗнач.ЭтоГруппа()=0 Тогда
               СписокВыбора.ДобавитьЗначение(ТекЗнач);
           КонецЕсли;
       КонецЦикла;
       //****************************************************************************
       Если СписокВыбора.РазмерСписка()>0 Тогда
           Если СписокВыбора.ВыбратьЗначение(ТекВыбор,,,,1)=1 Тогда
               АктивизироватьОбъект(ТекВыбор);
           КонецЕсли;
       КонецЕсли;
   КонецЕсли;
КонецПроцедуры

(178)
1. Зачем выводить Контрагенты.ISMARK ПометкаУдаления, если в условии стоит Контрагенты.ISMARK = 0?
2. Зачем делать RTRIM(DESCR)?
3. Зачем выводить [Ссылка $Справочник.Контрагенты] и Контрагенты.DESCR Наименование?
4. Зачем на клиенте проверять Если ТекЗнач.ЭтоГруппа()=0 Тогда, если это можно сделать в запросе?
5. Зачем результат запроса вовзращается в ТЗ, если можно сразу в список значений?
Ну как-то так...

(179) Гораздо интереснее кто такой qryMaker, раз поволяет такие запросы клепать.

(180)А... я кажись понял. Странно.

(180) А кто такой qryMaker?

(182) Консоль запросов для 1с++
Я ею тоже пользуюсь. Хотя потом все равно руками что-то правлю.

(180),(182) Консоль запросов И.Берездецкого...

интересно что там у автора?

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

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

(0) Как вариант сразу не переделывая на 1С++:
1 - Убрать лишние колонки, оставить наименование и код.
2 - Убрать все функции с формы
3 - Убрать все колонки с вызовом функций.

Протестировать, если помогло - искать в какой функции тормозит.

(187) @запретить оключать иерархию@ - не прет по определению
а есть у тебя варианты подобных реализаций? и опыт?

(188) Это тоже пытаюсь сделать

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

(189) "не прет по определению" - почему?

(189)
Спрашивай на http://www.1cpp.ru/forum, у людей есть уже готовые разработки для справочников, журналов документов, ТЧ документов и тп. Причем со всей обвязкой - контекстными меню, панелью команд и тп.

(193) Ага, есть :)

(193) Да все это замечательно, вот только всетаки сначала надо ресурс оптимизации кода 1С исчерпать а потом на 1С++ идти

(191) ок
(192) при подборе очнь важно в кратчайщие сроки подобрать из всего списка заданные позиции
(193) спасибо за ссылку
(195) сначал думаю скуль, потом стандартные, потом уже с++

(0) у меня справочник номенклатура 2 088 322 элементов все летает. SQL+терминал. Убрал все итоги из списка. В списке только код и наименование.

(197)
Болид формулы 1 тоже быстро ездит, однако картошку возить на нем неудобно.

(197) афигеть..

А сервак какой?

DGorgoN вчера скрипт отработал? чего показал?

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

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

(202) Вот как раз самое время!

(198) каждому свое. гдето прибавили гдето убавили - это назвывается кастомизация системы согласно требованиям.

(199) двухголовый ксеон 3.4, ОЗУ 4 гига, Винда 2003 server + SP2, SCSI вроде как RAID5 - точно не помню у айтишников надо уточнять.

В терминале одновременно до 40 человек. Конечно не всегда бывает все гладко, но большая часть времени юзеры работают без особых тормозов

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

(205) Вот просто интересно - а что ты в скуле собрался оптимизировать?

(206) Хотя бы разнести журнал транзакций и пачтики поставить, что-бы он 8 метров хавал заместо 4-х

это как минимум..

Ну и еще по результатом теста счетчиков

Не читал ветку, много б у к а ф.
Советовали уже при получении данных делать невидимым табличное поле, а потом Видимость = 1?

(210) А как определить начало момента получения данных и конец момента получения данных?

особенно при подборе и когда вычисляемое поле все же есть?

(205) да ничего особенного не делал. А че там можно сделать?

Форма списка и форма списка для подбора одинаково томозят?

(211) а хз, я не баловался этим, нужды не было. Спроси улю, он такое советовал...

(213) Да, причем даже если остатки не получаются - сам подбор даже без обычного списка тормозит :)
Грешу на то, что в самом справочнике, хоть и не отображаются, но присутсвуют 90 реквизитов, 8 из которых переодических.

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

(212) попробуй сделай свою форму списка для подбора включи туда только код и наименование. Если скорость будет устраивать, то пошагово прикручивай дополнительные фишки и все время проверяй как меняется скорость работы после добавления какой либо фичи. В общем ищи эксперементальным путем.

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

(215)
Правильно грешишь.
1Ска все реквизиты тащит с сервера.

(217) ок, но это после оптимизации всего скуля - возможно там оооооочень много косяков

(219) даже если они не отображаются?

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

(221) 1Ска все реквизиты тащит с сервера даже если они не отображаются? или нет?
переодики вроде нет, но там колонки скрываются - т.е. их видимость = 0, но на форме они присутсвуют..

(223) Если скрыты, но присутствуют - все равно вычисляются.

(224) ух - косяк :) :) :) :) :).. ес!

седня же вечером иду кастрировать..

(223)
Даже если колонок с реквизитами нет.
Когда в коде первый раз обращаешься к какому-либо реквизиту элемента справочника, 1С вызывает процедуру на сервере XXX_byID, которая тащит ВСЕ реквизиты этого элемента.

(227) уже веселее - значит таки справочник приедтся делать :(

Ну что-ж, спасибо за подсказку. Теперь я уже уверен в своих действиях. итакс:

1) заводим новый справочник - аналог старого но с кастомизацией..
2) анализируем скуль и оптимизируем его..

(227) Реквизиты тащит. Но при этом периодику вроде не вычисляет. (обращений к _1sconst) нету. только что попробовал. Или я слепой?

(230) В любом случае 90 реквизитов? :) - из них при подборе и анализе треется макс. 6

требуется

(227)
За периодику точно не скажу, возможно зависит от "ИспользоватьДату".

(229) Сделай справочник на табличном поле и не мучайся.

(231)
Вот ТП в 1С++ как-раз позволит тащить только нужное.

(234) Если на обычном - то тормозит, съедает буквы и куча других недостатков - попробую все же помучатся..

(233) При ИспользоватьДату() - да.

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

(231) фигасе. Все кроме Кода, наименования, и все что надо для подбора в справочник доп реквизитов подчиненный и вызывать только по необходимости

(236) "Если на обычном - то тормозит, съедает буквы и куча других недостатков" - поясни?

90 реквизитов? да что можно запихнуть в 90 реквизитов в номенклатуре?

(241) Ну как же! Прайс-листы для каждого контрагента :)

(240) если обычная тз на форме - то при посике пользоватся не удобно + все же есть тормоза при наборе - первые 3 символа долго ищутся - потом уже быстрее (при наборе артикула)

(241) Не спрашивай,
система предстала передомной ас из
ибится сердце перестало

(244) Да я верю. но мне интересно что у номенклатуры за 90 реквизитов

(243) А где я писал про таблицу значений?

С помощью рифоплета еплохо получается: OFF: Авторифма к 1С

Система предстала передомной ас из
Ибится сердце перестало
Получил я не сразу проклятый сурприз
И этот бред пишу устало

(246) я тебя позже понял..

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

(249) понятно. кто-то себе хотел облегчить жизнь не загоняясь на всякие подчиненные справочники.

Томно работая со скулем
Я в вечность получил билет
На ужин булок я возьму
А может, даже на обед

(251) даешь хокку.

Я буду бегло урезать
Все то что до меня написано
Скопилось столько, что немыслимо
Все это урезать

(250) таким грешат бывшие бухи перешедшие в проги и еще саперы (как не странно звучит), видел просто неперенное количество раз подобные системы.

(250) можно подумать, что с подчиненными справочниками тормозов не будет...

Что то не то:

Я буду бегло сокращать
Все то что до меня написано
Скопилось столько, что немыслимо
Все это урезать

(255) откуда? как влияет кол-во подчиненных справочников на работу основного?
Если только ты конечно не захочишь все реквизиты вытащить на форму списка.

(254) Где-то слышал про 150 реквизитов у номенклатуры в САПе

Объятый буйной радостью
Гастрит мой верный друг
Настолько полон сладостью
И мы продолжим путь

(258) думаю там все таки более сносная оптимизация по получению этого всего барахла из скуля

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

(248) я тут в последнее время лазил (в связи с переносами) в Навижене и Сапе (в физических таб.)

теперь я знаю, что 1с-овцы НОРМАЛЬНЫЕ ПРОГРАММИСТЫ с ПРЯМЫМИ РУКАМИ...

Заставим клюшки мы летать
Пределая к ним крылья
Ее уже не удержать
Там наверху - стихия

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

З.Ы. и еще раз (для закрепления): автор, не пиши стихи, а кури маны по Прямым запросам и ТП (табличное поле) из 1С++

(262) гы гы гы,
Еще более тупые и жадные программисты из САП :)) (зы - прошу воспринимать как юмор)

(258) Возможно в САПе это не напрягает систему (те там нет задач, когда тащатся все реквизиты баз разбору), в 1С - напрягает.
В любом случае, стоит помнить, что каждый раз, когда ты первый раз обращаешься через точку к реквизиту справочника, 1С тянет весь набор данных (хотя возможно есть кэширование для нескольких элементов), те справочник с 90 реквизитами наверняка является тормозом не только в форме списка. Это надо в консерватории править - разносить логически связанные реквизиты в подчиненные справочники.

+(266)
Либо использовать прямые запросы (они не зря так называются), чтобы брать только то, что нужно.

(266) угу

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

(269) буду иметь ввиду

(270) по чему я тебя и просил формат таблицы, и там имеет значение даже порядок следования реквизитов.

(271) к часу будет результат тестов.. ждус.. :)

(0) Есть опыт оптимизации таких справочников в 7.7

1. Осознать, что штатный поиск по колонке лучше не использовать (тормоз).
2. Дописать поиск по нужным реквизитам через прямые запросы (обычно делаю сразу поиск по подстроке).
3. Все вычисляемые колонки рассчитываются при выборе родителя.
4. При снятой иерархии вычисляемые колонки не рассчитывать вообще.

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

(274) +1

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

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

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

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

(277) про подчиненные справочники я из (250) вычитал... Сам такими вещами не занимаюсь. Мне проще типовую кривизну работы заменить на прямые запросы.

(278) Ты думаешь неправильно

Эту создавшуюся ситуацию меня как раз и попросили исправить - вот и сижу и анализирую, и исправляю

(276) А что типа ты дашь гарантию, что все реквизиты у всех элементов всегда заполненны? а тамлица то особенно ДБФ она места занимает. Кроме того когда ты у товара цену пытаешься вызвать (реквизит через ..)Нафига все 90 оставшиеся читать?
Подчиненные справочники выбираются легко и быстро ибо индексированы к элементам

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

архитекруры = архитектуры

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

блин, еще час ждать - ё

(285) ну? 13-00 уже было

(287) Адним понимаешли не на месте. будет через час, да и и подозреваю что все через 2.
Пошел курить от злости..

(288) главное, что-бы они окошко результатов не прибили :)

Была статья про быстрые справочники.
Можно поиском поискать, так вот - в 1С ШТАТНО некоректно идет обращение к ТекущийЭлемент() и т.п. Используя ВК 1cpp, даже не используя ее мощный потенциал, автоматически ускаряется работа 1С. А именно быстрые справочники становятся, может этого будет достаточно?
Т.е. просто загружать при старте 1с++

(290) может ты путаешь с оптимизацией выборки ТЗ а не справочников? есть такая фишка которая в 1С++ была включена.

(289) ага, я тогда буду рвать и метать

(290) в любом случае 90 реквизитов уже не дело

(291) именно про справочники была статья
И еще на счет ТЗ. Если использовать ИТЗ из 1с++, то при большом объеме данных она намного выгрывает по скорости

(294) ссылка есть на это? а то я это только про ТЗ читал. Про справочники никогда не попадалось. ты видимо всетаки путаешь. Оптимизировали именно ТЗ и Выбрать, получитьСтроку() ибо штатная 1С при поиске и выборке тупо перебирала все ТЗ помоему пока не натыкалась на нужную строку даже по ПолучитьПо Номеру

(295) ищу...

(295) Нашел у себя в txt

       Быстрые (легкие) справочники и документы ...

Прочитав статью Вы научитесь более быстро извлекать и записывать данные из справочников ( документов ),
что позволит при необходимости значительно оптимизировать решение Ваших задач.
Вы будете лучше понимать работу стандартных методов объекта Справочник ПолучитьЭлемент(), НайтиЭлемент(), Записать().

       Пролог

Может для кого то все написаное ниже давно извесно но тем не менее.
Изначально было желание написать Класс конкретного справочника. При этом предполагалось что
работать можно будет привычным способом, а скорость обращения значительно возрастет.
Простейший Класс ( класс СправочникКлиенты = Кл1.ert : Справочник.Клиенты ) был создан.
Но со скоростью все оказалось немного не так.


   Быстрые Справочники.


Кратко о базе. В базе есть справочник Клиенты.
Этот справочник содержит 61922 клиента. Элемент справочника Клиенты содержит 57 реквизитов,
один из них периодический с очень редким изменением.
1с база  - sql. В момент всех тестов с 1с базой работал только я один, но эта база
установлена на рабочем сервере где круться довольно интенсивно еще несколько 1с sql баз.
Замер скорости делался днем когда сервер был нагружен другими sql базами и вечером
когда не было никакой нагрузки дополнительной на sql сервер.
1cpp версии 2.0.2.2 Параметры Оптимизация включена.

Сначала я написал класс СправочникКлиенты и очень удивился почему этот класс работает очень медленно.
Вроде бы  этот класс создан на основании прямого запроса и должен работать с той же скоростью что и прямой запрос.
Путем эксперементов выяснил что основной тормоз состовляет Спр.НайтиЭлемент().
Проверив в профайлере sql убедился что  метод НайтиЭлемент() генерит sql код
select *  from sc46 и причем столько раз сколько у нас элементов в справочнике.
После этого полученные реквизиты копируются во внутренний объект Спр.ТекущийЭлемент().
Сделано так из-за универсальности потому что заранее неизвестно какие и когда реквизиты справочника будут
использоваться и при позиционировании на новое значение с  сервера беруться все реквизиты.
А теперь представьте что в конкретной выборке справочника Клиенты нам от всего справочника клиенты
нужен только один реквизит ИНН. Мы( конкретный программист) то это знаем, а 1с приложение нет и получается
понапрасну перемалывается зря куча никому не нужной информации - причем это происходит и на sql сервере
и на компьютере пользователя и этот "мусор" передается по сети сначала с сервера на компьютер пользователя,
затем в обратном направлении.

С записью элементов имеем аналогичную картину.
Все это видно из простейшего примера.
Рассмотрим пример :

/* Строка 1 */       Спр1 = СоздатьОбъект("Справочник.Клиенты");                      
/* Строка 2 */       Спр1.ВыбратьЭлементы();
/* Строка 3 */       Пока Спр1.ПолучитьЭлемент() = 1 Цикл
/* Строка 4 */          Если Спр1.ЭтоГруппа() = 1 Тогда Продолжить; КонецЕсли;
/* Строка 5 */          Если Спр1.ПометкаУдаления() = 1  Тогда Продолжить; КонецЕсли;
/* Строка 6 */          Спр1.site = "www.mail.ru";
/* Строка 7 */          Спр1.Записать();
/* Строка 8 */       КонецЦикла;

  В строке 3 происходит следущее находим  следущий id по нему делаем select * from sc46
  и записываем все реквизиты в Спр1.ТекущийЭлемент();
  В строке 4 игнорируем группы
  В строке 5 игнорируем помеч. на удаление
  В строке 6 изменяем реквизит site у элемента справочника
  В строке 7 записываем ВСЕ реквизиты конкретного элемента в таблицу sql.
  выполняется update по всем реквизитам справочника (Реквизит site = SP214)

Update SC46 set  ID=@P1, PARENTID=@P2, CODE=@P3, DESCR=@P4, ISFOLDER=@P5, ISMARK=@P6,
VERSTAMP=@P7, SP56=@P8, SP710=@P9, SP711=@P10, SP53=@P11, SP938=@P12, SP940=@P13,
SP941=@P14, SP1055=@P15, SP1056=@P16, SP1207=@P17, SP1570=@P18, SP1273=@P19, SP1383=@P20,
SP1569=@P21, SP1608=@P22, SP1609=@P23, SP1648=@P24, SP1649=@P25, SP1656=@P26, SP1657=@P27,
SP1835=@P28, SP2050=@P29, SP2051=@P30, SP2213=@P31, SP2214=@P32, SP2236=@P33, SP2237=@P34,
SP2238=@P35, SP2239=@P36, SP2251=@P37, SP2993=@P38, SP3330=@P39, SP3331=@P40, SP3547=@P41,
SP5019=@P42, SP5256=@P43, SP5374=@P44, SP5375=@P45, SP5376=@P46, SP5377=@P47, SP5378=@P48,
SP5387=@P49, SP5379=@P50, SP5380=@P51, SP5381=@P52, SP5382=@P53, SP5383=@P54, SP5384=@P55,
SP5385=@P56, SP5386=@P57, SP5388=@P58, SP5395=@P59, SP5396=@P60, SP5416=@P61, SP5737=@P62,
SP6253=@P63, SP6423=@P64 where  ROW_ID=@P65

А теперь представьте что у Вас в справочнике есть несколько реквизитов длиной скажем 300.

Сколько раз я писал аналогичный текст. Но под таким углом зрения взглянул впервые.


На основании этой информации был написан 1с++ класс
класс БыстрыйСправочникКлиенты_1 = Кл2.ert
{
   void ВыбратьЭлементы();
   Число ПолучитьЭлемент();
   void Записать();
};
Заметим здесь что этот класс не является наследником Справочника.Клиенты
В методе Записать() данного класса используется только один реквизит.
Из тестовых результатов видно что класс БыстрыйСправочникКлиенты_1 работает на  порядок
быстрее чем стандартный метод Записать();

конечно надо понимать что не все так просто. У справочника могут быть также графы отбора (надо делать
записи в доп таблицы), база может быть УРБД, Записать учитывает также блокировки или что-то еще я упустил.

Статья описывает не конечную реализацию а проблему разобравшись с которой можно значительно улучшить работу
1с приложений.
Имеем полную аналогию с прямыми запросами.
Запрос 1с неоптимальный универсальный.
Каждый раз когда мы хотим ускорить выборку мы разбираемся с таблицами и пишим
прямой запрос который выполняет задачу и работает быстро.
Аналогично когда нужно и читать и писать справочник для каждой конкретной ситуации нужно
разработать свой Быстрый-Легкий класс который работает
с минимальным количеством реквизитов и учитывает контекст выполнения.


   А как же документы ?

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

Еще одно отличие Документ можно записать в момент проведения.
В этом минусов ИХМО гораздо больше минусов чем плюсов но мое мнение ничего не меняет.

Методы ПолучитьДокумент() , НайтиДокумент копируют всю информацию из шапки документа
во внутренюю структура объекта документ.
По выборке все что относиться к справочникам применимо и к шапке документов.
По записи аналогично. И все сказанное  выше для справочника справедливо и для документа.
Но как правило документ никогда не записывается просто так.
В 90 случаях после записи документ проводиться. И если снова пользоваться стандартным способом провести
то сначала надо спозиционировать документ и все преимущество полученное быстрым классом документа будет потеряно.
Т.е. получается что надо думать в направлениии создать создания своего метода провести в быстром классе.



Эпилог
Можно еще улучшить метод Записать с с помощью параметризованных запросов и RPC, через временную
таблицу sql, а затем одним update записать в основную таблицу.
Надеюсь совмесными усилиями и знаниям мы сможем еще оптимизировать
метод Записать() для БыстрогоСправочника.





Заключение :
В заголовке статьи поставлено многоточие.
Хотелось бы обсудить кто что думает по всему вышеизложенному.

С  уважением Морев Андрей  aka Z1

(297) не ну это на скл по любому. тут не просто так взял 1С++ загрузил и вот оно.

(298) давно читал, ошибся немного.

(298) +1

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

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

(282)
1. Не понял причем тут заполненность реквизитов? подчиненный справочник тоже не горантирует заполненность всех реквизитов. Или ты хочешь сказать, что на один реквизит у тебя одна запись в подчиненном справочнике? Так это еще большие тормоза + проблемы с приведением типов, так как в результате получаем таблицу а-ля _1SConst.
2. Речь идет не про ДБФ, а про СКЛ, хотя и СКЛ таблица тоже место занимает :)
3. Когда мне надо получить любой реквизит через ".", я получаю прямым запросом только то, что мне надо (лишние реквизиты не тяну).
4. Ну и что что они индексированы, условие по колонке одной таблицы все равно быстрее, чем джоин с другой таблицей и условием по колонке присоединенной таблицы.

(283)
1. а где я говорил, что против нормального планирования архитектуры БД? Под нормальным я подразумеваю именно "нормальное", а не подстраивание под кривую работу 1С с БД на СКЛ.
2. За последние 6 лет ни разу не было необходимости выгружать базу в ДБФ, чтобы там что-то отладить... вся работа ведется на СКЛ. Зачем вообще базу СКЛ в ДБФ кидать?

(302)
Я же попросил..

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

(302) 2. про дбф. Ты аидимо не работал в сильно распределенных базах. когда зоопарк техники большой и часто в одной УРБД и Дбф и СКЛ базы с разными серверами и разными возможностями. Поддерживать 2 версии выборок и там и там?
Кроме того прямые запросы при изменении кол-ва реквизитов да и банально создаешь с этими-же метаданными новые бызы, когда банально идентификатор таблицы иной становится в ДДС вызывает некоторую проблему в перенастройки

(304) Я работал "в сильно распределенных базах". Ни разу не потребовалось базу в dbf выгружать. И куда ты ее, нафиг, выгрузишь, если в ней гигов за сотню?

(305) Это ЦБ. Я про перефирии.
Поддерживать и прямые запросы и стандартный код для ДБФ версии - не есть айс

+ 306 Кстати на СКЛ переводят и не только когда большие базы. А прежде всего из-за стабильности работы и надежности как таковой.

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

(306) "Переферия" - что-то около 40 гигов. Какая dbf?
"Поддерживать и прямые запросы и стандартный код для ДБФ версии - не есть айс" - согласен. DBF - ф топку.
(307) Кто бы спорил :)

(308) Да работает но вот не в лоб. по п2. утверждать не буду, но что-то из этой оперы есть.

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

(311) Ну, тут уж выбирать - шашечки или ехать :)

(312) Мы работаем с теми реалиями, которые есть и с людьми которые в наличии в данном регионе.

(313) Это ты к чему сказал такое?

(311) Работает на 1 компе. Девелопский сиквельник...

***total***     604090.0     100.0
LCK_M_U     189734.0     31.4
NETWORKIO     189064.0     31.3
LCK_M_X     179376.0     29.7
LCK_M_IS     19175.0     3.2
CXPACKET     10164.0     1.7
PAGEIOLATCH_SH     6752.0     1.1

Продолжение: Справочник 110 000 элементов 2

Просьба прикрыть ветку

(295) Ты не прав, в последних версиях 3.0.1.ХХХ как раз было многое сделано для ускорения всей работы 1С при простой загрузке 1С++.
Т.е. работа, выполненная еще в ВК ТурбоБЛ и перенесенная в 1С++, по ускорению работы методов и обращению к реквизитам объектов, доведена до логического завершения.

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

ЗЫ Заявляю этот ответственно как один из разработчиков, приложивших руку к этому ускорению 1С с помощью простой загрузки 1С++ :)

Причин тормозов может быть много.Это и вычисляемые поля и длинные поля с сортировкой и отбором, низкая селективность в виде отключаемой иерархии или подобного.
Вот описание одной из причин.
http://www.softpoint.ru/article_id18.htm

Ну а вообщем есть примеры с 1,5 млн записей в справочнике. Ничего не тормозит.