Co bardziej czytelne konwencje nazewnictwa dla tabel odnośników?

Question

Zawsze wymienić tabele wyszukiwania - takie jak kraje, miasta, regiony ... itp - jak poniżej:
EntityName_LK LUB LK_EntityName (Countries_LK ANI LK_Countries)
Ale pytam, czy ktoś ma więcej lepszych nazewnictwa konwersji tabel odnośników?

Edit:
Uważamy, aby przyrostek lub przedrostek rozwiązać jak konflikt:
jeśli mamy User Stoły i odnośników do UserTypes (ID-name) i mamy relację wiele do wielu między User & UserTypes które sprawiają nam stolik, który możemy nazwać go jak Types_For_User które mogą uczynić pomylenie UserTypes & Types_For_User Dlatego chcemy uczynić tabeli odnośników UserTypes być jak UserTypesLK być oczywiste dla wszystkich

Answer 1

Zanim zdecydujesz, że potrzebujesz monikera "wyszukiwania", powinieneś spróbować zrozumieć, dlaczego wyznaczasz niektóre tabele jako "wyszukiwania", a nie inne. Każda tabela powinna reprezentować jednostkę samą w sobie.

Co się dzieje, gdy tabela oznaczona jako "odnośnik" rośnie w zakresie i nie jest już uważana za "wyszukiwanie"? Pozostaje ci zmiana nazwy tabeli, która może być uciążliwa lub pozostawić ją tak, jak jest, i wyjaśnić każdemu, że dana tabela nie jest tak naprawdę "odnośnikiem".

Typowy scenariusz wspomniany w komentarzach dotyczących tabeli skrzyżowań. Załóżmy na przykład, że użytkownik może mieć wiele "typów", które są wyrażone w tabeli skrzyżowań z dwoma kluczami obcymi. Czy ten stół powinien być nazwany User_UserTypes? W tym scenariuszu chciałbym najpierw powiedzieć, że wolę używać przyrostka Member w tabeli skrzyżowań. Tak więc mielibyśmy Users, UserTypes, UserTypeMembers. Po drugie, słowo "typ" w tym kontekście jest dość ogólne. Czy numer UserType naprawdę oznacza rolę? Termin, którego używasz, może mieć znaczenie. Jeśli UserTypes są tak naprawdę Role, nasze nazwy tabel stają się Users, Roles, RoleMembers, co wydaje się całkiem jasne.

Answer 2

Każda tabela może stać się tabelą odnośników. Należy wziąć pod uwagę, że dana osoba jest odnośnikiem w tabeli faktur. Tak więc, moim zdaniem, tabele powinny być po prostu nazwane (pojedynczą) nazwą jednostki, np. Osoba, faktura.

Co ty chcesz to standard dla nazw kolumn i ograniczeń, takich jak

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

Na koniec dnia, to wszystko zależy od osobistych preferencji (jeśli można uciec z dyktując je) lub standardy drużynowe.

aktualizowane

Jeśli masz wyszukiwań, które odnoszą się tylko do jednostek, jak Invoice_Terms co jest wyszukiwanie z listy 4 scenariusze, a następnie można nazwać jako Invoice_LK_Terms które sprawiają, że pojawiają się nazwy zgrupowane pod Faktura. Innym sposobem jest posiadanie pojedynczej tabeli odnośników dla prostych wyszukiwań o pojedynczej wartości, oddzielonych przez funkcję (tabela + kolumna), do której jest przeznaczona, np.

Lookups 
Table | Column | Value 

Answer 3

Oto dwie kwestie dotyczące używania prefiksu lub sufiksu.

1. W posortowanej listy tabel, chcesz tabele Lk, aby być razem, czy chcesz, aby wszystkie tabele odnoszące się do EntityName pojawiać się razem

2. Podczas programowania w środowiskach z autouzupełniania są prawdopodobnie chcesz wpisać "LK", aby uzyskać listę tabel lub początek EntityName?

Sądzę, że istnieją argumenty na którekolwiek z nich, ale ja wybrałbym zacząć od EntityName.

Answer 4

Istnieje tylko jeden typ tabeli i nie sądzę, że istnieje jakiś dobry powód, aby wywoływać tabele tabel "wyszukiwania". Użyj konwencji nazewnictwa, która działa jednakowo dla każdej tabeli.

Answer 5

Jednym z obszarów, w którym konwencje nazewnictwa tabel mogą pomóc w migracji danych między środowiskami. Często musimy przenosić dane w tabelach odnośników (które ograniczają wartości, które mogą pojawiać się w innych tabelach) wraz ze zmianami schematu, ponieważ zmieniają się te dopuszczalne listy wartości. Obecnie nie nazywamy tabel odnośników inaczej, ale rozważamy to, aby uniemożliwić koledze migracji pytanie "które tabele są tabelami wyszukiwania ponownie?" każdego razu.