¿Por qué los prefijos de nombres de columnas se consideran una mala práctica?

Según una publicación SO popular, se considera una mala práctica prefijar los nombres de las tablas. En mi empresa, cada columna tiene como prefijo un nombre de tabla. Esto me es difícil de leer. No estoy seguro de la razón, pero este nombre es en realidad el estándar de la compañía. No soporto la convención de nomenclatura, pero no tengo documentación que respalde mi razonamiento.

Todo lo que sé es que leer AdventureWorks es mucho más simple. En esta base de datos de nuestra empresa, verá una tabla, Persona y puede tener el nombre de la columna:

Person_First_Name
o tal vez incluso
Person_Person_First_Name (no me preguntes por qué ves a la persona 2x)

¿Por qué se considera una mala práctica preestablecer los nombres de columna? ¿Los guiones bajos también se consideran malvados en SQL?

Los guiones bajos no son malos, solo son más difíciles de escribir. Lo malo es cambiar los estándares a mitad de camino sin arreglar todos los objetos existentes. Ahora tiene personId, Person_id, etc. y no puede recordar qué tabla usa los guiones bajos o no. La coherencia en la denominación (incluso si personalmente no le gustan los nombres) ayuda a facilitar la codificación.

Personalmente, el único lugar donde siento la necesidad de usar el nombre de la tabla en una columna es en la columna de ID (el uso de solo ID es un antipatrón en el diseño de la base de datos, ya que cualquiera que haya realizado extensas consultas de informes puede decírselo. Es muy divertido cambiar el nombre 12 columnas en su consulta cada vez que escribe un informe.) Eso también facilita el conocimiento inmediato de los FK en otras tablas, ya que tienen el mismo nombre.

Sin embargo, en una base de datos madura, es más trabajo de lo que vale la pena cambiar un estándar existente. Simplemente acepte que ese es el estándar y siga adelante, hay cosas mucho más críticas que deben arreglarse primero.

Un argumento para el prefijo de nombre de columna estaría evitando las "colisiones" de nombres al unir varias tablas Y cuando el creador de la consulta no usa alias.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Ambas consultas tendrían dos columnas de "nombre" ( nombre_1, nombre_2 ) sin "decir" a qué entidad pertenece. Y nunca puede estar seguro de los nombres de columna generados (será name_2 o name_3 o ...). Si usa el prefijo del nombre de la tabla, los nombres de las columnas serían person_name , company_name para que sepa cada nombre a qué entidad pertenece, además de que sabe que los nombres de las columnas permanecerán constantes (si los obtiene en Java usando JDBC, por ejemplo )

Se pueden ignorar ambos argumentos si se usa el alias, pero creo que la mayoría de las convenciones de codificación aplicadas en las empresas se deben a que muchos programadores (junior) no siguen las buenas prácticas. En este caso, por ejemplo, usar el comodín en una instrucción SELECT puede causar problemas sin el prefijo del nombre.

En cuanto al guión bajo en los nombres de tabla y columna, lo uso ampliamente porque solo uso minúsculas en los nombres más guión bajo como separador. Usar solo minúsculas ayuda a distinguir los identificadores de las palabras clave SQL (que escribo en mayúsculas):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

Agregar ese tipo de prefijos a los nombres de columna hará que una tabla sea más difícil de evolucionar. Como ejemplo: si finalmente se da cuenta de que desea / necesita cambiar el nombre de la tabla, deberá modificar toda la estructura de la tabla (es decir, no solo el nombre de la tabla, sino el nombre de todas sus columnas). Esto también dificultaría la actualización de los índices de la tabla y el código de los clientes que lo consultan.

Hay excepciones si se usa juiciosamente (según la respuesta de Patrick Karcher en su enlace) para nombres de columnas comunes (normalmente solo ID, a veces Nombre) que serían ambiguos con demasiada frecuencia .

Otra práctica recomendada es calificar siempre las columnas y los objetos en sus consultas. Por lo tanto, los prefijos de columna se vuelven discutibles y abarrotan su código.

Compare estos: ¿cuál es más fácil para la vista?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

En general, realmente no parece haber ningún estándar omnipresente. La pregunta a la que se vinculó tiene varias respuestas altamente votadas con convenciones totalmente diferentes. Por supuesto, todos defenderán sus propios estándares, y es mucho más importante mantener convenciones consistentes en un proyecto.

Dicho esto, prefijar los nombres de las columnas parece ser excesivo. Ya sabe con qué tabla está trabajando, y una situación con dos columnas de diferentes tablas que tienen el mismo nombre puede resolverse fácilmente utilizando alias de tabla o columna.

En TSQL puede referirse a los campos en el formato TableName.FieldName si desea evitar la ambigüedad, por lo que agregar nombres de tabla a los nombres de campo en realidad elimina la legibilidad, lo que lo convierte en TableName.TableName_FieldName o similar. Creo que usar guiones bajos o no es más una elección personal. Prefiero CamelCase y uso _ cuando quiero agregar un sufijo o similar, por ejemplo, TableName_Temp, pero solo soy yo.

Una vez trabajé en un sistema en el que decidimos usar códigos cortos para prefijar las columnas. Los campos PK usaban el "nombre completo de la tabla" como prefijo, y todas las demás columnas usaban de 2 a 4 caracteres consistentemente como prefijo. Cada columna también usó un dominio de datos como sufijo. Si se hace de manera consistente, puede ser muy agradable y limpio. No tiene sentido que un estándar de nomenclatura de un tipo u otro implique una codificación descuidada. La presencia de un estándar consistente es lo importante. He visto varias bases de datos que son inconsistentes porque no hay un estándar claro, y eso más que cualquier otra cosa me indicaría que puede haber problemas en las estructuras de datos. Si el diseñador de una base de datos ni siquiera puede nombrar constantemente objetos y sus hijos,

El prefijo es una mala práctica porque causa el problema que está diseñado para prevenir. Como dijiste, es muy difícil leer las columnas prefijadas. Si termina con nombres de columna duplicados en una consulta en la que une dos tablas, puede resolverlo, o es una vista, procedimiento almacenado o función tabular definida por el usuario que lo hace por usted si se encuentra constantemente uniendo tablas particulares.

En cuanto al uso subrayado en un nombre de tabla, ese es un argumento religioso. Al final, si aumenta la visibilidad y facilita las cosas. Generalmente, nunca tendría espacios o tablas en una columna o nombre de tabla. Sin embargo, podría hacer una excepción para las tablas o vistas que solo fueron utilizadas por un paquete de informes o exportadas a un archivo CSV.

Muchas bases de datos tienen límites estrictos en el número de caracteres en un nombre de columna (es decir, Oracle).

Si está trabajando con una base de datos que permite nombres de columna largos, pero luego decide que desea migrar esa estructura a otro sistema de base de datos, los prefijos aumentarán las posibilidades de que sus nombres de columna no sean válidos.

Aunque ahora está trabajando con SQL Server, nadie puede predecir el futuro, y es posible que su software tenga que funcionar en múltiples bases de datos en el futuro.

Considere escribir un diccionario de datos (o "registro"). Con eso quiero decir un documento que contiene todos los elementos de datos en su modelo: nombre, descripción, etc. Debe ser independiente de la implementación del modelo, por ejemplo, no debe mencionar los nombres de las tablas. ¿Cómo desagregaría nombres como 'ID', 'Tipo' y 'Código'?

Un enfoque es seguir las pautas de la norma internacional ISO / IEC 11179. Después de todo, ¿por qué reinventar la rueda? La estructura básica es:

[Object] [Qualifier] Property RepresentationTerm

con delimitadores entre los elementos: SQL no funciona bien con espacios en los nombres de columna y el subrayado funciona bien visualmente.

Tengo la sensación de que alguien en su organización estaba tratando de seguir estas pautas cuando se les ocurrieron nombres de elementos como Person_Person_First_Name.

El ejemplo que me gusta mostrar es el diccionario de datos del Servicio Nacional de Salud del Reino Unido (NHS) .

Así que no creo que la convención de nomenclatura con la que tienes que trabajar suene demasiado mal.

En la implementación, por ejemplo, en SQL, a algunas personas les gusta omitir los subelementos Objeto, Calificador y Propiedad cuando el nombre de la tabla proporciona contexto, por ejemplo, se person_first_nameconvierte first_nameen la Persontabla, etc. Sin embargo, la regla general de que un elemento de datos no debería cambiar su nombre simplemente debido a su ubicación en el modelo físico parece una buena. A cualquiera que piense que no es una buena idea seguir esta regla se le debe dar la tarea de documentar todas las variaciones de nombre que han usado :)

Encontrará un buen resumen de ISO 11179 en el libro Estilo de programación de Joe Celko , que incluye evidencia para preferir guiones bajos como delimitadores en los nombres de columna.

Algunos encuentran más fácil en el código saber de qué tabla provienen los datos, sin embargo, si está hablando de un sistema orientado a objetos, debe usar el contexto del nombre para saber de dónde proviene, en este caso el nombre de la tabla.

Personalmente, el prefijo de nombre de tabla es una indicación de que los desarrolladores no son muy hábiles y, a medida que profundice, encontrará muchas otras convenciones de codificación incorrecta y si tuviera que adivinar que la aplicación tiene demasiadas tablas, tiene errores, etc.