Как вы обрабатываете описательные имена таблиц базы данных и их влияние на имена внешних ключей?

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, если это что-то меняет.

UPDATE

Получил ответы, которые мне нужны ниже, но я хотел бы упомянуть, что после некоторого тестирования я обнаружил, что 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, и если кому-то абсолютно НЕОБХОДИМО огромное описание, объясняющее все значения и варианты использования таблицы, то поместите это описание в метаданные таблицы, т.е. комментарии на столе. Это мешает нам, разработчикам, сходить с ума (и ненавидеть вас за это), и предлагает «значение» таблицы, если необходимо.