Как идентифицировать пользователя перед началом работы

Здесь обсуждаем систему TDM/PDM/Workflow Lotsia PDM PLUS (PartY PLUS).
Ответить
Аватара пользователя
Александр
Активный участник
Сообщения: 1652
Зарегистрирован: 24 авг 2006, 08:06
Используемое ПО: Lotsia PDM PLUS
Откуда: 55.745578,37.665825

Как идентифицировать пользователя перед началом работы

Сообщение Александр »

Вопрос тем кто придерживается двойной структуры

User's Пользователи Лоции (СУБД)
=(+)
Объекты Пользователи Лоции(Структура компании)

Не подскажите как сделать следующую штуку - в параметрах старта запустить действие которое сопоставляет текущего user'a объекту пользователю и помещает его ID в глобальную переменную Лоции для последующей адресной работы

Другими словами есть user Иванов у которого минимум информации (как у юзера) и есть объект Иванов у которого море информации (и фото и статус и семейное положение и штатное расписание и т.д. и т.п)

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

А вот если бы ID объекта Иванов все время сеанса лежал бы в глобальной переменной это было бы правильней.

Но как использовать глобальные переменные в Party я не знаю :? - подскажите :wink: :wink: :wink:

Софт - RicCRM<<LotsiaPDM(4.40)<<MsSQL(5/8)
Уровень администрирования - Альтернативный

Аватара пользователя
Старик Крупский
Активный участник
Сообщения: 803
Зарегистрирован: 27 июл 2006, 22:17
Откуда: Москва

Сообщение Старик Крупский »

Глобальные переменные это которые системные? В общих параметрах БД? Они сейчас только для документооборота. И кроме того, они действительно глобальные, т.е. у переменной одно значение. Заносим значение для текущего юзера, и для других оно тоже обновляется. Так что это не вариант. А что, поиск объекта типа сотрудник с атрибутом с заданным значением занимает приличное время? По-моему на это уходит меньше секунды.
Сейчас, получив некоторый опыт, я бы конечно сделал бы по-другому. Я бы импортировал объекты сотрудников со своими идентификаторами. То есть я бы сделал так, чтобы у объекта сотрудника был бы такой же идентификатор, как у соответствующего ему пользователю. Мысль вроде понятна? Тогда я, совершенно не заморачиваясь поиском, делаю SetByID и... понеслась душа в рай :-)
Аватара пользователя
Александр
Активный участник
Сообщения: 1652
Зарегистрирован: 24 авг 2006, 08:06
Используемое ПО: Lotsia PDM PLUS
Откуда: 55.745578,37.665825

Сообщение Александр »

меньше секунды конечно, просто надоело каждый раз сталкиваться с ограничениями среды разработки Party :? :wink: :wink: :wink: :wink: :wink:

Софт - RicCRM<<LotsiaPDM(4.40)<<MsSQL(5/8)
Уровень администрирования - Альтернативный

Аватара пользователя
Disillusioned
Активный участник
Сообщения: 420
Зарегистрирован: 15 июл 2004, 15:12
Используемое ПО: Lotsia PDM PLUS
Откуда: Подольск
Контактная информация:

Сообщение Disillusioned »

Предлагаю использовать глобальную временную таблицу. При старте Лоции при помощи f_ExecSQLSelect_2 записать в таблицу код объекта, потом при помощи того же f_ExecSQLSelect_2 получать его. Наверняка будет быстрее чем поиск через форму. Глобальные временные таблицы очень удобны для хранения информации о текущем пользователе/соединении, т.к. данные в них доступны только в рамках текущего коннекта.
Аватара пользователя
Александр
Активный участник
Сообщения: 1652
Зарегистрирован: 24 авг 2006, 08:06
Используемое ПО: Lotsia PDM PLUS
Откуда: 55.745578,37.665825

Сообщение Александр »

дело в том что использовать f_ExecSQLSelect... для записи, обновления, удаления данных можно только через вызов своих хп- что делать не очень правильно и не документировано - хотя сами мы и делаем и пользуемся :wink: :wink: :wink:

Было бы лучше хранить данные в текущей структуре Лоции т.е. таблица - объект, колонки - атрибуты.
т.е. при старте мы забиваем какой то служебный объект всеми нужными данными о пользователе или хотя бы одним указателем на объект User - а потом просто читаем их.

но тут вопрос - как сделать такой объект локальным по отношению к текущему сеансу-вроде никак :? :? :? :?

по большому счету речь идет о максимальном сокращении времени сопоставления User базы-User объект. И мы готовы терять на это ~.5 сек следующим запросом (через f_ExecSQLSelect... т.е. не через автоматическую форму)

Код: Выделить всё

         Select rw.id
          From lsdbo.object_reference_view rw,
               lsdbo.object_type_view tw
         Where (rw.type_id = tw.id) 
                AND ((tw.mnemo = 'тип объекта' 
                      AND rw.id in
                     --только работающие сотрудники
                      (Select av.object_id
                         From lsdbo.attrib_value_view av,
                              lsdbo.value_numeric_view vv
                        Where av.value_id = vv.id and
                              av.attrib_id = 100000019000005 and
                              vv.attrib_id = 100000019000005 AND
                              vv.Value > -1))
                      AND rw.id in
                     --только тот сотрудник - чей номер ID (атрибут) совпадает с id User'a базы  
                      (Select av.object_id
                         From lsdbo.attrib_value_view av,
                              lsdbo.value_numeric_view vv
                        Where av.value_id = vv.id and
                              av.attrib_id = 100004060200000 and
                              vv.attrib_id = 100004060200000 AND
                              vv.Value = 35));
кстати проверку на работающих тоже можно снять - тогда еще быстрее.

-а можно например хранить соответствие User базы User объект не в каждом объекте персонально а в каком нибудь специальном объекте (например для тех у кого сотрудников >1000) - тогда выборка еще короче

-а можно вообще это соответствие хранить во внешнем файле
да как угодно
но мы оставили все как есть Объект User хранящий в себе id User'a базы

В любом случае визуально сама процедура длиннее и потеря 0.5 сек на запрос - вообще не видна :wink: :wink: :wink: :wink: :wink:

Софт - RicCRM<<LotsiaPDM(4.40)<<MsSQL(5/8)
Уровень администрирования - Альтернативный

Аватара пользователя
Disillusioned
Активный участник
Сообщения: 420
Зарегистрирован: 15 июл 2004, 15:12
Используемое ПО: Lotsia PDM PLUS
Откуда: Подольск
Контактная информация:

Сообщение Disillusioned »

По моему скромному мнению, при наличиии прав администратора БД использовать собственные хранимые процедуры и таблицы, наоборот вполне естественно. На мой взгляд, это неплохой способ расширить возможности Лоции. У меня, например, одних только процедур и функций с сотню (при этом Лоция и не думает ругаться на операторы CALL). Конечно, вмешательства в структуру данных Лоции допускать нельзя ни при каких обстоятельствах (максимум выборка из таблиц и views Лоции).
Временные таблицы (как глобальные, так и локальные) превосходно подходят для хранения локальных данных пользователя, притом область их применения ЗНАЧИТЕЛЬНО шире обсуждаемой проблемы.
Аватара пользователя
Александр
Активный участник
Сообщения: 1652
Зарегистрирован: 24 авг 2006, 08:06
Используемое ПО: Lotsia PDM PLUS
Откуда: 55.745578,37.665825

Сообщение Александр »

например, одних только процедур и функций с сотню
круто :wink: :wink:

поделитесь идеями - что реализовано на хп - в двух словах

Софт - RicCRM<<LotsiaPDM(4.40)<<MsSQL(5/8)
Уровень администрирования - Альтернативный

Аватара пользователя
Disillusioned
Активный участник
Сообщения: 420
Зарегистрирован: 15 июл 2004, 15:12
Используемое ПО: Lotsia PDM PLUS
Откуда: Подольск
Контактная информация:

Сообщение Disillusioned »

Использовать просто SELECT или создавать ХП, в принципе разницы никакой, если в итоге получаем один и тот же результат. Просто, на мой взгляд, потенциал хранимых процедур более велик (тут тебе и временные таблицы и курсоры, и переменные, и циклы всевозможные).
Часть ХП из у помянутой сотни - это универсальные функции с достаточно простой логикой (например: поиск объекта по значению атрибута, поиск потомков и родителей по типу или значеним атрибутов, получение значений атрибутов на определенное время, получение списка документов объекта, списка версий документа и т.п.) т.е некая библиотека наиболее употребляемых запросов. Основное преимущество здесь в более компактной записи в действии текста запроса и в возможности внести изменения в тест запроса, не трогая действие(я).
Следующее применение:отчеты (тут зачастую без ХП просто не обойтись, особенно на ресурсоемких отчетах разлюбезной Sybase ASA, т.к. для обеспечения приемлимой производительности приходится идти на ряд "извращений" доступных только в ХП).
Остальная часть процедуры и функций используется в действиях и шаблонах работ со специализированным функционалом. Тут целый зверинец в части функционала и сложности.
Что касается собственных структур данных, то у меня это в основном глобальные временные таблицы. Например они используются для ресурсоемких отчетов, когда на данных одного большого проекта необходимо сформировать несколько отчетов (например детальная и сводная ведомость материалов). Осуществляем выборку данных проекта в глобальную временную таблицу (может занимать до нескольких минут), а потом на их основе формируем сколько угодно отчетов не прибегая к повторному сканированию проекта. Второе применение-хранение локальных данных пользователя. Например, для организации "сессии аналога собственной подписи", когда пользователь для подписи значительного числа документов указывает продолжительность сессии и вводит пароль, после чего ему не надо для каждого документа вводить пароль отдельно. Данные о времени окончания сессии записываются в глобальную временную таблицу, в результате чего получаем, что сессия действут не только для конкретного пользователя, но и рамках конкретного соединения с БД. (кстати без ХП мне не удалось бы реализовать аутентификацию пользователя в действии по логину и паролю в Sybase ASA).
Аватара пользователя
Anderyt
Активный участник
Сообщения: 777
Зарегистрирован: 15 июл 2004, 13:15
Используемое ПО: Lotsia PDM PLUS
Откуда: Тюмень
Контактная информация:

Сообщение Anderyt »

сразу скажу, что просмотрел тему бегло, но пришла вот какая мысль.
зачем использовать ВРЕЕННУЮ таблицу в ХП? почему она должна быть ВРЕМЕННОЙ?
соответствие ИД пользователя ИД-ру объекта-сотрудник - это постоянное явление (по крайней мере, можно сделать именно так, и без особых проблем).
то есть получается простая таблица - ИДюзера и ИДобъекта.
в действии это будет выглядеть как одна функция - execSQLSelect по этой самодельной таблице, в качестве параметра передавать ИДюзера, получать - ИД объекта...
потом - setbyid и так далее...
так можно??
лучше день потерять, потом за пять минут долететь!
Аватара пользователя
Александр
Активный участник
Сообщения: 1652
Зарегистрирован: 24 авг 2006, 08:06
Используемое ПО: Lotsia PDM PLUS
Откуда: 55.745578,37.665825

Сообщение Александр »

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

Софт - RicCRM<<LotsiaPDM(4.40)<<MsSQL(5/8)
Уровень администрирования - Альтернативный

Аватара пользователя
Anderyt
Активный участник
Сообщения: 777
Зарегистрирован: 15 июл 2004, 13:15
Используемое ПО: Lotsia PDM PLUS
Откуда: Тюмень
Контактная информация:

Сообщение Anderyt »

а сколько времени занимает запрос к таблице, в которой 2 колонки и примерно 50-100 строк? ;-)
лучше день потерять, потом за пять минут долететь!
Аватара пользователя
Disillusioned
Активный участник
Сообщения: 420
Зарегистрирован: 15 июл 2004, 15:12
Используемое ПО: Lotsia PDM PLUS
Откуда: Подольск
Контактная информация:

Сообщение Disillusioned »

Попробую описать подход с глобальной временной таблицей более детально.

Примеры на Watcom SQL.

Сначала создаем глобальную временную таблицу

create global temporary table ext_UserLocalParam(
exec_id numeric( 18 ),
) on commit preserve rows


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

create procedure ext_SaveCurrectExecID(in @exec_id numeric( 18 ))
begin
insert into ext_UserLocalParam(exec_id) values(@exec_id);
select 'Complete'
end


В действии автоматически запускаемом при старте Лоции ищем соответствующий пользователю объект (хоть бы и при помощи автоматически завершаемой формы) и при помощи вышеупомянутой ХП записываем его в ext_UserLocalParam.

В дальнейшем, при необходимости получаем кода объекта в действии при помощи SQL-запроса

SELECT first exec_id FROM ext_UserLocalParam

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

При завершении работы Лоции и соответственно, разрыве соединения с БД данные о коде объекта будут автоматически удалены и при следующем запуске Лоции все повториться заново.

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

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