如何处理描述性数据库表名称及其对外键名称的影响？

Question

我正在研究数据库模式，并且正在尝试对表名做出一些决定。我喜欢至少有点描述性的名称，但是当我使用建议的外键命名约定时，结果似乎变得荒谬。考虑这个例子：

假设我有桌子

session_subject_mark_item_info

它有一个引用

的外键

sessionSubjectID

中的

session_subjects 

表。

现在，当我根据fk_ [referencing_table] __ [referenced_table] _ [field_name]创建外键名称时，我最终得到了这个疯狂：

fk_session_subject_mark_item_info__session_subjects_sessionSubjectID

这种类型的外键名称会不会引起我的问​​题，或者这种情况很常见？

此外，那些经验丰富的数据库设计师如何处理可读性的描述性命名与产生的长名称之间的冲突？

如果有任何不同，我正在使用MySQL和MySQL Workbench。

更新

我收到了下面我需要的答案，但我想提一下，经过一些测试，我发现MySQL确实限制了FK名称的长度。因此，使用我提到的命名约定和描述性表名，意味着在我的数据库中的两个实例中，我必须缩短名称以避免MySQL 1059错误

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

Answer 1

你为什么关心FK名字是什么？您永远不会在代码中看到它们或使用它们。我们还使用SQL Server描述性地命名我们的表，并且通常具有这样的名称。这对我们没关系，因为我们从未见过它们。他们只是在那里强制执行数据。

Answer 2

FK名称对于维护非常重要。一般来说，我只引用FK和两个表名，而不是名称中的字段。如果您已正确命名字段，那么字段将是显而易见的。

Answer 3

虽然它可能没什么区别。我会说我有两种表名。在我看来，使用长描述性表名称是过度的，当在代码中工作或甚至在命令行工作时，这些长表名称变得繁琐和乏味。我的意思是认真的，在他们正确的头脑中会有近30个字符的表名，即。 stationchangelogmasterreport。现在想象一下数据库系统中有几十甚至几百个。从开发者的角度来看，这只是愚蠢的！我的建议......考虑一下，使用缩写（当你可以的话）并保持简短和重点。例如，上面的表名可以简化为：stnchangelog，如果有人绝对需要一个解释表的每个含义和用例的大量描述，那么将此描述放在表元数据中，即。桌子上的评论。这使我们的开发人员不会发疯（并且讨厌你），并在需要时提供表格的“含义”。