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

Задача: спроектировать в системе возможность настройки удобного выбора клиента в зависимости от формы.
Условие: настройка хранится в реляционной СУБД.
Формат решения: диаграмма 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 отношения, левые части которых выделены жирным.

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