>Here comes the other position. I follow the relational design principle that if two fields in two tables share the same domain they should have the same name

That's how I used to feel, too. It's similar to having a class called Foo, for example and calling a method Print() instead of PrintFoo(). Furthermore, the approach you're talking about takes less typing. :)

However, I do think that table prefixes are necessary. If you have a foreign key, it's nice to be able to unambigously generate it from the names of the tables involved.

>I don't worry about aliasing in SQL because I would alias even if I didn't have to to make the SQL self documenting for me in 6 months when I don't remember which table has the prefix fgc_.

The prefix approach makes the SQL self-documenting automatically. But I admit that my apps don't have a large number of tables, where selecting memorable prefixes would be difficult.