How do you handle descriptive database table names and their effect on foreign key names?

Question

Hello,

I am working on a database schema, and am trying to make some decisions about table names. I like at least somewhat descriptive names, but then when I use suggested foreign key naming conventions, the result seems to get ridiculous. Consider this example:

Suppose I have table

session_subject_mark_item_info

And it has a foreign key that references

sessionSubjectID

in the

session_subjects 

table.

Now when I create the foreign key name based on fk_[referencing_table]__[referenced_table]_[field_name] I end up with this maddness:

fk_session_subject_mark_item_info__session_subjects_sessionSubjectID

Would this type of a foreign key name cause me problems down the road, or is it quite common to see this?

Also, how do the more experienced database designers out there handle the conflict between descriptive naming for readability vs. the long names that result?

I am using MySQL and MySQL Workbench if that makes any difference.

Thanks!

UPDATE

Received the answers I needed below, but I wanted to mention that after some testing, I discovered that MySQL does have a limit on how long the FK name can be. So using the naming convention I mentioned, and descriptive table names, meant that in two instances in my db I had to shorten the names to avoid the MySQL 1059 error

http://dev.mysql.com/doc/refman/5.1/en/error-messages-server.html#error_er_too_long_ident

Thanks again.

Answer 1

Why do you care what the FK names are? You never see them in code or use them. We also name our tables quite descriptively and commonly have names like this, using SQL Server. It doesn't matter to us, because we never seen them. They are just there to enforce data.

Answer 2

FK names are important for maintenance. Generally I only refernce the FK and the two table names, not the fields in the names. If you have named your fields correctly, it will be obvious what the fields are.