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

Question

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

Suppose I have a table

session_subject_mark_item_info 

And it has a foreign key that refers to

 sessionSubjectID 

in

 session_subjects 

Table.

Now, when I create the foreign key name based on fk_ [referging_table] __ [referenced_table] _ [field_name], I end this madness:

 fk_session_subject_mark_item_info__session_subjects_sessionSubjectID 

Will this type of foreign key name cause me problems in the future, or is it pretty common to see this?

Also, how do more experienced database developers deal with the conflict between descriptive names for readability compared to long names?

I use MySQL and MySQL Workbench, if that matters.

UPDATE

Got the answers I need below, but I wanted to mention that after some testing, I found that MySQL has a limit on how long the FK name can be. Thus, using the naming convention I mentioned and descriptive table names meant that I had to shorten the names in two copies of my db to avoid MySQL 1059 error

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

Answer 1

Why are you worried about FK names? You never see them in code or use them. We also wrote our tables quite descriptively and usually have such names using SQL Server. This is not important for us, because we have never seen them. They are there to enforce data.

Answer 2

FK names are important for maintenance. Usually I refer only to FK names and two tables, and not to fields in the names. If you correctly named your fields, it will be obvious what fields are.

Answer 3

Although it probably doesn't matter. I will say that I had table names in both directions. And, in my opinion, using long descriptive table names is redundant, and when working in code or even on the command line, these long table names become burdensome and tedius. I mean seriously, who in their right mind would have almost 30 characters the name of the table, that is. stationchangelogmasterreport. Now imagine dozens or even hundreds of them in a database system. from the point of view of the developers, this is just silly! My recommendation ... think about it, use abbreviations (when you can) and keep them short and precise. for example, the specified table name can be shortened to: stnchangelog, and if someone absolutely NEEDS to get a huge description explaining each value and use case for the table, then put this description in the table metadata, i.e. comments on the table. This makes us developers go crazy (and hate you for it), and if necessary offers the "meaning" of the table.