Усиливает ли комплексные соединения большие проблемы с соединением и обслуживанием?

Question

Наш проект имеет ~ 40 таблиц со сложными отношениями. Коллега верит в использование длинных запросов на объединение, которые заставляют меня узнавать о таблицах вне моего модуля, но я думаю, что я не должен относиться к таблицам, не связанным напрямую с моим модулем, и использовать доступ к данным функции (написанные теми, кто отвечает за другие модули), когда мне нужны данные из них. Позвольте пояснить:

Я отвечаю за модуль ContactVendor, который позволяет клиентам связаться с поставщиком и начать разговор о каком-то конкретном продукте. Модуль продуктов имеет собственные сложные таблицы и отношения с функциями, которые инкапсулируют детали (например, i18n, активация, доступность продукта и т. Д.). Теперь мне нужно показать название продукта какого-либо продукта, связанного с некоторой беседой между продавцом и клиентами. Я могу либо написать длинный запрос, который извлекает информацию о продукте вместе с материалами беседы одним выстрелом (который принуждает меня узнать о таблицах продуктов). Или я могу передать соответствующий product_id функции get_product_info (int).

Первый подход, очевидно, требует и вводит много плохих практик и вещей, которые я обычно рассматриваю как недостаток в программировании. Проблема со вторым подходом, по-видимому, заключается в бесчисленных мини-запросах, вызванных этими функциями доступа, и потеря производительности вызывает беспокойство, когда цикл пытается получить заголовки продуктов для 100 продуктов, используя функции, каждый из которых выполняет отдельный запрос. Поэтому я застрял между «не кодовым кодом реализации, кодом для интерфейса» и производительностью. Каков правильный способ делать вещи?

ОБНОВЛЕНИЕ: меня особенно беспокоят возможные будущие изменения этих таблиц за пределами моего модуля. Что, если модуль «Продукты» решил изменить то, как они это делают? или по какой-то причине изменить схему? Это означает, что некоторые другие модули сломаются или будут работать неправильно, пока изменения не будут интегрированы в них. Обычная проблема эффекта пульсации.

Answer 1

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

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

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

Answer 2

Как насчет работы с видами здесь?

Вместо вызова функции get_product_info сделайте, чтобы каждый поддерживающий модуль предоставлял представления этому модулю, например product_info_view, а затем использовал это представление с вашим запросом. Как и вам, вам не нужно заботиться о внутренних (таблицах) такого представления, но все равно получите преимущество в производительности, так как механизм datbase упростит окончательный запрос, содержащий ваш код и представление.

Answer 3

Правильный способ создания такого рода материалов (Persistence/Data Source/ORM) очень хорошо описан Мартином Фаулером в его удивительной книге «Шаблоны архитектуры корпоративного приложения». Книга ДОЛЖНА читать для всех в области развития предпринимательства.