Database naming conventions.

I only do this routinely when the same data could be found in other tables, to make it clear that it is from another table. The most common example would be naming ID columns as [Table]Id instead of just Id. I have used just Id in the past as the ID column and regretted it.

I might also do this when the column name I want to use is a reserved word, either in SQL or the programming language. Sometimes I can find an alternative name, but other times it just makes sense to prefix the table name and move on.

Generally though, I try to stick to the shortest descriptive name I can come up with.

I've tried it, and usually regret it. I'm not sure what's "good practice", or who gets to define that, but I'd rather read (and type):

Ponies::CutieMark
Avengers::Snarkiness

...than

Ponies::PonyCutieMark
Avengers::AvengerSnarkiness

If you believe in normalization of your databases, you probably want your tables to more-or-less roughly map to your concepts. For me, this means that they also map to the way I speak about those concepts. I don't say "I want the Cars Carname", I say "I want the Cars Name".

There is one exception, which would be if you're forced to use a non-normalized table but include a lot of related concepts (this happens to me a lot in FileMaker). So, for example:

Cars::Model
Cars::Make
Cars::_VendorName
Cars::_VendorID

But, as you can see, the caveat only really applies to non-normalized data (for me, at least).

It's redundant. If you need to distinguish a.type from b.type in a query or view, that's what aliasing is for.

I don't use prefixes, just a convention in which if the model is named Car, the table is named cars. I think prefix are redundant...