What's a more natural column name for Tables whose name share a column name? I have a database that's used by an ASP.NET MVC project through EntityFramework. Currently there are some tables that have columns with the same name, i.e. 

CREATE TABLE HairColor(
    HairColorID int IDENTITY CONSTRAINT PK_HairColor PRIMARY KEY
    ,HairColor varchar(15) NOT NULL
)


but once EF goes through its thing it changes the HairColor property to HairColor1 because classes can not have properties which share its name.

So my question is, what would be better: HairColor.Name or HairColor.Color?
Personally, I usually like my column names to be meaningful, as it makes it easier to follow in queries. I can see Scotts Hodgin's point, certainly, but you could end up with a query that looks like:

SELECT cust.full_name
      ,stat.name
      ,type.name
      ,clhd.name
      ,src.name
....


Of course, good table names or aliases can ameliorate my complaint (even in my example, you can take a stab at what these things might be). However, (again, for me) having to use 20 different columns with the same name in a query can make it easier to use the wrong one in the wrong place, and can make it harder to catch. I'd rather see:

SELECT cust.full_name
      ,stat.status
      ,type.cust_type
      ,clhd.reason
      ,src.source
....


Again - I'm presenting my perspective - this is really something that is a matter of personal taste.

It is a good idea to ask a team to be consistent. If you're the team lead, you can either dictate (your preference wins), take a vote (if most people want one option, then compliance with that option should be better), or ignore it (leading to the best chance of confusion for all).