¿Qué estándar debo seguir al nombrar tablas y vistas?

20

¿Qué estándar debo seguir al nombrar tablas y vistas? Por ejemplo, ¿es una buena idea poner algo como tbl_ al comienzo de los nombres de las tablas? ¿Debería designar tablas de código / búsqueda de alguna manera como ct_, lut_ o codes_? ¿Hay otros que hacer / no hacer?

Estoy usando MS SQL Server y tengo muchas bases de datos con muchas tablas, por lo que sería bueno tener algo que podamos usar como estándar con algún soporte racional.

relational-theory naming-convention

— Beth Whitezel
fuente

29

OK, primero NUNCA ponga tbl delante del nombre de una tabla. Es una mesa, ya lo tenemos ahora. Eso se llama notación húngara, y la gente dejó de hacerlo hace más de 5 años.

Simplemente llame al objeto en función de lo que es. Si una tabla contiene datos de empleados, llámela "Empleado". Si contiene información sobre computadoras, llámelo "Computadora". Si asigna computadoras a los empleados, llámelo "EmployeeComputer" o "ComputerEmployee" (personalmente me gusta más "EmployeeComputer").

No hay una convención de nomenclatura correcta real para usar (aparte de no usar la notación húngara). Mientras los nombres de los objetos tengan sentido, es importante.

— mrdenny
fuente

11

Además de eso, por favor no ponga los nombres de las tablas como sustantivos plurales, ya que he visto ejemplos de Empleados, Cumputers ... Todos sabemos que las tablas deben tener muchas filas, no una ...

— Marian

1

¿Por qué crearías vistas de una tabla? Toda una vista es, es una declaración de selección almacenada. Los datos no se materializan detrás de una vista a menos que esté utilizando una vista indizada. Casi nunca uso vistas, nunca lo he hecho. Ciertamente no hay ningún beneficio de rendimiento al hacerlo.

— mrdenny

2

Usamos vistas cuando queremos hacer algo como unir un par de tablas o traducir valores de código a valores legibles por humanos. La segunda situación es donde terminaría con un nombre simular.

— Beth Whitezel

2

La respuesta del Sr. Denny y los siguientes contribuyentes están respaldados por esto: dba4life.blogspot.com/2007/11/…

1

@Marian: uso plurales porque hacen que las consultas se lean de forma más natural y resuelvan colisiones con palabras clave. Muchos sistemas con los que he trabajado han tenido una entidad de orden. El uso de plurales hace que el nombre de la tabla ordersno ordery evita tener que citar el nombre de la tabla cada vez que son usuarios. Esto también se aplica a groupy otras palabras clave. Afortunadamente, pocas palabras clave chocan con entidades comunes.

— BillThor

13

Usamos esquemas (piense en ellos como espacios de nombres en SQL quizás) tanto para permisos como para agrupación. Entonces, en lugar de "tbl", etc. tenemos

Data.Thing
Data.ThingHistory
Datos.

Ningún código entra en el esquema de datos. No hay tablas en vivo fuera del esquema de datos. Esto puede extenderse, por supuesto, para tener un esquema de Búsqueda o Estadificación si lo desea.

Para las vistas que usamos, vwpero esto era para distinguirlas de las tablas en SQL Server 2000 y ahora es un poco heredado

— gbn
fuente

3

+1 para recomendar esquemas. Esto será útil mientras se mantiene una base de datos grande con cientos de tablas. Usamos esquemas para la agrupación funcional también ... como lo hizo en AdventureWorks db

— CoderHawk

5

Personalmente, soy un gran admirador de Fanö Bedingung , lo que significa que aquí no se permite que el nombre sea el comienzo de otro nombre válido.

Y segundo, la distancia de Hamming entre dos nombres es mejor que más de una letra diferente.

Sí, eso es regla desde los tiempos predigitales, pero hacen la vida más fácil.

Y los terceros nombres deben ser pronunciables, o te volverás loco, cuando el reconocimiento de voz se vuelva verdadero.

— bernd_k
fuente

2

Cuando el reconocimiento de voz se haga realidad, me enojaré de todos modos. :-)

— Beth Whitezel

Solo si haces soporte de teletón

— bernd_k

1

Cuando llegue el reconocimiento de voz, me convertiré en camionero. Eso o un ermitaño loco.

— mrdenny

¿Podría explicar con más detalle (quizás con un ejemplo) qué es "Fano Bedingung"?

— Nick Chammas

1

@NickChammas Creo que en inglés llamamos a esto codificación Shannon-Fano .

— Iain Samuel McLean Élder

2

No sé si realmente existe alguna "mejor" convención de nomenclatura, ya que realmente se reduce a preferencias personales y facilidad de desarrollo. Mi consejo es elegir una convención de nomenclatura y cumplirla. Si desea separar las palabras con un guión bajo, hágalo en todos los objetos de su base de datos. Si desea utilizar camelCase, hágalo en todos los objetos de su base de datos.

En mi tienda nos adherimos a las siguientes reglas:

Separamos las palabras con guiones bajos y usamos todas las letras minúsculas.
Los nombres de nuestras tablas describen lo que son: dbo.person, dbo.invoice.
Nuestros nombres de tabla de muchos a muchos también describen cuáles son (con la adición de mm para indicar una relación de muchos a muchos que se está mapeando: dbo.person_mm_address. Nuestros procedimientos almacenados definidos por el usuario describen tanto el objeto como la acción que se realiza: usp_person_select , usp_address_select_by_city Nuestras vistas y funciones siguen las mismas reglas que los procedimientos almacenados. Nuestros índices incluyen tabla, columnas clave (en orden) y una indicación de clustered / non-clustered: ix_person_last_name_first_name_nc

Solo porque esto es lo que usamos en mi tienda, no significa que estas reglas sean adecuadas para usted. Elija algo con lo que usted y su equipo de desarrollo acuerden que sea útil y fácil de desarrollar, y establezca una cultura de conocer y usar cualquier convención de nomenclatura que decida. En nuestro caso, esto incluye la revisión de código para cualquier objeto creado en una base de datos. Con el tiempo, la combinación de una convención de nomenclatura documentada y una revisión del código de pares ha llevado a cada vez menos desviaciones de la convención.

Espero que esta "no respuesta" ayude de alguna manera.

— Matt M
fuente

2

Estoy contento con esto desde hace años

nombres de tabla: minúsculas y guiones bajos, singular {cliente, producto}
nombres de tabla para relaciones de muchos a muchos: tablename1_tablename2: {customer_product}
vistas: las minúsculas agregaron v al final {customerv, productv, product_groupv}
procedimientos almacenados: nombre y función de la tabla {customer_select, customer_insert, customer_delete, customer_update}

Si tiene un paquete de alojamiento compartido barato, deberá usar la abreviatura del proyecto frente a todos sus objetos, como por ejemplo, el sitio de administradores de bases de datos, da_users, da_questions

— Uğur Gümüşhan
fuente

¿Por qué product_groupvy no product_group_vpara las vistas (si insiste en esta discreción de vistas y tablas)?

— ypercubeᵀᴹ

@ypercube porque soy demasiado vago para escribir un guión bajo adicional y cometo errores de escritura fácilmente. Leo las palabras más fácilmente cuando uso un guión bajo y uso v para separar la vista de las tablas, y v no es una palabra, así que no uso guión bajo. Parece inconsistente, sí, pero este formato me parece práctico.

— Uğur Gümüşhan