¿Qué es más convenciones de nombres legibles para tablas de búsqueda?

Question

Siempre nombrar tablas de búsqueda - como Países, ciudades, regiones, etc ... - de la siguiente manera:
EntityName_LK O LK_EntityName (Countries_LK O LK_Countries)
Pero puedo preguntar si alguien tiene mejores conversiones más nomenclatura para las tablas de búsqueda?

Editar:
Pensamos hacer de sufijo o prefijo para resolver como un conflicto:
si tenemos User mesas y tabla de consulta para UserTypes (ID-Nombre) y tenemos una relación de muchos a muchos entre User & UserTypes que nos una mesa que podemos nombrar como si fuera Types_For_User que pueden hacer que la confusión entre UserTypes & Types_For_User Así que nos gusta hacer tabla de búsqueda UserTypes sea como UserTypesLK a ser obvio para todos

hacer

Answer 1

Antes de decidir que necesita el apodo de "búsqueda", debe intentar comprender por qué está designando algunas tablas como "búsquedas" y otras no. Cada tabla debe representar una entidad en sí misma.

¿Qué sucede cuando una tabla que fue designada como una "búsqueda" crece en alcance y ya no se considera una "búsqueda"? A usted le queda cambiar el nombre de la tabla que puede ser oneroso o dejarlo como está y tener que explicarle a todos que una tabla dada no es realmente una "búsqueda".

Un escenario común mencionado en los comentarios relacionados con una tabla de unión. Por ejemplo, supongamos que un usuario puede tener múltiples "tipos" que se expresan en una tabla de unión con dos claves externas. ¿Debería llamarse esa tabla al User_UserTypes? Para este escenario, primero diría que prefiero usar el sufijo Member en la tabla de unión. Entonces tendríamos Users, UserTypes, UserTypeMembers. En segundo lugar, la palabra "tipo" en este contexto es bastante genérica. ¿Significa realmente un rol un UserType? El término que usa puede marcar la diferencia. Si UserTypes son realmente Roles, entonces nuestros nombres de tabla se convierten en Users, Roles, RoleMembers, lo que parece bastante claro.

Answer 2

Cada tabla puede convertirse en una tabla de búsqueda. Considere que una persona es una búsqueda en una tabla de Factura. Entonces, en mi opinión, las tablas solo deberían llamarse el nombre de la entidad (singular), p. Persona, Factura

lo que quieren es un estándar para los nombres de columna y limitaciones, tales como

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

Al final del día, es todo depende de las preferencias personales (si puede salirse con la dictándolo) o estándares del equipo.

actualizado

Si tiene operaciones de búsqueda que corresponden únicamente a entidades, como Invoice_Terms que es una búsqueda de una lista de 4 escenarios, entonces se podría nombrar como Invoice_LK_Terms lo que haría aparecer por su nombre agrupadas bajo Factura. Otra forma es tener una sola tabla de búsqueda para búsquedas sencillas de un solo valor, separadas por la función (tabla + columna) para la que se utiliza, p.

Lookups 
Table | Column | Value 

Answer 3

Aquí hay dos preocupaciones acerca de si se debe usar un prefijo o sufijo.

1. En una lista ordenada de las tablas, ¿Quieres que las tablas LK para estar juntos o quieres todas las tablas que pertenecen a EntityName a aparecer juntos

2. Al programar en entornos con auto-completado, se es probable que desee escribir "LK" para obtener la lista de tablas o el comienzo de EntityName?

Creo que hay argumentos para cualquiera, pero elegiría comenzar con EntityName.

Answer 4

Solo hay un tipo de tabla y no creo que haya ninguna buena razón para llamar tablas a algunas tablas de "búsqueda". Use una convención de nomenclatura que funcione de la misma manera para todas las tablas.

Answer 5

Un área donde las convenciones de nomenclatura de tablas pueden ayudar es la migración de datos entre entornos. A menudo tenemos que mover los datos en las tablas de búsqueda (que restringen los valores que pueden aparecer en otras tablas) junto con los cambios de esquema, ya que estas listas de valores permitidos cambian. Actualmente no nombramos las tablas de búsqueda de manera diferente, pero lo estamos considerando para evitar que el tipo de migración pregunte "¿qué tablas son tablas de búsqueda otra vez?" cada vez.