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

¿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.

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.

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

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.

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.

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