[SQLRockstar]

Fair point. But how much time have I wasted trying to root out a performance problem caused by nested views disguising themselves as tables?

The tools have been failing us. Using a prefix is a way to get around those failings.

[numbsafari]

Is that really an issue?

Let's say you have identified a performance problem on a single page of a web application that lists results from a query.

Let's say you look at the code and see a complex query.

What do you do?

You use the equivalent of EXPLAIN on your DB.

It should be pretty clear at that point what objects you are dealing with.

The point of a view is that it should be interchangeable with a table logically. There are many cases I've been involved in where a view was used to either temporarily address a performance issue or address a data migration need.

If you have a naming standard that requires objects to be named a certain way, you're going to have to do a code push along with a database change that would otherwise only require a database change. That's a lot of extra testing and a lot of extra risk.

Either that or you are going to temporarily break your own rules just for that one thing. But now guess what, you've created an even bigger problem because you have trained everyone to not look at the EXPLAIN plan and instead rely on the names of the objects, and so now they'll be really confused because you've temporarily made a view "look" like a table.

In practice, this is a solution to a non-issue. YMMV.

[emp_]

This is the same as the "don't use aliases but instead tablename_id for Id fields because at 3am this will help you" type of argument (a real one, unfortunately) you should not model things around exceptions.

[mgkimsal]

and... if debugging live code on production machines at 3am is the norm, you've got much bigger problems than table prefixes.