Решение разработчика в зависимости от опыта работы. Как ограничить отображаемый пользователю список и ничего не потерять

0. 10 25.02.20 10:00 Сейчас в теме
Решение разработчика в зависимости от опыта работы.
Ограничение отображаемого пользователю списка без применения RLS.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. VmvLer 25.02.20 10:41 Сейчас в теме
Заголовок дает претензию на то, что в теме будет понятный сравнительный анализ вариантов решения
с четкой детализаций разниц.

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

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

Остальные проф темы будут в своих профильных разделах.
paybaseme; Ta_Da; user764477; Diversus; +4 Ответить
2. user633166 10 25.02.20 11:05 Сейчас в теме
(1) Ваше право написать лучше, детальней, прозрачней, детальней, удобней...

А я вашу критику приму к сведению и буду стараться изложить следующий раз понятнее.
3. Diversus 2122 25.02.20 11:10 Сейчас в теме
А ваше решение действительно "senior-ское"?
Вы используете в запросе левое-соединение с подзапросом к регистру остатков.
Но вот тут: Типичные причины неоптимальной работы запросов и методы оптимизации говорят, что это не правильно.
user764477; wowik; +2 Ответить
5. user633166 10 25.02.20 14:56 Сейчас в теме
(3) Отвечу так - если я правильно понял то вы руководствуетесь данной фразой ИТС "Оптимизатор сервера СУБД (независимо от того, какую СУБД вы используете) не всегда может правильно оптимизировать подобный запрос. В данном случае, проблемой для оптимизатора является выбор правильного способа соединения. Существуют несколько алгоритмов соединения двух выборок. Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке. В том случае, если вы соединяете две физические таблицы, СУБД может легко определить объем обоих выборок на основании имеющейся статистики. Если же одна из соединямых выборок представляет собой подзапрос, то понять, какое количество записей она вернет, становится очень сложно. В этом случае СУБД может ошибиться с выбором плана, что приведет к катастрофическому падению производительности запроса."

Два момента:
Дата публикации 07.12.2015 Типичные причины неоптимальной работы запросов и методы оптимизации - считаете, что производители СУБД 5 лет не работали.
И второй, я не пытаюсь реализовать "оптимальное решение", поскольку "Выбор того или иного алгоритма зависит от того, сколько записей будет содержаться в одной и в другой выборке."
4. Liogon 8 25.02.20 14:36 Сейчас в теме
А на каком уровне у разработчика возникает вопросы типа "А какую проблему вы хотите решить этой доработкой?" и "Почему это является проблемой?" Из контекста постановки я предполагаю, что пользователям тяжело работать с большим списком данных, большая часть которых для него вообще не актуальна. Но тогда возникает другой вопрос. "Что такого у пользователя произошло в жизни, что ему этот список потребовался?" Ответ будет лежать в плоскости бизнес-процессов, а не конфигурации. Но оттуда уже будет ясно, что разумнее будет не переделывать динамический список и крутить РЛС, а сделать отчёт, который покажет только нужные карточки. Либо настроить один из типовых. Либо сделать форму подбора в документ. И с точки зрения поддержки это будет более "удобное решение". Все изменения лежат на поверхности. А то и вообще в справочнике доп.обработки.
6. user633166 10 25.02.20 15:03 Сейчас в теме
(4) Вы правильно понимаете, что у пользователя проблема работы со большим списком карточек номенклатуры, в общей массе не актуальных для него. И представьте себе, он зачем-то этот список открывает. Вероятно у него такой бизнес-процесс. Тогда вопрос к Вам - отключить у пользователя возможность открыть такой список? А в форме подбора(выбора) Вы что собираетесь поменять, чтобы ограничить список?
7. Liogon 8 25.02.20 15:17 Сейчас в теме
(6)
И представьте себе, он зачем-то этот список открывает. Вероятно у него такой бизнес-процесс.


Так вот в этом то и вся суть. Зачем-то это зачем? Тут, навскидку, есть 2 варианта:
1) Это форма выбора, а не форма списка. Соответственно этот список открылся из какой-то другой формы.
2) Если это форма списка, значит пользователь какие-то действия может делать либо только в ней, либо оттуда проваливается в форму элемента, и какие-то действия совершает там. Такие вещи решаются созданием АРМ, которое в общем случае можно просто приставить к основной конфигурации, не изменяя логику её работы.


(6)
отключить у пользователя возможность открыть такой список?


Лишить его причин туда заходить и он сам перестанет это делать. К тому же наверняка уже есть, или появится в обозримом будущем категория пользователей, которым нужен этот список целиком.
8. user633166 10 25.02.20 15:54 Сейчас в теме
(7) "Хотелка" возникла по форме списка, рассуждения по теме как сделать "хорошо" пользователю, чтобы он не просил эту "хотелку" - сделать вместо этого ему АРМ, не тема этой публикации, я просто продемонстрировал разные подходы к решению.
Категория пользователей с административными правами на весь список была с самого начала, и будет всегда даже в необозримом будущем.
Оставьте свое сообщение
Вопросы с вознаграждением