обычные формы. в базе есть справочник примерно на 2 млн записей без иерархии. нужно делать в нем фильтрацию, поиск и т.п. все поля текстовые. с базой работает человек 10. что можно сделать для ускорения работы?
поможет ли апгрейд железа.
сейчас оно крутится на компе с 2 ядрамии и 4 гр оперы.
база в сиквеле.
может в регистр сведений переделать или на УФ переписать базку?

сделай отчёт

Если предположить что одна запись порядка килобайта, то справочник весит около 2гигабайт.
При этом общий объем оперативки 4гб.
В итоге тормоза.

(0) простейшие методы

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

+(3) 3. Установить сервер 1с и SQL
     4. Заменить железо

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

(1) +1 и отображение только с нужными фильтрами... Или в форме справочника по аналогии сделать

(2) В итоге - пальцем в небо.

(7)Не факт.
Я не говорю что не надо оптимизировать структуру, но когда идет работа с такими объемами 4гб оперативки это явно мало.

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

(9) Там, где это возможно.

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

но надо чтобы эти все колонки выводилось в списке и сохранять в ексель потом.
отчет пробовал делать, все равно тормозит при формировании.

пробовал переносить на серьезный сервак с 64 гб оперы. все равно как-то тупит

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

(11) Что значит "тупит" отчет? Они хотят моментально получать результат или что?

(13) за 10сек до того как понадобится

Я бы сделал справочник, где было бы просто уникальное имя.
Все остальное в регистре сведений. Причем не в одном, а в 10, допустим. В каждом - несколько букв алфавита. Например А-В,Г-Е и т.п. Получается что-то вроде индексно-последовательного метода. Работать будет быстро, но программировать всё ручками.

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

(13) ну пару минут думает)

(16) Это - не простая задача. Вот было бы 20000 записей - тогда простая.

(0) Апгрейд железа и перевод на УФ скорее всего результатов не дадут. В теории дело обстоит так, если список динамический, то данные из него выбираются порциями  записей, будет запрос к БД вида SELECT TOP 45. Обычная проблема с динам. списком - данные получаются быстро, а вот при перемотке все начинает тормозить. Нужно посмотреть, какие запросы и как долго выполняются на СУБД при формировании и фильтрации списка.

(11) Точно фиксированный - именно тип значений - Строка, фиксированная, 120 символов?

(19) да. фио строка 200, адрес 200, все остальное по мелочам 5-20

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

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

(18) да я тоже понимаю, что вроде как дин список не прокатит

(22) да, на все поля индексы стоят

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

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

(23) Не могу представить себе, какому человеку нужно одновременно видеть 2 млн записей в списке или отчете, скорее всего нужно ставить доп. фильтры.

вобщем советуете в сторону отчета думать.

(20) Я про свойство ДопустимаяДлина - Фиксированная.

перменная стояла

млин, и еще 1 поле неограниченная строка есть

(0) (12) иногда на таких базах (я не только про 1С) бывает оптимально не только улицы в отдельный справочник, но и имена и отчества вынести. Вопрос только с добавлением к базе.

(31) ты ж сказал, что все проиндексированы? Как ты безконечную строку в индекс запихнул? :-)

У меня есть пара справочников с количеством несколько миллионов записей. В итоге сделал так:
На sql сервере создал отдельную базу под доп. справочники.
Создал там таблицы, загрузил данные из csv bulk'ом. А в 1С уже настроил внешний источник данных. Вполне быстро фильтрует по такому справочнику. Оно и понятно ведь это нативный доступ к бд sql. Но минус надо писать инфраструктуру по вставке/обновлению данных.

(33) да это без меня добавили. я даже внимания не обратил сразу

(34) я тоже так иногда делаю, но не думал, что тут тоже придется огород городить

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

Фильтр можно задавать не после открытия справочника, а до.
Т.е. хочешь посмотреть записи - сначала задай условие. Иначе не посмотришь. Так например в SAP реализовано.

а вообще 2 ляма - это не много...

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

(40) у тебя условия фильтра должны быть такие, чтоб кол-во записей не привышало 1000 хотя бы

(0) для таких объемов если это возможно надо пользоваться регистрами сведений

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

(42) чем регистр отличается от справочника без иерархии?

физически и то и другое одна таблица, и  индекс то же одинаковый...

(0) Вьюху в скуле ... и делов. Вызывать можно из скуля штатным образом через XLS. Microsoft Query встроен в Excel.

(44) Вообще вроде как ничем, но например в УТ11 есть справочник КлючиАналитикиНоменклатуры и РС АналитикаНоменклатуры, так во всех типовых запросах делают соединение именно с РС

(44) справочники намного медленные и менее поворотки чем РС вот и тем и отличаются! РС совершенно другую структуру имеет на уровне СУБД.

(47) Пруф, ор диднт хэппен

(47) про индексы http://its.1c.ru/db/metod8dev#content:1590
Так че, у вас доказательства будут или слив защщитан?

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

(50) для справочника то же можно сделать кластерный индекс

(49) Собственно говоря ответ лежит в кластерном индексе, так что зачислите себе слив! Поскольку в справочнике кластерного индекса не построить! Ой...

(0) попробуй 8.3.6 + Полнотекстовый поиск+ дин. список

(51) нет нельзя..... Кластерный индекс там только по-умолчанию

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

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

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

прикинь как будет работать регистр с текстовыми измерениями :)

(56) нормально он будет работать. А как по вашему работают другие СУБД /:)

(56) это же РС, а не РН. Для такой залачи приемлемое решение, если результат даст хороший :-) Правда, не факт, что кластерный индекс вообще сможет построиться по строковым измерениям.

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

Если пойти чуть дальше и взять базу ТЕКДОК то там масса текстов и ищется быстро.

(57) ту теоретик? я практик у меня был такой регистр и примерно на 2 ляма записей, тормозил...

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

(47) На уровне СУБД все равны в виде отношений и атрибутов .  Различиие в индексах если только. Индексированная вьюха рулит.

Добавить полнотекстовый поиск и юзать его, а не отборы

+(61) И то ... как оптимизатор решит. Не случайно вендор вводит понятие подсказок оптимизатору... Ну как то так ..

(60) а сколько у тебя ресурсов было в регистре?

(60) практик. Кластерный индекс будет использован только в том случае, когда я запросом в условии ГДЕ наложу последовательно поля

ГДЕ Измерение1=..., Измерение2=... и т.д

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

Все зависит от задачи как он будет искать информацию и как накладывать условия.

Почему люди забывают о таких вещах как обновить статистику на СУБД и дефрагментировать индексы.

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

http://www.gilev.ru/index/

(65) Это только оптимизатор знает при условии достаточной статистики...

(68) + да забыл дописать и как решит оптимизатор. Это то что янаписал в (66)

(65) Не прав. Отдельные индексы не помогут, если в ГДЕ несколько условий

Ответ лежит в (66)

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

(0) я не знаю как у Вас сделано, но по тексту понимаю, что вы ищете по номеру телефона.

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

В отчетах не применять конструкцию СОРТИРОВАТЬ.

(11) (0)Код покажи, как ты фильтруешь?
1с на УФ или только Толстый клиент?
Как реализовал поиск в текстовых полях?

(40) Да, можно, можно чисто в запросе отобрать элементы, и в список выводить маленький список самих элементов, а не отбор по какой либо части текста :)

Так же можно править сам запрос, но для Динамического списка.

экспорт списка в текущем варианте похоже виснет намертво

(75) кода вообще нет, тупо стнадартный 1ский механизм фильтрации списка по условиям, который вызывается кнопкой на командной панели

толстый клиент

поиск через ctrl+f )

(78) Реквизиты проиндексированы?

(78) Естественно будет тормозить, осотенно при поиске по подстроке. Это же скан.

(78) Тебе поможет только полнотекстовый поиск

Никакие индексы тебе не помогут при поиске по подстроке.

то есть сделать им окошко для полнотекстового поиска

(83) Да

(79) ага

(85) А как проиндесированы - просто или с дополнительным упорядочиванием?

(86) просто

экспорт списка думал 2часа и 1с вылетела с ошибкой)

у меня винда на 4гб оперативы тормозит, не то что 1с)))

(87) Замени все на дополнительное упорядочивание

(90) Вы прикалываетесь?

(91) Нет, совершенно серьезно

(92) Доп упорядочивание - это индекс: реквизит + наименование

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

если записей не много после отбора, то операция сортировки не особо влияет

(95) А если много? Что скорее всего в данном случае...

(96) я больше склоняюсь к (91)

(97) http://its.1c.ru/db/metod8dev#content:2742:hdoc

(0)Посмотри в профайлере какие SQL-запросы тормозят. Сделай составной индекс средствами скуля (с теми колонками, которые участвуют в выражении WHERE).

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

К сожалению 1С стандартными средствами не дает создавать составные индексы - видимо считает 1С-ков тупыми для такого сложного понятия :)

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

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

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

И еще непонятный момент - в эксель слишшком много строк не получалось сохранить.

(11)
>>>там грубо говоря колонки - фио, адрес (удица, дом), телефон, год рождения
им надо фильтровать эту байду по улице и по возрасту. а также искать там телефон или фио (телефон уникальное поле)

Военкомат что ли там у вас? На АТО призыв идет???

Вот зачем на Украине еще нужно фильтровать по улице и возрасту огромные базы.

>> и еще там планируется рост этой байды до 10 млн.
>> и еще будет еще один такой же список и надо будет делать из них список 3, в котором будут записи из первого, но без записей из второго со связкой по телефону...

Точно!
Всего вна Украине мужчин 46% от общего количества. Численность возрастной группы 18-60 примерно 27 млн. Мужчин в этом возрасте примерно 12,5 млн. Можно догадаться, что 10 млн это боеспособные мужчины Украины.
http://ukrstat.gov.ua/operativ/operativ2007/ds/nas_rik/nas_r/nas_rik_r.html

(106) Связка по телефону - это, видимо, те, кто уже звонил из зоны проведения АТО за некоторый период.

Можете пинать, но я бы вынес эту ботву во внешний источник.
2М записей для постреса - фигня в общем.
Загнать в редис и прогнать тупой фильтр на чем-нибудь пригодном - офигейте от разницы.
Кэшируйте в редисе ваши запросы через что нравится и ухватитесь за гениталии от восторга.
PS: redis = InMemoryВсеЧтоВамНравиццо

(108) По числовым признакам и фильтрам (улица, возраст) это база укро-мобилизации.

(106) уникальный номер телефона, означает скорее всего что источник данных - базы мобильных операторов. Увеличение с 2 до 10 миллионов означает что планируется догрузить базу от еще одного или нескольких операторов

+110 и это не базы киевстара и мтс-украина

http://e-finance.com.ua/show/185733.html
Осторожно укро-сми

(111) Интересно, откуда они взяли 60,6 млн абонентов, если общая численность не более 45 млн. Почему такой большой разрыв? В России так же интересно?

(112) У многих по 2-3 симки бывает.

(112) у кого-то несколько номеров + туристы могли купить для местных звонков

Это всё конечно версии, но romix , нужно признать, нестандартно мыслит - сложил 2 плюс 2

не военкомат, но идея интересная

(116) Общенациональная (судя по размерам) база Украины с фильтром по улице и возрасту — что бы еще это могло быть...

То есть, некоторые люди имеют определенный возраст и живут на одной улице — это кто?

Разрешите мои сомнения, а то у меня фантазия уже иссякла — кроме военкомата АТО ничего не могу придумать.

(0) в бан