есть sql2000,  1с77  (25 релиз)
Есть Огромный справочник клиенты
число записей 144 000
размер одной записи 1 Кб ( почему так не обсуждаем )
количество уровней 5
Сейчас пользователи когда хотя снимают устанавливают иерархию
в этом справочнике.
Если запретить снятие иерархии ( всем пользователям )
улучшит ли это общую производительность sql сервера.
Можно ли это как то увидеть в цифрах.

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

leshik писал(а) 26. Февраля 2010 :: 09:47:

Я года три назад попробовал переделать один из журналов на ТП.
Все работало правильно и не хуже стандартного журнала.
Ничего из этой затеи не вышло.
И цвета пользователям не такие и колонки не те и еще много чего не так по мелочам.Вернул все обратно.
Может сейчас ТП уже и не такое как раньше но у меня еще и 1cpp 2.3

chessman писал(а) 26. Февраля 2010 :: 10:07:

Так если в ТП тоже делать снятие иерархии то не думаю что будет намного быстрее ну чуть луше запрос потому что не все поля берем со справочника клиента, можно чуть лучше сортировку сделать
чем в стандартном справочнике ( разница во времени видна
только на этом справочнике
речь идет что при сортировке по реквизиту ORDER BY ИмяРеквизита, ROW_ID
поставить ORDER BY ИмяРеквизита ) но все перевешивает объем этого справочника.

chessman писал(а) 26. Февраля 2010 :: 10:25:

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

Речь идет о том чтобы добиться снижения общей нагрузке на sql сервер.
Я считаю что показ Всего такого большого справочника что в стандартном 1с списке что в ТП создает
большую нагрузку на sql сервер.
Эту нагрузку можно значительно  снизить если уменьшить объемы выборок.

chessman писал(а) 26. Февраля 2010 :: 10:38:

Почему минимальна.
помимо своих клиентов  есть ничьи (общие) клиенты.
Давайте по другому
Два вопроса
1.если строить иерархию в ТП как в стандарном списке 1с то
чем ТП лучше стандартного списка 1с
2.Если выводить все элементы справочника ( нет иерархии ) то чем ТП будет лучше стандартного списка 1с

и еще вопрос для стандарного списка 1с как отличается нагрузка на sql сервер при снятии установлении иерархии.

Вопрос в чем ограничение их работы то? Стандартный справочник по сравнению с возможностями ТП просто курит в сторонке.
Что касается быстродействия... если не ставить автообновление тогда можно говорить о том что ТП точно будет создавать меньшую нагрузку (хотя бы за счет того что открытое окно в трее просто напросто не обновляется от каждого чиха пользователей в базе).
Про автообновление пользователям можно ДОНЕСТИ аккуратно и доходчиво что так будет лучше. А вот согласятся или нет зависит от того как ты доносишь информацию. Есть люди кто и хорошее донести не сможет, а есть те кто говняшку как конфетку представят. Всякое встречал в жизни.

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

alexdd писал(а) 26. Февраля 2010 :: 11:12:
Цифры смотрел цифры большие.потому что для стандартного 1с списка без иерархии
курсора открываются  как
select * from  ИМЯ (nolock INDEX = КонкретИндекс ) order by Поле,ROW_ID  Зачем  тут * достаточно id и/или row_id
далее идет позиционирование на нужную строку курсора
и Цикл по количеству видимых записей
select * from  ИМЯ (nolock ) where ID = 'Конкрет ID'
Получить все доп поля строки из других справочников.

alexdd писал(а) 26. Февраля 2010 :: 11:12:
получено добро у руководства ускорить улучшить общую работу всех пользователей ( без замены железа)
вот я и озадачился в том числе как работает огромный справочник без иерархии и что с этим можно сделать.
Так что в разумных пределах мнение пользователей сейчас не является решающим.

В общем может пример может нет, но пока я так делаю

1. Формы списка - на базе ТП в виде обработок (индивидуальные для конкретных справочников, и одна универсальная для всего-всего-всего). Как подсовывал не спрашивайте
2. Стандартную форму списка заменил на ТП без автообновления (ибо предполагается что ее открывают только для выбора).
Многострочную часть уменьшил до офигенски маааааленьких размеров, привязал к нижней части (чтобы не расширялась), и скрыл формексом. Подробно нагрузку не изучал. Как нить как объем большой будет посмотрю как будет себя вести. Открытый курсор пока напрягает, но при желании можно попробовать что-нибудь с этим делать. Есть же компонента для перехвата текстов запросов 1С .

chessman писал(а) 26. Февраля 2010 :: 11:51:

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

Провел эксперимент, создал в справочнике Основных средств 150 тыс. элементов.

На ТП (колонки Код и Наименование) все летает, и при установленной иерархии и при отключенной.

Z1 писал(а) 27. Февраля 2010 :: 11:41:


Как это узнать?

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

в qa выбираешь свою базу и запускаешь скрипт со своей таблицей

select sum( convert(int, length))
from syscolumns
where  id=object_id('sc13')
 

либо можно самому посчитать в столбик вызвав
sp_help sc13




ps долго не отвечал интернет сломался

orefkov писал(а) 28. Февраля 2010 :: 21:30:

Точно тупо ищут по первым буквам ( сила привычки)
Хотя есть фильтр по разным условиям в том числе и по наименованию.

vandalsvq писал(а) 01. Марта 2010 :: 06:35:

Ну, насчет "офигительный" я конечно загнул спросонья, а так для примера можно глянуть http://sqlite1c.googlecode.com/files/search_goods_customers.zip (для дбф баз)

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

Z1, твой запрос выдал результат 230, я предполагаю, что это длина всех полей в таблице...т.е. получается 230 байт?

Провел след. эксперимент: добавил 10 текстовых реквизитов с длиной 100, теперь длина записи получилась 230+1000 байт. Для чистоты эксперимента заполнил их текстом.
Результат не изменился - как летала ТП, так и летает.

Эсперименты с dbcc dropcleanbuffers тоже не изменили визуальных ощущений.

Ну вот в свое время когда писал поставщика для 1sqlite, баловался. Ничего особенного, но принцип уловить можно.
Запускать на демо ТиС дбф, с 1sqlite.
В приоткрытии только подправить пути к ВК.
А так на форуме "Репозитарий" смотри "ПоставщикДанных". Там все есть вроде бы.