Я работал с большой системой, использующей префиксы. Своеобразно, но особых ужасов и неудобств не заметил - к единообразию привыкнуть легко. Так что все аргументы "удобно-неудобно", "путанее/распутанее" - дело привычки.

Технически, преимущество одно: уникальность имени атрибута в системе. То есть, из какого бы запроса не приехал атрибут, на клиенте всегда однозначно ясно, что это и откуда.

Нужно ли это, и важно ли это в большинстве обычных систем? Пожалуй, не особенно.

Однако в той системе это было важно и нужно, поскольку на имя атрибута клиентская библиотека сразу автоматически навешивала приятную функциональность из словаря метаданных. То есть, там применялись элементы "програмирования через метаданные", и это было удобно.

Кстати, большинство SQL-запросов там тоже генерились автоматически, так что вопрос (не)удобства их составления отпадал сам собой.

Теперь о суровых мерах, которые пришлось принять, чтобы эту идею довести до работоспособного логического завершения:

1. Каждой таблице должен соответствовать префикс. Минимальной длины (3-4) символа, но максимальной мнемоничной понятности. Уникальный в пределах БД.

(Кстати, эта идея - сопоставить длинному, понятному имени таблицы "технический", сокращенный префикс, и использовать его в именовании связанных объектов, не нова, и предлагается, например, здесь: Oracle Naming Conventions . Правда, там его используют в именах ключей, а для полей не рекомендуют. Но сама идея, и принцип составления заслуживают внимания).

Так вот, в именах полей используется именно этот префикс.

Как вариант, сами таблицы можно поназывать разумно-покороче, и использовать их имена как префиксы. Понятно, это для небольших БД.

2. Формализуем названия полей для внешних ключей. Если ссылка между таблицами ровно одна - название полей с обеих сторон (1 и N) ключа одинаково. Если ссылок больше - к полям на стороне "N" добавляются смысловые суффиксы, например "_X", "_Y".

3. Формализуем именование алиасов, если таблица участвует в запросе более одного раза. Суть в том, что каждый такой "раз" получает уникальный смысловой суффикс (он же алиас таблицы в запросе, например "_PARENT", "_CHILD"), и все поля из этого экземпляра таблицы получают в своих алиасах в добавку к своим именам этот суффикс.

Мое мнение: можно жить и с этим, и без этого. Включение префиксов таблиц в имена полей позволяет двинуть систему в сторону "пусть безобразно, но единообразно". Если это вызвано какими-то дополнительными требованиями, например, использованием метаданных, или автоматической генерацией SQL, - то это может быть оправдано технически. Если нет - то может порадовать разве что любителей "военного" порядка в БД, в ущерб "книжной" наглядности.

Об авторитетных мнениях. Скандально известный Джо Селко в обсуждении этого вопроса сначала ссылается на некий ISO-11179 который требует уникальности имени скалярного атрибута в пределах всего словаря (то есть как-бы за префиксы). Затем разбивает эту идею в пух и прах в главе "Избегайте описательных префиксов". Впрочем, разбивает скорее эмоциями, чем доводами.

А вот система приверженца префиксов: link , тоже достаточно стройная.

softwarerБоюсь, эта идея растёт на 99% из устаревшего ораклового ограничения идентификатора в 30 байт. Оно не составляет заметной проблемы, когда мы придумываем названия для полей и таблиц, но иногда неприятно стреляет, когда генерируем имена для вторичных объектов (скажем, FK_TABLE1_TABLE2 уже запросто может нарушить это ограничение).

Возможно. Но, возвращаясь к Оракловому примеру, (таблицы у них называются APPLICATION_FUNCTIONS и APPLICATON_FUNCTION_ROLES), если даже воображаемое имя ключа "APPLICATION_FUNCTIONS_APPLICATON_FUNCTION_ROLES_FK" и будет допустимо по длине, то многие предпочтут все же скромный APFU_APPL_FK. Тем более - его, скорее всего, ни читать, ни набирать часто не придется, а лишь иногда поискать "ой, что это нарушилось?".