When I create a table, I will often (but not always!) use a surrogate key, an auto_increment or identity column as the primary key. I always give this column the name ID. Then, when it's time to reference this primary key in a foreign key somewhere, you cannot call the foreign key ID, too, because that would clash with the primary key ID in that table. Therefore all foreign keys are called Entity_ID, where "Entity" is formed from the table name of the table it's referencing. This allows you to have a table containing several foreign keys, each named differently, each identifying the table it's referencing. So you can have a SalesTransaction table, with an ID primary key and foreign keys Cust_ID (referencing the Customers table ID key), Prod_ID (referencing the Products table ID key), and so on.

Other than that, no other columns should have a prefix as part of the column name to identify the table. This means that a lot of tables have columns like NAME, STATUS, DATE_UPDATED and so on.

This also means that you would never use a NATURAL JOIN because it would join on the wrong columns. But with a prefix scheme, you wouldn't use a NATURAL JOIN either, because it would join on no columns.

Without a prefix scheme, you need to be careful when writing a join; be sure to qualify each column using either the table name or a table alias. But this is self-documenting, and, on balance, qualifying column names used in a join by their table name or table alias is a good thing. Besides, even with a prefix scheme, you will still have to qualify some columns -- the foreign keys!