Java веб-приложение и дизайн базы данных

Question

Я разработал веб-приложение рабочего потока на Java с серверной частью Oracle. Рабочий процесс требует от пользователя заполнить серию контрольных списков.
Я запустил проект, используя 2 таблицы для каждого контрольного списка - одну таблицу для хранения вопросов и другую для хранения ответов.

Но руководство продолжает просить больше контрольных списков, поэтому я изменил свой подход к БД (ниже). Я хотел бы знать, хорош ли этот подход, или я готовлюсь к неприятностям в будущем. Я нахожусь в процессе рефакторинга всего приложения, потому что оно не следовало подходу MVC. Теперь настало время исправить любые проблемы с базой данных.

Вот мой новый подход:

таблица:

CHECKLIST_CLASS - сохранить тип контрольного списка, т.е. контрольный список аудита качества, контрольный список аудита процесса
CHECKLIST_INSTANCE - проверяемый список пользователей. хранить FK checklist_class_id, work_flow_id
CHECKLIST_ANSWER - хранит check_list_instance_id, FK question_id, множественный выбор ответа
CHECKLIST_QUESTION - хранит вопрос_идентификатора, FK контрольного_класса_id

Мне нравится этот подход, потому что я могу динамически добавлять новый контрольный список без добавления другой таблицы БД.
но это делает запросы немного сложнее, когда требуется определить статус каждого контрольного списка в рабочем процессе.

 SELECT TO_CHAR(CALCDATEREQUIRED, 'MM/DD/YYYY') as CALCDATEREQUIRED, 
        TO_CHAR(CALCAPPROVEIPRDATE, 'MM/DD/YYYY') as CALCAPPROVEIPRDATE, 
        (SELECT SECTION_I_STATE FROM TPQOT_CALC_MODEL WHERE CHECKLIST_INSTANCE_ID = 
            SELECT MAX(TPQOT_CHECKLIST_INSTANCE.CHECKLIST_INSTANCE_ID) FROM TPQOT_CHECKLIST_INSTANCE 
            WHERE TPQOT_CHECKLIST_INSTANCE.CHECKLIST_CLASS_ID='1257877690209' AND 
            TPQOT_CHECKLIST_INSTANCE.CALC_ID=CALCID AND 
            TPQOT_CHECKLIST_INSTANCE.CALC_REV=CALCREV)  ) AS SECTION_I_STATE, 
        (SELECT CHECKLIST_STATE AS FINALIZE_CHECKLIST_STATUS FROM TPQOT_CHECKLIST_INSTANCE WHERE CHECKLIST_INSTANCE_ID = 
            (SELECT MAX(TPQOT_CHECKLIST_INSTANCE.CHECKLIST_INSTANCE_ID) FROM TPQOT_CHECKLIST_INSTANCE 
            WHERE TPQOT_CHECKLIST_INSTANCE.CHECKLIST_CLASS_ID='1257877690209' AND 
            TPQOT_CHECKLIST_INSTANCE.CALC_ID=CALCID AND 
            TPQOT_CHECKLIST_INSTANCE.CALC_REV=CALCREV)  ) AS DI4630901_STATE, 
        (SELECT CHECKLIST_STATE AS FINALIZE_CHECKLIST_STATUS FROM TPQOT_CHECKLIST_INSTANCE WHERE CHECKLIST_INSTANCE_ID = 
            (SELECT MAX(TPQOT_CHECKLIST_INSTANCE.CHECKLIST_INSTANCE_ID) FROM TPQOT_CHECKLIST_INSTANCE 
            WHERE TPQOT_CHECKLIST_INSTANCE.CHECKLIST_CLASS_ID='1257877670188' AND 
            TPQOT_CHECKLIST_INSTANCE.CALC_ID=CALCID AND 
            TPQOT_CHECKLIST_INSTANCE.CALC_REV=CALCREV)  ) AS OPC_STATE, 
        (SELECT phonebook.lname FROM phonebook WHERE phonebook.badge = xtbl463Calc.CalcOriginator) AS OrigName, 
        (SELECT phonebook.lname FROM phonebook WHERE phonebook.badge = xtbl463Calc.CalcChecker) AS CheckName, 
        (SELECT phonebook.lname FROM phonebook WHERE phonebook.badge = xtbl463Calc.CalcReviewer) AS ReviewName, 
        (SELECT phonebook.lname FROM phonebook WHERE phonebook.badge = xtbl463Calc.CalcApprover) AS ApproveName 
        FROM xtbl463Calc ORDER BY CALCID;

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

Answer 1

Я не вижу много неправильных в структуре таблицы, если я правильно понял ваше описание, она хранит структуру, которую она должна хранить.

Запрос с другой стороны выглядит слишком сложным.

В запросах много запросов, которые просто не могут быть правильными.Здесь я вижу три варианта:

1. Проверьте, нужен ли вам этот запрос вообще.Вы действительно должны одновременно отображать подробный статус всего?
2. Проверьте, можете ли вы каким-то образом упростить свой запрос, исключить или объединить его части, заменить внутренние выборки соединениями, что угодно.В запросе много повторений, поэтому его можно упростить.
3. Разбейте запрос на несколько меньших запросов, которые выполняются один за другим.Например, часть запроса в телефонной книге почти наверняка может быть выполнена отдельно от основного запроса.

При вариантах 2 и 3 подопция должна учитывать использование представлений.

И, наконец, возникает вопрос о включении результата в список хэш-карт.Я, очевидно, не знаю временных ограничений, в течение которых вы работаете, но если вы можете себе позволить время, я настоятельно рекомендую создавать POJO для хранения результатов, а не помещать их в хэш-карту.