We have a vendor delivered database that to this point I have been able to avoid making any database structure changes to. We will be soon directly querying the tables directly for a related project. In order to pull all of the data we need, we will need to create a big SQL statement with multiple unions.
select ... from table1
union
select ... from table2
...
select ... from tableN
Speed is the utmost priority for this project. Would it be quicker to create a view to do the joins then just query this view (and thus making changes to the vendor database) or just run the union statement from our application?
I know the potential problems involved in making changes to the vendor database so thus why I am looking for feedback.
When it comes to vendor databases I would be very hesitant to make changes to any existing tables. Adding something like a view seems a little safer since you are the only one that will be using it. My biggest concern with the view would be if you ever got an update from your vendor that made changes to your DB and you might lose the view.
I don't think you'd see any performance gains from using the view, unless you used an indexed view. Unfortunately you can't create indexes on a view that is created using a union (at least in SQL Server).
Personally when it comes to putting logic in application vs putting it in the DB I lean towards DB. In my experience these types of changes are easier to deploy and maintain.
If i were in your situation I would go ahead create the view if it will make your life easier. But again, don't expect performance gains.