Что является более читаемым соглашением об именах для таблиц поиска?

Question

Мы всегда называем таблицы поиска - такие как Страны, Города, Регионы ... и т. Д. - как показано ниже:
EntityName_LK ИЛИ LK_EntityName (Страны_ЛК ИЛИ ЛК_Страны)
Но я спрашиваю, есть ли у кого-то более подходящие преобразования имен для таблиц поиска?

Редактировать
Мы думаем сделать постфикс или префикс для решения как конфликт:
если у нас есть User таблицы и таблица поиска для UserTypes (ID-Name), и у нас есть отношение многие ко многим между User & UserTypes, которые делают нас таблицей, которую мы можем назвать как Types_For_User может привести к путанице между UserTypes & Types_For_User Так что нам нравится делать справочную таблицу UserTypes, чтобы она была похожа на UserTypesLK, чтобы была очевидна для всех

Answer 1

Прежде чем вы решите, что вам нужен прозвище «поиск», вы должны попытаться понять, почему вы определяете некоторые таблицы как «поиски», а не другие. Каждая таблица должна представлять собой сущность.

Что происходит, когда таблица, которая была обозначена как «поиск», расширяется в объеме и больше не считается «поиском»? Вам либо нужно изменить имя таблицы, которое может быть обременительным, либо оставить все как есть и объяснить всем, что данная таблица на самом деле не является «поиском».

Общий сценарий, упомянутый в комментариях к соединительной таблице. Например, предположим, что пользователь может иметь несколько «типов», которые выражаются в соединительной таблице с двумя внешними ключами. Должна ли эта таблица называться User_UserTypes? В этом сценарии я бы сначала сказал, что предпочитаю использовать суффикс Member в таблице соединений. Таким образом, у нас будет Users, UserTypes, UserTypeMembers. Во-вторых, слово «тип» в этом контексте довольно общее. UserType действительно означает Роль? Термин, который вы используете, может иметь значение. Если UserTypes действительно являются ролями, то имена наших таблиц становятся Users, Roles, RoleMembers, что кажется вполне понятным.

Answer 2

Вот два вопроса о том, использовать ли префикс или суффикс.

1. В отсортированном списке таблиц: хотите ли вы, чтобы таблицы LK были вместе, или вы хотите, чтобы все таблицыотносящиеся к EntityName для отображения вместе

2. При программировании в средах с автозаполнением, вы, вероятно, захотите набрать "LK", чтобы получить список таблиц или начало EntityName?

Я думаю, что есть аргументы для обоих, но я бы предпочел начать с EntityName.

Answer 3

Каждая таблица может стать таблицей поиска.Учтите, что человек - это поиск в таблице счетов.Так что, по моему мнению, таблицы должны просто называться (единичными) именами сущностей, например, Person, Invoice.

То, что вы хотите, это стандарт для имен столбцов и ограничений, таких как

FK_Invoice_Person (in table invoice, link to person)
PersonID or Person_ID (column in table invoice, linking to entity Person)

В конце концов, все зависит от личных предпочтений (если вам это удается диктовать) или от командных стандартов.

обновлено

Если у вас есть поиски, которые относятся только к сущностям, таким как Invoice_Terms, который является поиском из списка 4 сценариев, то вы можете назвать его как Invoice_LK_Terms, который сделает его отображаемым по имени, сгруппированному в Invoice.Другой способ - создать единую таблицу поиска для простых поисков с одним значением, разделенную функцией (таблица + столбец), для которой она предназначена, например,

Lookups
Table | Column | Value

Answer 4

Одной из областей, в которых могут помочь соглашения об именах таблиц, является миграция данных между средами. Нам часто приходится перемещать данные в таблицах поиска (которые ограничивают значения, которые могут появляться в других таблицах) вместе с изменениями схемы, так как эти списки разрешенных значений меняются. В настоящее время мы не называем таблицы поиска по-другому, но мы рассматриваем это, чтобы парень миграции не спросил: «Какие таблицы снова являются таблицами поиска?» каждый раз.

Answer 5

Существует только один тип таблиц, и я не верю, что есть веская причина называть некоторые таблицы таблицами поиска.Используйте соглашение об именах, которое одинаково работает для каждой таблицы.