Assume you can refer to a field of a row with tablenam.fieldname, eg customer.id or customer.name is of course good, but so is customers.id or customers.name...
You mostly use a table name within SQL, and select ... from customers seems more natural to me.
One other thing I'd avoid is two names of tables or fields that are identical besides case, as there still are and will be languages that don't differentiate this.
Regarding tye prefix: It's true you can read this from meta data, but source code is for the prorammer, not the program, if you read and work on code you don't take a look at the meta data of a table. Tables are normally out of the scope for such things as intellisense, so as a programmer your clue about the field type is a type prefix.
Regarding keeping apart field names and variable names, a variable also has different scopes, I normally have two prefixes of scope and type for a variable. With table fields, the scope is the table, I don't have that prefix. Readability is given by CamelCase or underlines. Don't give the argument it's more typing, it's one character. If you're lazy at typing, intellisense should jump in, otherwise you will also be tempted to use abbreviations and names not descriptive enough.
Bye, Olaf.