Здравствуйте!

Очень медленно работает динамический список на форме списка справочника. В справочнике 350к элементов, 22 реквизита, не считая стандартных. В произвольном запросе беру 20 реквизитов без сортировок, группировок, условий, использую только одну таблицу (сам справочник).

Платформа 8.3.12

Вот сам запрос:


ВЫБРАТЬ
    СправочникКнигаЗахоронений.Ссылка КАК Ссылка,
    СправочникКнигаЗахоронений.ПометкаУдаления КАК ПометкаУдаления,
    СправочникКнигаЗахоронений.Год КАК Год,
    СправочникКнигаЗахоронений.Фамилия КАК Фамилия,
    СправочникКнигаЗахоронений.Имя КАК Имя,
    СправочникКнигаЗахоронений.Отчество КАК Отчество,
    СправочникКнигаЗахоронений.Комментарий КАК Комментарий,
    СправочникКнигаЗахоронений.Кладбище КАК Кладбище,
    СправочникКнигаЗахоронений.Возраст КАК Возраст,
    СправочникКнигаЗахоронений.ДатаРождения КАК ДатаРождения,
    СправочникКнигаЗахоронений.ДатаСмерти КАК ДатаСмерти,
    СправочникКнигаЗахоронений.ДатаЗахоронения КАК ДатаЗахоронения,
    СправочникКнигаЗахоронений.ДатаОформления КАК ДатаОформления,
    СправочникКнигаЗахоронений.АдресПодачиКатафалка КАК АдресПодачиКатафалка,
    СправочникКнигаЗахоронений.Квартал КАК Квартал,
    СправочникКнигаЗахоронений.Участок КАК Участок,
    СправочникКнигаЗахоронений.Ряд КАК Ряд,
    СправочникКнигаЗахоронений.Могила КАК Могила,
    СправочникКнигаЗахоронений.НомерСвидетельства КАК НомерСвидетельства,
    СправочникКнигаЗахоронений.Заказчик КАК Заказчик
ИЗ
    Справочник.КнигаЗахоронений КАК СправочникКнигаЗахоронений


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

Пробовал индексирование с доп. упорядочиванием - ничего не меняет.

Кроме ФИО заказчику необходимо искать и по другим полям, по ним также стоит индексирование. Всего на 11 реквизитах этого справочника.
Делал реиндексацию таблиц ИБ.

Как можно оптимизировать этот динамический список и ускорить поиск по нему?

Может в справочнике индексировать эти поля

Галка установлена "Динамическое считывание данных"?

(2) Да, установлена. Что значит в справочнике индексировать эти поля?

тут все равно фулл скан, если с отборами

отдельные индексы по полям смысла имеют мало. фамилии достаточно

(5) Иногда заказчик ищет только по имени и отчеству или только по адресу захоронения, состоящего из нескольких полей, не зная ФИО. На эти поля точно не нужна индексация?

Полнотекстовый поиск включен? Если да, то индекс ППД актуален?

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

А вообще стрёмная структура справочника. Нежели кто-то делает поиск, например, по 10-му участку всех кварталов всех кладбищ? Или по отчеству "Иванович" среди всех захороненных?

(7) Забыл отписаться, слияние, обновление настроил. Структура справочника стрёмная, но вынужденная. Поиск ведётся как угодно, например, бывает ищут все участки, оканчивающиеся буквой "п". Или же не знают ничего, кроме Отчества и примерного участка.

Если ищешь через ППД, то индексы БД пофиг какие

(0) напиши поиск ссылок запросом, отбор - только по ссылкам

(0) Можно узнать название конфишурации? Это типовое/отраслевое решение?

(0) на каком железе все это работает?

(11) (12) Самописная конфа на БСП (из БСП только контактная информация и файлы). Файловая база, железо приличное intel i5, оперативки тоже хватает

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

(0) Мля, жестяк...

Пометка удаления в таком справочнике.. зачет

(8) >>Поиск ведётся как угодно, например, бывает ищут все участки, оканчивающиеся буквой "п".

Пи*дежь. Все участки, оканчивающиеся на "п" будут искать на определённом кладбище. На ВСЕХ кладбищах такой поиск нафиг не нужен.

>>  Или же не знают ничего, кроме Отчества и примерного участка.

Опять таки такой поиск будет с отбором по кладбищу или же с ещё какими-либо дополнительными отборами.

1. Не делать дин.списком, делать отчетом.
2. Поля проиндексировать (без доп упорядочивания, они примитивные)
3. "открывается справочник секунд 20-30" - это очень странно для приведенного запроса, с динамически считываемыми данными.
!!! Кстати, галка "произвольный запрос" установлена? Если да - убрать нафиг.

Мне кажется это должен быть регистр

(19) И что изменится?

(0) А какой тип имеют поля Фамилия, Имя, Отчество, Комментарий, Кладбище, АдресПодачиКатафалка, Квартал, Участок, Ряд, Могила, НомерСвидетельства, Заказчик?

Это случайно не строки неограниченной длинны?

А зачем поле Возраст при наличии ДатаРождения и ДатаСмерти?
Зачем в этой таблице поля ДатаОформления и АдресПодачиКатафалка. Это текущая "оперативная" информация. Вряд ли важен АдресПодачиКатафалка для клиентов, захороненных десять лет назад.
А какой смысл поля Год, если есть все даты - и смерти, и рождения, и захоронения?

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

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

(19) >> ...это должен быть регистр.

Обоснуй! (с).

Лично я не вижу никакого особого смысла.

ИМХО, поможет только перевод на SQL.

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

(13) Работа с базой идет локально или по сети?

для содержит юзайте полнотекстовый поиск

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

(23) Перевод на SQL конечно поможет.
Но всё равно, по-моему, даже на файловой не должно так жестко тупить.

350К записей и файловая база на i5, что тут можно оптимизировать?

ответ - ничего.

вероятно еще и диск не SSD

(14) это ж всё государственное, как в поликлинике обстановка

(17) Да, по одному кладбищу. Только проблема в том, что у них оно огромное кладбище (примерно 80% всех записей) и штук 10 маленьких кладбищ. Понятное дело, они ищут чаще всего по огромному, поставив отбор. Только это не спасает ситуацию.

(18) Уверен насчет отчета? Мне кажется, что дин. список намного быстрее получает свои 10-50 записей и подгружает их во время прокрутки, чем отчет будет получать все записи. Доп. упорядочивание убрал.

(21) Все эти поля - строки длиной до 50 символов. Есть два неограниченных, но они не индексируются и по ним не ведётся поиск. По всем полям с датами поиск ведётся. Дата смерти, дата рождения, возраст. Если что-то убрать. то придётся рассчитывать недостающее значение в запросе, чтобы поставить на него условие, ведь так? А с таким количеством записей запрос с арифметической операцией будет работать ещё дольше.
Какой смысл поля "Год" - не помню. Заказчик вообще обратился за тем, чтобы я перевёл им самописную базу с обычных форм на управляемые. Архитектуру я не менял.

(24) 50 символов стоит на каждое поле

(25) локально

(30) да, обычный hdd

В общем, я убрал им отборы платформенные, чтобы при изменении полей не производился поиск раньше времени (пока все поля для поиска не будут заполнены).
Настройка индекса ППД, слияние и т д помогла.
Поиск, конечно, всё равно медленный очень, секунд по 5.

(0) почитайте про про индексы бд. под вашу задачу больше подойдут РС.

Адресное хранение, пересортица и восстановление последовательности, простигосподи.

Адресный склад на кладбище
Надо менять структуру БД: добавить справочник физлица(ФИО,....), справочник местоположений(ряд, ячейка, помещение) видимо подчиненный справочнику кладбищ.
Заменить в книге реквизиты на ссылки этих справочников, проиндексировать необходимые поля справочников(надо делать собрав статистику по запросам по каким полям чаще отбирают, тж в помощь). Делать ли вместо справочников РС(что усложнит разработку) это вопрос, база файловая, индексы свои не добавить. Делай тестовую базу, забивай еще рандомными данными и экспериментируй со структурой метаданных

+(33) сроки годности, правила хранения (шиитов с суннитами нельзя)
плюс оптимизация зон приёмки , до кучи оптимизация двумерного раскроя участков а в перспективе 3-х мерного размещения урн.

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

Говорил же умный человек: делай отчет. Раз сразу по 10050 полей в условие надо им вводить - так отчет тут и подходит.
Ну или установка отборов через обработчик ожидания - когда пользователь точно закончил ввод параметров (так вроде для вебклиентов делали).