Как определять из каких таблиц брать данные при формировании запросов

Что проверяют

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

Как отвечать

Стройте ответ на реальном случае: задача, схема, как нашли нужные таблицы, как проверили результат. Каркас действий, на который удобно опереться:

• от требования к сущностям: переведите задачу на язык данных. «Выручка по клиентам за месяц» это клиенты, заказы, позиции и оплаты, а не одна таблица orders;
• схема и связи: ER-диаграмма в DBeaver или в панели Database в IntelliJ IDEA, внешние ключи, представления. Внешние ключи надёжнее названий;
• код как документация: JPA-сущности (@Entity, @Table, @ManyToOne, @JoinColumn) показывают, как приложение само связывает таблицы. История миграций Flyway или Liquibase объясняет, какая таблица живая, а какая осталась от старой версии;
• что приложение выполняет на самом деле: logging.level.org.hibernate.SQL=DEBUG или p6spy на похожем сценарии, готовые запросы в репозиториях;
• владелец данных: когда две таблицы похожи, спросите аналитика или команду сервиса. Это дешевле, чем неделя работы над отчётом не по той таблице;
• проверка: сверить число строк и итоги с известной цифрой, посмотреть план через EXPLAIN.

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

Где спотыкаются

Выбирают таблицу по названию. В живых базах бывают orders, orders_old и orders_v2, и актуальной оказывается не та, что звучит логичнее.

Не думают о кратности связи. JOIN заказов с позициями размножает строки заказа, и сумма по заказам выходит завышенной в разы.

Отвечают теорией нормальных форм вместо примера. На поведенческом вопросе это читается как отсутствие опыта.