Я вижу обе стороны вопроса. Однако, учитывая, что вы говорите, что существует всего около 40 таблиц, мне кажется, что сложность взаимодействия, скажем, с 30 другими таблицами вне вашей области знаний минимальна. Я бы проголосовал за написание запросов, которые делают сложные объединения. В конце концов, кроме знания точных столбцов в таблице, что должно быть легко, все, что вам действительно нужно знать, - это любые особые отношения или особые значения, которые используют эти таблицы.
Но другой факт, который может принять решение для меня, это каковы требования к производительности? Если система в настоящее время достаточно быстра, а размеры оборудования и таблиц таковы, что она все равно будет достаточно быстрой с использованием отдельных запросов для каждой таблицы, сделайте это, используя второй подход, если это облегчит жизнь всем. Но с другой стороны, если кто-либо когда-либо жаловался на скорость, или если таблицы могут расти без ограничений в будущем, или число ваших пользователей увеличится, сделайте это с помощью метода, который У меня самая большая надежда на то, чтобы быть быстрее.
ОТВЕТ НА КОММЕНТАРИЙ: Не обязательно. Скажем, в продуктовый модуль добавлено 5 новых столбцов. Либо вы уже не использовали их и, следовательно, не присоединялись к ним и не извлекали их, и на вас это не влияло бы, независимо от того, какой метод вы выбрали, или они вам нужны и вам нужно написать новый код для того, как с ними обращаться. В любом случае, изменения на вашей стороне будут такими же, какой бы метод вы ни выбрали. Скажем, модуль Продукт переименован или удален 3 столбца. Тогда вашей стороне придется изменить способ обработки возвращаемых значений, независимо от того, как был написан интерфейс. Я понимаю, к чему вы клоните, но суть в том, ИМХО, что если вы используете поля, связанные с изменением, вы должны внести изменения в код. Если поля не используются вами, вы не делаете. Упомянутый вами «волновой эффект» не должен существовать, если вы выбираете только нужные столбцы, а не select * from tbl запросов.