Добавление представлений в базу данных поставщика и производительность

Question

У нас есть база данных, предоставленная поставщиком, и до сих пор я не мог вносить изменения в структуру базы данных. Скоро мы будем напрямую запрашивать таблицы для соответствующего проекта. Чтобы получить все необходимые данные, нам нужно создать большой оператор SQL с несколькими объединениями.

select ... from table1
union
select ... from table2
...
select ... from tableN

Скорость является высшим приоритетом для этого проекта. Будет ли быстрее создать представление для выполнения объединений, затем просто запросить это представление (и, таким образом, внести изменения в базу данных поставщиков) или просто запустить оператор объединения из нашего приложения?

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

Answer 1

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

Я не думаю, что вы увидите какой-либо выигрыш в производительности от использованияпредставление, если вы не использовали индексированное представление.К сожалению, вы не можете создавать индексы для представления, созданного с помощью объединения (по крайней мере, в SQL Server).

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

Если бы я был в вашей ситуации, я бы пошел вперед, чтобы создать представление, если это облегчит вашу жизнь.Но опять же, не ожидайте повышения производительности.

Answer 2

Нет, просмотр не будет быстрее (кроме времени разработки).

Что было бы быстрее, так это использовать UNION ALL, если он будет работать.UNION ищет дублированные записи и удаляет их из конечного результата.Если вы знаете, что записи по проекту (например, каждая таблица предназначена для отдельной клиники или каждая таблица имеет различный диапазон дат) не могут быть продублированы, UNION ALL не пытается РАЗДЕЛИТЬ набор результатов и, следовательно, работает намного быстрее.