Сбор мнений :) по реализации многопольз. задачи

netfrog
Дата: 12.12.2002 19:14:32
Есть следующая ситуация - набор данных в многопользовательской среде из которых делается выборка по определенным критериям, иногда пользователи хотят видеть все данные и некоторые из них помечать для последующей обработки. В однопользовательской версии в БД добавлено битовое поле, которое в реальном времени редактируется посредством грида. Соответственно при формировании отчета по выбранным данным в запросе указывается определнный флаг поля и все прекрасно.

Как это правильно реализовать в многопользовательской среде? Использовать временные таблицы и давать пользователям работать с ними или все же делать выборки средствами клиента на отцепленном рекордсете? Или есть более красивые варианты?
папа Карло
Дата: 12.12.2002 20:45:21
Это называется отношение один ко многим.... все зависит что у вас на бизнес слое, какая логика, сколько данных... итд...
Александр Спелицин
Дата: 13.12.2002 00:09:15
На каждую такую таблицу с данными придется создать еще по одной таблице. В них будет информация о том, какая запись отобрана каким пользователем. Пользователей можно идентифицировать по логину, либо по id сессии (@@spid). Если по логину, то 2 человека, зашедшие под одним логином будут видеть действия друг друга. Если по id сессии, то в конце сессии нужно удалить все, что было в ней создано.
Mik Prokoshin
Дата: 15.12.2002 10:50:47
С точки зрения универсальности - загрузить этим клиента, как Вы и предполагали (проще всего сделать отцепленный рекордсет, где хранить ключи отобранных записей или комбинацию ключ - знак пометки (что более расточительно)). Если у клиентов очень ограничены ресурсы, то - придется на сервере, как сказал Спелицин.
dkstranger
Дата: 15.12.2002 11:25:10
2netfrog
Более привлекательно из прозвучавших предложений, конечно -
временная таблица.
Это позволит независимо выбирать данные, независимо их обрабатывать,
не беспокоясь о передачи параметров и цеплять еще кучу доп.
информации (типа кто выбрал, когда и пр.)

Единственное требование - далеко не все приложения держа один коннект.
Поэтому (и для возможности аудита и отладки из другого коннекта)
соответствующие таблицы мы стали делать статическими по след схеме
1. При запуске клиента открывается новый сеанс (в таблицу список
сеансов заносит соотве запись, пользователю возвращается id сеанса)
2. Дальше все телодвижения пользователя идут с параметром id сеанса
3. Все выборки одинаковой структуры содержатся в статиче таблице,
разделены флагом id сеанса