Database Table and ID Naming

Database, Tables and Fields should have clear, understandable and functional names. I think all programmers agree on that. But I'm not sure that all are agree in same standards.

Database name can be anything unless it's not a copy of other. But it's the easiest one.

Lets think about table names. Although you are completly free in naming, you should allways think that one day, another stranger will have to continue coding your programs. Or even you will forget how you did something. Believe me, may be you would have full control in your first 4-5 programs but then you will loose your control. When it happens, "standards" are the life saver.

You may notice that there are some naming standards for variables, file names, table names, field names etc. I admit that most of them OK, but I have an objection to data table field namings in some point. Especially ID Fields. I am developing database applications nearly 20 years. In a large databases with more than 200 tables ID fields must be more specific. if you have just 10-20 tables you may understand anything with a quick look. But with 200 table it may be hard to follow tables.

This is my way of naming ID Fields. May be it's useful for you too. Actually it never let me down in 20 years.
Rule 1 : Name of the ID field in the table itself is "ID". Every single table has a field as ID. (only in few exceptions, you may not need ID field)
Rule 2 : A reference to an ID field of an other table must be named as TableNameID
Example
Assume there are two tables like Profile and Country.

Profile	Country
ID	ID
CountryID	CountryName
FirstName

In this way when you look for at the profile table you see there is a link to an ID field in Country table easily and also when you will write an SQL sentence it's easy to remember the connection.
Like
SELECT * FROM Profile INNER JOIN Country ON Profile.CountryID = Country.ID

(We will mention how useful are the uppercase lowercase syntax later. )
if the connection with the tables is one to one or one to many this will be very easy to find. We'll mention many to many connections later.

I don't know why but it's not the Microsoft way. I think this is more logical than their namings .

When it comes to table names,  mostly related tables should begin with the same way. So that when you look at the database you could see them together. I will explain my way. It may enlight your vision.

First I decide which modules I need. For example if I use accounting, operation and crm modules in a program, I simply determine shortnames for them
Accounting -> acc
Operation -> opr
CRM -> crm
and also I'll need some  base modules which can be defined as prg

Now I name the tables like
accCurrency
accCurrencyRate
accAccount
accAccountHistory
oprTask
oprTaskAssignment
crmProfile
crmProfileDetail
prgParameters
In this way when you browse tables in SQL Management Studio your close related tables follow each other.
Also you can find accounting related tables easily.

I'll be happy for any comments or questions.