Здравствуйте,
собственно требуется совет по архитектуре, ибо хочется сделать как надо а в голову приходит только то что не нравится.

Итак суть проблемы: нужно найти информацию в БД и показать результат в таблице. При этом поиск осуществляется по разным типам запросов (для наглядности скажем люди ищутся по ФИО или по номеру мобильного). В базе сохраняются сами "запросы": есть таблицы "Запрос_по_фио" и "Запрос_по_телефону", где грубо говоря номер запроса и дата. Номера запросов в разных таблицах могут совпадать! Далее эти таблицы связаны ну скажем с таблицей "Человек" отношением n->1 ну и т.д. В коде есть Enum класс, который имеет типы запросов (опять же скажем "ПО_ФИО", "ПО_ТЕЛЕФОНУ", "ВСЕ").
И вот надо показать когда какой запрос был добавлен: скажем 17.02.2017 запрос №111 на человека Иванов Иван у которого телефонный номер 1234567. Я делаю это довольно долгим селектом с кучей JOIN (ну в жизни все сложнее чем в моем примере) и маплю это в Entity класс. Это выглядит так:


Причем для разных типов запросов все работает обычным UNION внутри SQL. Нечто подобное внутри запроса:
Select a.Number, p.Name from request_A a LEFT JOIN Person p ON...
UNION
Select b.Number, p.Name from request_B a LEFT JOIN Person p ON...

Внимание вопрос: в итоговой таблице надо показать тип запроса! Вообще это сделать довольно элементарно. Добавить в мои выборки "'Request_Type_A' as 'RequestType'" и "'Request_Type_B' as 'RequestType'" соответственно. Далее стринговое поле в мою Entity и готово - в таблице показывать что угодно смотря по тому что там в этой переменной. НО решение ужасно ибо получается что и в SQL и в Entity в итоге будут какие-то "волшебные названия запросов" закодированы, при том что уже есть Enum, и, кроме того, при дальнейшем расширении это все тоже некрасиво. Итак есть дикое желание прикрутить в запросы Enum и мапить ответы сразу же с полем Enum без жестко закодированных текстовых значений. Такое возможно?

Пока лучшее что приходит в голову это ввести Enum в это самое поле Entity, разбить запрос на несколько (вместо UNION) и после каждого из них самому выставлять значение Enum внутри Entity. Будет работать конечно, но тоже не сказать что душа лежит. Вот думаю отмапить бы сами Entity в базе... Вроде сейчас время есть захотел покопаться:)
Извиняюсь если не очень понятно - по сути все просто только вот я не знаю смог ли наглядно объяснить хоть букв и очень много извел

Всем заранее спасибо!

Petro123То добавка ... типа запроса ... совсем неплохое решение.
Либо убирайте UNION
Я собственно так и сделал - решение самое очевидное и напрашивающееся, но мне эти вот "первый тип", "второй тип" прям жуть как глаза мозолят:(
Убрать UNION тоже можно и это уже лучше пожалуй, хотя писать чуть дольше. Все равно в идеале хотелось бы нечто вроде
Select Enum.TzpeA as type, ...
но вот насколько я погуглил хоть ты индексы сохраняй хоть значения стринговые - ничего не короче и не удобнее небольшой модификации SQL получается. Тот же хардкод там или сям и те же силы при расширении.


BlazkowiczИ для чего такие сложности?
Хотят видеть в таблице когда к ним какие запросы падали по дате. Сразу для всех запросов вместе а уж дальше фильтровать коли надо.


Сергей АрсеньевЭто не одинаковые запросы (Ибо UNION это не UNION ALL)
Да совершенно согласен. Там у меня на самом деле уже "с параметром" как уважаемый Petro123 предложил, так что UNION годится - выборка всегда разная.

Ну словом вроде лучшее решение (до которого я смог дойти по крайней мере) выкинуть к чертям этот UNION - сделать запрос к одному "типу запроса" и потом в полученный лист проставить Enum. Потом повторить для второго и поставить ему соответственно другой Enum. Потом все слить.
На выходи будет лист<Entity>, в которой есть все что нужно влючая тип запроса уже в форме Enum, с которым впоследствии при отображении будет куда удобнее.
Думаю оптимально по скорости, наглядности и удобству обслуживания.

Но коли кто-то знаком с лучшими практиками буду очень признателен за инфу! Спасибо всем еще раз.

BlazkowiczНу, обычный лог запросов. Какое он отношение имеет к процессу поиска? А что делать если захочется искать и по имени и по телефону?

Ну нет тут я немного упростил. Речь же не о "свободном поиске". В жизни это официальные запросы и речь идет о банковских операциях. Сохраняются именно все эти запросы с их номерами и датами чтобы отслеживать своевременность ответов помимо прочего. Официальные запросы они стандартизированы, так что "вдруг захочется" тут не будет, хотя всякие изменения в жизни возможны. Я вот как раз с расширением и столкнулся, отчего и забудмался...