Why is using '*' to build a view bad?

Question

Why is using \'*\' to build a view bad ?

Suppose that you have a complex join and all fields may be used somewhere.

Then you just have to chose fields needed

Answer 1

No one else seems to have mentioned it, but within SQL Server you can also set up your view with the schemabinding attribute.

This prevents modifications to any of the base tables (including dropping them) that would affect the view definition.

This may be useful to you for some situations. I realise that I haven't exactly answered your question, but thought I would highlight it nonetheless.

Answer 2

I don't think there's much in software that is "just bad", but there's plenty of stuff that is misused in bad ways :-)

The example you give is a reason why * might not give you what you expect, and I think there are others. For example, if the underlying tables change, maybe columns are added or removed, a view that uses * will continue to be valid, but might break any applications that use it. If your view had named the columns explicitly then there was more chance that someone would spot the problem when making the schema change.

On the other hand, you might actually want your view to blithely accept all changes to the underlying tables, in which case a * would be just what you want.

Update: I don't know if the OP had a specific database vendor in mind, but it is now clear that my last remark does not hold true for all types. I am indebted to user12861 and Jonny Leeds for pointing this out, and sorry it's taken over 6 years for me to edit my answer.

Answer 3

Another reason why "*" is risky, not only in views but in queries, is that columns can change name or change position in the underlying tables. Using a wildcard means that your view accommodates such changes easily without needing to be changed. But if your application references columns by position in the result set, or if you use a dynamic language that returns result sets keyed by column name, you could experience problems that are hard to debug.

I avoid using the wildcard at all times. That way if a column changes name, I get an error in the view or query immediately, and I know where to fix it. If a column changes position in the underlying table, specifying the order of the columns in the view or query compensates for this.

Answer 4

Using SELECT * within the view does not incur much of a performance overhead if columns aren't used outside the view - the optimizer will optimize them out; SELECT * FROM TheView can perhaps waste bandwidth, just like any time you pull more columns across a network connection.

In fact, I have found that views which link almost all the columns from a number of huge tables in my datawarehouse have not introduced any performance issues at all, even through relatively few of those columns are requested from outside the view. The optimizer handles that well and is able to push the external filter criteria down into the view very well.

However, for all the reasons given above, I very rarely use SELECT *.

I have some business processes where a number of CTEs are built on top of each other, effectively building derived columns from derived columns from derived columns (which will hopefully one day being refactored as the business rationalizes and simplifies these calculations), and in that case, I need all the columns to drop through each time, and I use SELECT * - but SELECT * is not used at the base layer, only in between the first CTE and the last.

Answer 5

Once upon a time, I created a view against a table in another database (on the same server) with

Select * From dbname..tablename

Then one day, a column was added to the targetted table. The view started returning totally incorrect results until it was redeployed.

---

Totally incorrect : no rows.

This was on Sql Server 2000.

I speculate that this is because of syscolumns values that the view had captured, even though I used *.

Answer 6

Using '*' for anything production is bad. It's great for one-off queries, but in production code you should always be as explicit as possible.

For views in particular, if the underlying tables have columns added or removed, the view will either be wrong or broken until it is recompiled.