Вход:
В системе имеются:
- некий перечень организаций, с которыми мы имели или имеем сношения (например, "Контрагенты");
- перечень договоров поставки контрагентам с признаком действия на текущий момент.
- некие формы ввода документов (например, "Создание заявки на отпуск товара клиенту", "Создание именной рекламы бывшему клиенту");
- обе формы в заголовке содержат реквизит "Контрагент" (т.е. клиент/бывший клиент);
- в заявке нужно выбирать только текущих клиентов (у которых есть действующий договор);
- в рекламе нужно выбирать только клиентов, у которых нет действующего договора.

Задача: спроектировать в системе возможность настройки удобного выбора клиента в зависимости от формы.
Условие: настройка хранится в реляционной СУБД.
Формат решения: диаграмма E/R.


Вариант решения №1 на рисунке (2-ой дан :)

Комментарии, предложения?

iscrafmАнатоЛой- в заявке нужно выбирать только текущих клиентов (у которых есть действующий договор);
- в рекламе нужно выбирать только клиентов, у которых нет действующего договора.
Анатолий, а в чем сложность в первом случае выбирать контрагентов со значением в каком-то поле 1, а во втором - 0? Т.е. в запрос списка клиентов передавать параметром статус клиентов, в зависимости от того, в каком документе этот запрос вызывается.
Или есть какие-то скрытые особенности?

"Спасибо за вопрос" (с) набившие оскомину знатоки правильного диалога.

В предложенном решении №1 как раз явно присутствует недостаток: не выполняются эти самые условия.

Вход задачи- в заявке нужно выбирать только текущих клиентов (у которых есть действующий договор);
- в рекламе нужно выбирать только клиентов, у которых нет действующего договора.


Предлагаю уточнение к варианту №1 (вариант №2) (см. рисунок, 3-ий дан :).

Выгоды по сравнению с "передавать параметром статус клиентов" следующие:
- имеем "русскоговорящее название" критерия отбора данных;
- имеем учёт реквизитов, в формах которых используют тот или иной алгоритм отбора;
- не привязываемся к текущему способу получения/хранения реквизита "имеет действующий договор".

Комментарии/предложения принимаются.

У варианта №2 есть важный момент: если необходимые критерии можно реализовать на уровне SQL, то "Алгоритм отбора" - это обычные предикаты WHERE к


.
Например:
"is_client = 0"
или
"OrgIsClient(id_organization, TODAY) = 0",
или
"(
) > 0".
Т.е. есть возможность использовать "SQL-скрипты" без подключения:
- интерпретатора скриптов на языке ООП;
- впиливания в сервер приложений case/switch, который в зависимости от "названия" алгоритма будет вызывать некий метод;
- впиливания в сервер приложений динамического вызова функции по названию и т.п.

Недостаток варианта №2 - "безусловные" критерии. Как показано в примерах-коментариях, критерии работают без входных данных...
Ждите варианта №3... :)

dma_caviarНо вообще-то это жутко фиговый подход. Какие-то обрывистые sql запросы. Совсем не очевидно с первого взгляда что тут происходит.
Хотели настраиваемую систему, а получили плохо управляемые метаданные.
Куски кода, разбросанные по интерфейсу и без IDE для компиляции/поиска ошибок/рефакторинга...

Предлагаю вариант №3 на рисунке (уже дан на 6-ой тянет :)...

Сохраняем логику в реляционном виде: и совсем не проблема собрать запросом всё необходимое для анализа в кучу.
И куча эта будет анализируема ровно настолько, насколько была декомпозирована изначально... :)

Вариант №2:
входные параметры + использование в качестве значений параметров:
- констант,
- констант из перечней,
- переменных из текущих значений в форме.

Комментарии/предложения/замечания/апплодисменты? :)

dma_caviarГораздо лучше унаследовать от Сотрудников еще один справочник, например "Сотрудники текущего офиса" или "Сотрудники", но с фильтрацией по офису, куда необходимо передавать обязательный параметр "Офис".
1. О! Спасибо, добавлю реквизит "Обязательный" во "Входной параметр критерия"

2.
а) Переименуйте мои "Критерии отбора с фильтрацией" в "Подмножество перечня"
или
б)
1. Архитектуру реализации хранения настроек выберите не РСУБД, а язык ООП.
2. Для каждой сущности/реквизита/связи укажите альтернативу хранения в новой архитектуре
2.1. "Перечень" в "Тип/Класс" Domain Model,
2.2. "Критерии отбора с фильтрацией" в "Подтип/Наследник" Domain Model.
2.3. "Форму" в класс "UI View"
...


Получим "тот же вид сбоку" (с)... :)

dma_caviarНо вообще-то это жутко фиговый подход. Какие-то обрывистые sql запросы. Совсем не очевидно с первого взгляда что тут происходит. Нужно лезть в скрипт справочника Сотрудников и догонять смысл (хотя можно визуально подсвечивать). А ведь платформы для того и создаются чтобы удешевлять разработку и повышать управляемость проектов.


Очень хочу себя перепроверить.
Если не затруднит, можно примеры проблем в вашей реализации, а я проверю и отпишусь, может ли это "проблема" быть реализаована как "рутинная задача" на моём варианте №3?

dma_caviarАнатоЛой2.3. "Форму" в класс "UI View"
Вот тут не соглашусь. Форма и Представление, это все же разные вещи. Форма это сугубо разметка элементов управления и ничего более. А представление это фактически UI логика.
Пардон, я использовал "UI View" из плохого паттерна "батонобросательной 2-х-звенки" :). Да, конечно, же тут "Форма" = "Представление/View", если брать паттерн MVP.

АнатоЛой1. Архитектуру реализации хранения настроек выберите не РСУБД, а язык ООП.
2. Для каждой сущности/реквизита/связи укажите альтернативу хранения в новой архитектуре
2.1. "Перечень" в "Тип/Класс" Domain Model,
2.2. "Критерии отбора с фильтрацией" в "Подтип/Наследник" Domain Model.
2.3. "Форму" в класс "UI View"
...

Получим "тот же вид сбоку" (с)... :)
Т.е. получим вместо "хранения настроек функционала (настройка выбора значения из перечня в реквизит) " в виде "кода реализации настройки...на языке ООП" :).
Мы правильно поняли друг-друга? :).

dma_caviarНаверное да)) Хотя разговор получился настолько абстрактным, что я уже слабо догоняю.
Забудь... По-крайней мере, пока... :).

dma_caviarАнатоЛой,

Собственно основная проблема тут одна, это разрыв sql кода, который будет в рантайме единым скрипитом. Т.е. скрипт вроде как единый, но конфигурится он в двух разных местах.

Например
автор"is_client = 0"
или
"OrgIsClient(id_organization, TODAY) = 0",
Открываем и видим нечто непонятное.

Ну в общем да... согласен, что можно в конфигураторе автоматом считать скрипт загрузки самого справочника, затем взять "is_client = 0", слить их оба и показать настройщику как единый скрипт (при этом можно даже заблокировать редактирование первой части и разрешить только вот эту часть править - "is_client = 0". Есть контролы с подсветкой синтаксиса, позволяющие это делать.
И это, если я правильно понял и есть смысл "Варианта №3".

Это можно сделать как в вариенте №3, так и в варианте №2. "Алгоритм отбора" появился уже в №2.
Смысл вариант №3: есть описание выделенных входных параметров скрипта и описание правил заполенния параметров при вызове "критерия отбора" в рантайме...

dma_caviarЯ даже было загорелся этой идеей сначала. Но потом прикинул, что все это маскировка проблемы. По идее, если настройщику требуется наложить фильтр на какой-то существующий справочник, значит ему просто не хватает еще одного справочника (точнее выборки на основе этого справочника).

Вот же она, эта "выборка" - запись в "Критерии отбора из перечня".
- описываешь один раз (например, "Актуальный клиент");
- алгоритм отбора описываешь один раз (настройщик сам или по чьей-то наводке - всё с наворотами из первой цитаты);
- используешь везде, где требуется "актуальный клиент";
- видишь по связям (FK для РСУБД), где используется;
...

dma_caviar К тому же эта выборка может еще где-нибудь понадобится, так уж лучше пусть этот код будет описан в одном месте, например в "Сотрудники текущего офиса", и будет использоваться потом в нескольких местах безо всяких фильтров. В противном случае все эти фильтры придется дублировать.


Хорошо, если "Текущий офис" и "Отв.сотрудник текущего офиса" в "Заявке на канцтовары" - реквизит заголовка документа.
А если "Офис" и "Отв.сотрудник офиса" в "Бюджете заказа канцтоваров по офисам" - связанные реквизиты в строке документа?

На рисунке вариант №4:
Явно разделены сторона "Форма" с настройками реквизита (слева) и описание перечней и критериев отбора (справа), водораздел между ними: 3 отношения, левые части которых выделены жирным.

Задавайте конкретные вопросы, устану расписывать :( :).

dma_caviarАнатоЛойХорошо, если "Текущий офис" и "Отв.сотрудник текущего офиса" в "Заявке на канцтовары" - реквизит заголовка документа.
А если "Офис" и "Отв.сотрудник офиса" в "Бюджете заказа канцтоваров по офисам" - связанные реквизиты в строке документа?
В смысле, что делать если нужного поля нет в документе?
Тогда или добавляем это поле в этот документ как "виртуальное поле", ну чисто для наших нужд, т.е. в таблице документа его конечно нет. Или второй вариант - ну что-то же есть в документе, например ID заявки. А справочник тогда может называться "Справочник чего-то там... для заказа канцтоваров" и в нем обязательный параметр "ID заявки на канц. товары".

нет, я вот про это:
dma_caviarесли настройщику требуется наложить фильтр на какой-то существующий справочник, значит ему просто не хватает еще одного справочника (точнее выборки на основе этого справочника). К тому же эта выборка может еще где-нибудь понадобится, так уж лучше пусть этот код будет описан в одном месте, например в "Сотрудники текущего офиса", и будет использоваться потом в нескольких местах безо всяких фильтров. В противном случае все эти фильтры придется дублировать.

В варианте №4:
- перечень "Офисы";
- перечень "Сотрудники" с реквизитом "Офис".
- выбор значения в реквизит "Сотрудник текущего офиса" может быть реализован несколькими вариантами:
- а) Критерий "Сотрудник текущего офиса" без передачи входных параметров,
текущий офис определяется внутри "Алгоритма отбора" (допустим эта переменная в сессии пользователя);
- б) если БД в каждом офисе своя, то текущий офис может быть прописан в критерии Критерий "Сотрудник текущего офиса" без передачи входных параметров, но с параметром-константой:
значение из перечня - указан нужній офис;
без возможности смены значения при вызове.
в) критерий "Сотрудник офиса" c параметром "Офис".
Если "Офис" и "Сотрудник этого офиса" реквизиты одной строки в перечне строк документа, то для реквизита "Сотрудник этого офиса" в правиле для параметра критерия "Офис" будет указан реквизит "Офис" из этой же структуры....

ф-у-у-у-у-ф.
Всё, спать :)

ViPRos, меня возьмёте? :)

dma_caviarПо идее, если настройщику требуется наложить фильтр на какой-то существующий справочник, значит ему просто не хватает еще одного справочника (точнее выборки на основе этого справочника). К тому же эта выборка может еще где-нибудь понадобится, так уж лучше пусть этот код будет описан в одном месте, например в "Сотрудники текущего офиса", и будет использоваться потом в нескольких местах безо всяких фильтров. В противном случае все эти фильтры придется дублировать.
Я провтыкал основную идею: выборка есть именованное подмножество, которым неплохо бы оперировать ка цельным новым перечнем :)
Ждите вариант N5.. :) И где LSV, я из-за кого тут распинаюсь !? :)

ViPRosАнатоЛойViPRos, меня возьмёте? :)
ты далеко и только начинаешь трудный путь к обобщениям :)
Если далеко еще могу принять за аргумент, то с обобщениями не соглашусь. В этом топике я изначально затевал процесс проектирования, а не показать некую свою наработку. У каждого в наработках есть оригинальные решения и не очень, плюсы и минусы. Вопрос этого топика для меня был актуален лет 15 назад. Решение, в разработке ядра которого я кчааствовал, живет до сих пор. Вот только я уже лет 5 как аналитик в основном, и в других областях и с другими решениями. :)

iscrafmАнатоЛойЕсли далеко еще могу принять за аргумент, то с обобщениями не соглашусь. В этом топике я изначально затевал процесс проектирования, а не показать некую свою наработку
множество лишнего вместо банальной выборки с параметром.
Может быть.... А может и нет! :).
1. Что конкретно лишнее и почему?
или
2. "Вот конкретный вариант от меня, в нём меньше того и этого, а результат тот же!"

iscrafmЛишнее все то, что сверх банальной выборки с передаваемой в нее параметром, какой тип записей отбирать в нее. Подумайте сами, если все это можно сделать банально "where st = <значение параметра> ", к тому же индексированное и т.д., то в чем смысл делать столько лишнего? Что бы кому-то показать что каким то образом домайн все же может заработать, просто нужно смирится с кучей непонятно чего.
Боюсь сделать много лишних домыслов, чтобы от "настройки банальной выборки с передаваемой в нее параметром, какой тип записей отбирать в нее" перейти к "хранения этих настроек в РСУБД". Вас не затруднит простенькую структуру набросать?

[quot LSV]Тоже задавался вопросом передачи доп. фильтра при лукапе.
Это может быть полезно, особенно если фильтр должен меняться у разных строк датасета.

Да, так и сделано: связь от "Источник значения параметра в правиле отборе" на "Реквизит в структуре данных".
При запуске выбора значение этого реквизита в форме будет взято как значение конкретного параметра критерия.

LSVУ меня в фреймворке есть возможность открывать разные формы в завис. от условия. Но это решает проблему лишь частично, т.к. плодит формы и их не может быть бесконечно много.
То бишь количество форм соттветствует количеству параметризованных критериев отбора?
Если да, то роде не страшно, и их количество таки поддаётся пересчёту комбинаторикой :).
А при подходе "выборка из перечня" сама есть новый "перечень" ещё и оценивается +- количеством узлов сбалансированного дерева с глубиной в количество реквизитов из перечня.

И, по-моему, dma_caviar так и предлагал делать (с наследованием).
Вопрос в следующем:
- какие комбинации фильтров "востребованы"? (это зависит в том числе и от конретного внедрения);
- что нужно сделать (настроить или разработать+перекомпилировать), если нужной комбинации фильтров нет.

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