Просмотреть или хранить процедуру для сложных запросов?

Question

У меня есть несколько сложный запрос с несколькими (вложенными) подзадатами, которые я хочу сделать доступным для разработчиков приложений. Запрос общий и генерирует представление с вычисленными значениями по сравнению с набором наборов данных, и, как ожидается, разработчику потребуется только некоторые записи из того, что возвращает запрос (т.е. они ограничат результат для идентификатора какой -либо организации или диапазона дат или некоторых. такой).

Я вижу 3 способа реализации этого:

1. Пусть разработчики внедят запрос в каждое приложение и добавит свое собственное WHERE положения по мере необходимости.
2. Создайте хранимую процедуру, которая принимает в качестве параметров все условия, которые я ожидаю от разработчиков (ради аргумента, скажем, я могу предсказать, что потребуется для обозримого будущего), и процедура будет выполнять сложный запрос и фильтровать его в соответствии с принятыми параметрами.
3. Реализуйте запрос как представление с несколькими подножиями (потому что MySQL не разрешает подразделы в представлениях) и пусть разработчики используют это в качестве таблицы и используют WHERE Чтобы каждое приложение применяет необходимые фильтры. В настоящее время я смотрю на 3 дополнительных подвизах, в основном потому, что некоторые подзадачи используются несколько раз и выполняют их, поскольку подвесы предотвращает дублирование-в противном случае это могло быть хуже ;-).

Что будет лучше? (Предполагая, что вся индексация эквивалентна во всех случаях), если вы можете.

Что будет лучше в условиях обслуживания кода, как вы думаете?

Answer 1

Мне нравятся вопросы, которые определяют «хорошие» - вы специально спросили о производительности и обслуживаемости, что позволяет ответам говорить об этом компромиссе.

С точки зрения производительности, я не думаю, что между 3 вариантами может быть какая -то разница, если запросы и данные соответствуют вашим ожидаемым сценариям. Я бы проверил с более чем в 100 раз большим данным и потенциально расширял пункт «где», чтобы увидеть, что произойдет, но структура индексации и т. Д. С большей вероятностью повлияет на производительность, чем если вы выполняете один и тот же SQL из хранимой Proc, через Просмотр или из клиентского приложения.

Лучший способ ответить на этот вопрос - проверить его - конечно, есть много конкретных деталей, которые могут аннулировать общие «Ответы X, Y или Z», которые мы переполняем, можем дать. Если производительность является важной проблемой, используйте инструмент заполнения базы данных (Redgate Make On, я использовал DBMonster в прошлом) и пробую все 3 варианта.

С точки обслуживания, просмотра, я бы предоставил вариант 4, который - на мой взгляд, - безусловно, самый лучший.

Вариант 4: Создайте библиотеку доступа к данным, которая инкапсулирует доступ к вашим данным. Попросите библиотеку разоблачить методы и параметры для уточнения выбора записей. Рассмотрим использование шаблона спецификации (http://en.wikipedia.org/wiki/speciation_pattern). Используйте любые вопросы, которые лучше всего находятся в библиотеке, и не беспокойтесь о разработчиках с деталями реализации.

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

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

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

3. Взгляды: Это, наверное, лучший выбор. Он помещает конкретную логику данных в одном месте, но способствует использованию логики на основе наборов, поскольку маршрут доступа проходит через оператор SELECT, а не выполняя процедурные операторы. Виды легко включить в другие запросы.

Answer 2

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

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

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

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

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

Имея в виду, что в MySQL взгляды не являются временными таблицами, Если запрос очень сложный Эти решения не были бы лучшими, если бы запрос много использовался и по -разному (отключение повышения производительности кэша). Я бы рассмотрел временную таблицу Решение (счетчик встреч), которое обновляет каждый период времени с помощью запрограммированной задачи / cron (например, в день, неделю, когда это необходимо) или обновляется путем установки триггеров Propper. Это решение может немного улучшить производительность.

Надеюсь, это поможет, мне больше всего нравится решение View, но, возможно, это сложнее разработать с точки зрения базы данных.