Decisions decisions..

So I inherited some SSRS reports that need some updating - mostly appearance stuff.. the boss wants the reports to all have a similar look and feel.. BUT yesterday in the staff meeting it turns out he also wants me to convert the PROC datasources all into table valued functions.. because they're cooler.. (which, well, they are, but anyway..) So I open up the source of the proc and inside I find a whole bunch of #temp tables. The original author filled a series of #temp tables and them hooked them all together with unions at the end. So I am now faced with a decision - do I convert these #temp tables into: - table variables - views or - subqueries Table variables - I like doing this because it's the most similar. I don't like doing this because I have to figure out what the column datatypes all are in order to declare the table variable, and that's just tedious. Views - These are nicely reusable! BUT I highly doubt they will ever get reused, and it creates a bunch of otherwise useless objects cluttering up the list of views. Subqueries - grab the query and stick it in parenthesis where the #temp table is currently called. Gets the job done, no risk of changing the results, quick and easy, I like it. Downside is .. well, it feels kinda cheesy, plus there's a chance that one of the #temp tables may be called more than once, and a there's a few of them. I'm not an "elegant code" kind of guy, I prefer to get the job done as quickly as possible and move on. Variables have the lowest impact with the fewest chance of the unexpected. Subqueries are risky but super quick implementation if everything goes right. Views would be quick too.. probably the quickest. Clutter is less of a concern to me personally than time is, but there are other DBA's and developers here and I don't have the slightest idea how someone else might react.. making objects in a database feels like bumping somebody's shoulder in a hallway on accident. Overall though, I think views is the way to go. They're super quick both to create and to implement into the rest of the new table function, PLUS I may end up being able to reuse one later, which would be a great bonus. Views it is