Quali sono le convenzioni di denominazione più leggibili per le tabelle di ricerca?

Question

Abbiamo sempre citarne tabelle di ricerca - come Paesi, città, regioni, ecc ... - come di seguito:
EntityName_LK O LK_EntityName (Countries_LK O LK_Countries)
Ma mi chiedo se uno ha più migliori conversioni di denominazione per le tabelle di ricerca?

Edit:
Pensiamo di fare suffisso o un prefisso di risolvere come un conflitto:
se abbiamo User tavoli e tabella di ricerca per UserTypes (ID-Name) e abbiamo una relazione molti a molti tra User & UserTypes che un tavolo cui possiamo chiamarla come Types_For_User che può rendere confusione tra UserTypes & Types_For_User Così ci piace rendere tabella di ricerca UserTypes di essere come UserTypesLK essere evidente a tutti

fare

Answer 1

Prima di decidere è necessario il moniker "lookup", si dovrebbe cercare di capire perché si stanno designando alcune tabelle come "lookups" e non altri. Ogni tabella dovrebbe rappresentare un'entità a sé.

Cosa succede quando una tabella che è stata designata come "ricerca" cresce nell'ambito e non è più considerata una "ricerca"? O sei lasciato a cambiare il nome della tabella che può essere oneroso o lasciare così com'è e dover spiegare a tutti che una determinata tabella non è realmente una "ricerca".

Uno scenario comune menzionato nei commenti relativi a una tabella di giunzione. Ad esempio, supponiamo che un utente possa avere più "tipi" che sono espressi in una tabella di giunzione con due chiavi esterne. Questo tavolo dovrebbe essere chiamato User_UserTypes? In questo scenario, vorrei prima dire che preferisco usare il suffisso Member sulla tabella di giunzione. Quindi avremmo Users, UserTypes, UserTypeMembers. In secondo luogo, la parola "tipo" in questo contesto è piuttosto generica. Un UserType significa davvero un ruolo? Il termine che usi può fare la differenza. Se UserTypes sono davvero ruoli, i nomi delle nostre tabelle diventano Users, Roles, RoleMembers che sembra abbastanza chiaro.

Answer 2

Ogni tabella può diventare una tabella di ricerca. Si consideri che una persona è una ricerca in una tabella delle fatture. Quindi, a mio parere, le tabelle dovrebbero essere chiamate solo il nome dell'entità (singolare), ad es. Persona, fattura.

ciò che si desidera è uno standard per i nomi delle colonne e dei vincoli, come ad esempio

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

Alla fine della giornata, è tutto fino a preferenze personali (se si può ottenere via con dettare essa) o standard di squadra.

aggiornato

Se avete le ricerche che riguardano solo agli enti, come Invoice_Terms che è una ricerca da un elenco di 4 scenari, allora si potrebbe nominare come Invoice_LK_Terms che renderebbe apparire per nome raggruppate sotto Fattura. Un altro modo è di avere una singola tabella di ricerca per semplici ricerche a valore singolo, separate dalla funzione (tabella + colonna) per, ad es.

Lookups 
Table | Column | Value 

Answer 3

Qui ci sono due dubbi se utilizzare un prefisso o suffisso.

1. In un elenco ordinato di tabelle, vuoi le tabelle LK per stare insieme o volete tutte le tabelle relative alle EntityName ad apparire insieme

2. Quando si programma in ambienti con completamento automatico, sono è probabile che vogliate digitare "LK" per ottenere l'elenco di tabelle o l'inizio di EntityName?

Penso che ci siano argomenti per entrambi, ma vorrei scegliere di iniziare con EntityName.

Answer 4

C'è un solo tipo di tabella e non credo ci sia una buona ragione per chiamare alcune tabelle di "ricerca" tabelle. Utilizzare una convenzione di denominazione che funzioni allo stesso modo per ogni tabella.

Answer 5

Un'area in cui le convenzioni di denominazione delle tabelle possono aiutare è la migrazione dei dati tra gli ambienti. Spesso è necessario spostare i dati nelle tabelle di ricerca (che vincolano i valori che possono apparire in altre tabelle) insieme alle modifiche dello schema, in quanto tali elenchi di valori consentiti cambiano. Al momento non definiamo le tabelle di ricerca in modo diverso, ma lo stiamo prendendo in considerazione per impedire al responsabile della migrazione di chiedere "quali tabelle sono di nuovo le tabelle di ricerca?" ogni volta.