Лень региться
1) Смущает необходимость написания ХП а-ля:
sp_get_documents (тут нам надо показать документы)
sp_get_documents_user (тут нам надо показать документы + информацию об авторах)
sp_get_documents_dept (Документы + информацию об подразделениях)
sp_get_documents_tree (документы для вывода дерева на клиенте...пример не самый удачный, ну да ладно: )
sp_get_documents_grid
.....
И т.д.
То есть это почти одни и теже данные, но либо изменяется набор выходных полей (добавляется наименование или описание присоединенных таблиц) или нужно присоединить другую таблицу и в результате увеличится кол-во записей(ну и добавятся некоторые поля).
не совсем понял проблемы, для каждой ХП у вас свой возвращаемый набор, равно как и было бы для предствления.
Лень регитьсяДопустим на форме(клиентсое приложение) выводится список документов и необходимо реализовать фильтрацию данных(пользователь в полях фильтра вводит значение и данные фильтруются). Без ХП все просто:
В приложении динамически генерируется запрос вида
SELECT * FROM vw_docs WHERE doc_author LIKE 'ива%' AND doc_type_id = 4
, в зависимости от заполненных полей фильтра и выполняется на сервере.
А как быть с ХП?
Писать хранимку на все возможные поля фильтра
sp_get_documents(doc_name, doc_type, ..., filter_25)
и в зависимости от того, какие параметры
то по тем и строить запрос?
Фильтровать данные после хранимки
SELECT * FROM sp_get_documents() WHERE doc_author LIKE 'ива%'
тоже не выход - по причине низкой производительности.
не... про select * from view... - забудьте )))
тут надо "оптимизировать" исходя из ситуации..
например, мой случай...
у мя все крутилось вокруг таблицы документов, и их статусов (что-то типа docflow)
и причем, надо было одновременно в таблицу выводить около 12 статусов... чтоб было видно когра регали, когда/кому отписали, когда исполнили...
то есть к основной таблице, около 12 join таблицы status_list и ещё к ним join таблицы status_name чтоб узнать "Названия статусов" и ещё приджойнить таблицу с пользователями которые задали этот статус и кому перенаправили док...
в общем это большая жесть, аксес задумывался на минуту уже при 200х документах, собственно почему на PostgreSQL перевел все...
а ещё и надо искать Like почти по всем строковым полям.., фильтровать по статусу ("все новые" или "на исполнеии"), по дате самого документа и дате регистрации
то есть, ядро сперва джойнило почти весь массив с данными, выбирала диапазоны с подходящими датами и строками... в общем жуть
надо было что-то делать...
сделал отдельную табличку, для предварительного отсева, назвал её doc_index
там был doc_id, последний статус, нужные даты (разбил по int полям), пользователей...и одно поле строку... тип данных что-то с vector связанное, для полнотекстового индекса (туда через пробел пихал все строковые поля по которым надо искать), и на наделал много соответствующих индексов. когда вызывается хранимка на сохранение дока - обновляется этот "всевдо индекс"
основной критерий отсева доков - дата регистрации/документа или диапазон и поледний статус...
это все выбирается исходя из вашей специфики... у вас возможно это будет "отдел" или "проект" или ещё что-то...
исходя из этого, во временную таблицу, выбирал все doc_id которые соответствуют нужным критериям, через int поля таблицы doc_index это делаетс очень быстро
если была введена строка - то динамически клеем where str_index like... FullSeachText тоже довольно быстр.....
ещё... пользователю по умолчанию выдаем ток 50 документов (что с нормальным поиском вполне хватает), но он может выбрать ещё и 100, и 1000
Далее, надо эту табличку с doc_id заполнить содержимым... куча тех страшных джойнов
и тут я понял одну вещь... всего, я могу вывести около 40 полей для одного дока... но зачем пользователю 40 полей, они на экране не поместятся... причем одни поля могут быть нужны одним пользователям, и ненужны другим...
тогды ещё одну табличку, где хранятся описания какие поля какому пользователю нужны
и в процедуре выдачи дока - образно:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
if( упользователя стоит галочка1)
begin
update result_table set f1 = a.status_date
from (select....);
end;
if( упользователя стоит галочка2)
begin
update result_table set f2 = a.status_name
from (select....);
end;
...
такой отсев тоже дал хороший прирост, обычно из 40 полей надо максимум 10...14
с клиента конечно сложнее передавать условия запроса, много параметров...
но, когда для тестирования забил 30тыс доков... был длинный первый запрос пользователя, до 7 сек... а все остальные укладывались до 2 сек... на десктопе
можно было ещё быстрее, если учесть, что 95% запросов на документы которые "в работе", а это всего 40...100 последних документов
то можно было сделать таблицу "архив", куда все исполненное сбрасывать
на "оперативной таблице" быстрый поиск критичен, на архивной - нет, туда обращаются только при разборе полетов, построения отчетов, и посмотреть "как было"
можно секционирование делать (на разные таблицы), "за год", или "для отдела", "для проекта"
и все это спрятать за процедурой, для клинета это будет незаметно
в общем ХП дает очень много возможностей по оптимизации выборки, там можно играться опциями оптимизатора, местами, более "интелектуально" чем это делает он сам... например включить один режим для одного запроса, и после другой для следующего, чтоб добиться максимум производительности
