¿Cuál es una forma efectiva de etiquetar columnas en una base de datos?

Solía ​​etiquetar columnas en mis bases de datos de esta manera:

user_id
user_name
user_password_hash

Para evitar conflictos al unir dos tablas, pero luego aprendí un poco más sobre cómo alias de tablas, y dejé de hacer esto.

¿Cuál es una forma efectiva de etiquetar columnas en una base de datos? ¿Por qué?

En su caso, el usuario del prefijo es redundante. Nosotros (los desarrolladores a cargo) sabemos que este es el usuario de la tabla, entonces, ¿por qué agregar un user_prefijo delante de cada campo?

Lo que te sugeriría es que lo hagas con un enfoque más natural.

¿Cuáles son las características de una persona? Apellido, nombre, fecha de nacimiento, nacionalidad, etc.

¿Cuáles son las características de un automóvil: modelo, año, color, energía, etc.?

Su columna debe ser nombrada lo más natural posible, haría que el esquema sea más claro para todos, para usted y los que vienen después de usted. Esto también se llama la fase de Mantenimiento, y cualquier cosa que pueda hacer para facilitar el mantenimiento generalmente vale la pena.

Además del comentario de Spredzy, etiquete sus claves principales de la misma manera (ID) para que cuando esté escribiendo consultas sobre la marcha, pueda recordar fácilmente (u.ID = c.ID) en lugar de tener que buscar "¿Fue countryID? , country_ID, países_ID, paísesID,? "

No podría estar más de acuerdo con la adición de David Hall a la excelente respuesta de Spredzy. Simple y natural es el camino a seguir. La confusión de tablas no debería ser un problema si también nombra las tablas naturalmente.

No tiene sentido tener users.user_id y cars.car_id cuando podría tener users.id y cars.id

Yo diría que en un esquema de base de datos, cada columna debe tener un nombre único, en todas las tablas. Hay varias razones para eso:

• Desde el punto de vista del modelado: comienza con una sopa de atributos y lo normaliza en tablas. Con el tiempo, puede desnormalizar o normalizar más o introducir vistas o vistas materializadas, o introducir nuevas tablas. Esto nunca es un problema si todos los nombres de columna son únicos.

• Se puede utilizar esta sintaxis de combinación: a JOIN b USING (a_id) JOIN c USING (a_id). Muy conveniente y también ayuda con el siguiente punto.

• Si ejecuta consultas con muchas combinaciones o crea vistas materializadas SELECT *, nunca (bueno, tal vez rara vez) tendrá un conflicto. Pensar en unirse person.name, product.name, country.name, etc. Urgh.

• En general, si tiene grandes consultas, es difícil hacer un seguimiento de lo que idsignifica en todas partes.

Veamos, con su ejemplo se verá más o menos así:

USERS
----
id
username,
password
registration_date

Yo uso el nombre de la tabla en mayúsculas. Esto me permite identificar la tabla fácilmente. Las columnas que acabo de nombrar son cada una para lo que representa. Intento no usar números ni incluir ningún prefijo o sufijo con él. Esto hará que las consultas sean simples y bastante directas.

Por cierto, creo que deberías encontrar un estilo que te guste y seguir con él. Si lo cambia con frecuencia, tendrá un esquema de DB más desordenado.

Al igual que los demás, le recomiendo que no incluya el nombre de la tabla como parte de la columna. A menos que tenga cientos de tablas, todas con nombres de columnas en su mayoría similares: si tiene varias docenas de tablas, todas con una columna titulada ID, entonces, por todos los medios, prefijelas con el nombre de la tabla.

Recientemente dejé una compañía donde uno de los desarrolladores prefería prefijar las columnas de clave principal y clave externa con pk y fk. Esto condujo a algunas abominaciones donde las columnas comenzaron con pkfk (generalmente una clave primaria compuesta basada en 2 columnas, de las cuales una columna era una clave foránea para otra tabla).

Estoy trabajando en un entorno donde cada nombre de columna comienza con un prefijo derivado del nombre de la tabla, no es mi invención, pero estoy bastante contento con él.

Idealmente, los nombres de columna son únicos en todas las tablas de la base de datos.

Algunas observaciones

• solo necesitamos alias de tabla, cuando las tablas se unen varias veces en una instrucción select
• evita algunas fallas al copiar fragmentos de código, porque los nombres de columna deben adaptarse al nombre de la tabla
• ayuda a mostrar a qué tabla apunta una columna de clave externa

Ideas generales: lo más importante es la consistencia de cada convención de nomenclatura: - singular vs. plural (está bien que se aplique a tablas y no a columnas) - identifique claves primarias y externas (crean la estructura frente al contenido de la base de datos) - sea coherente cuando almacena cadenas y una variante corta de la misma cadena: sea coherente con las banderas, el estado, etc.

Estoy de acuerdo con la respuesta de Spredzy, pero agregaría que, como cuestión de preferencia, usaría camelCase en lugar de under_score.

nombre, apellido, etc.

En el caso de Oracle, usted querrá no nombrar columnas 'id' o 'nombre' o algo genérico.

El problema es que, de manera predeterminada, en versiones anteriores , Oracle intentará unir tablas basadas en nombres de columnas similares, por lo que si he nombrado todo bien, también he terminado especificando la cláusula de unión predeterminada entre mis tablas.

Pero incluso si usted está no utilizar Oracle, al no eligiendo nombres que aparecen en varias tablas, sino que también significa que no se tiene que pasar por la molestia de añadir un alias cada vez que tenga que hacer un seleccione a través de dos tablas:

SELECT
  instrument.name as instrument_name,
  instrument.abbr as instrument_abbr,
  source.name     as source_name,
  source.abbr     as source_abbr,
  ...
FROM ...

Por lo tanto, si las selecciones de varias tablas son la norma, los nombres de columna más largos le ahorran escribir. (si solo usa una tabla a la vez ... ¿realmente necesita una base de datos relacional?)

... y guardar la escritura nos lleva a otro problema en Oracle, al menos en 8i (la versión actual cuando tomé los cursos de Oracle SQL Tuning y Data Modeling) el almacenamiento en caché de los planes de ejecución se basa solo en los primeros caracteres del consulta (no puede recordar el valor exacto ... 1024?), por lo que si tiene consultas que solo varían según algo al final de la cláusula where, y una lista realmente larga de columnas que está extrayendo, usted puede encontrarse con un impacto en el rendimiento ya que no puede almacenar en caché el plan de ejecución correctamente.

Oracle tenía una guía para seleccionar lo que dicen que son buenos nombres de tabla y columna, que es básicamente una guía para eliminar letras hasta que tenga entre 5 y 8 caracteres, pero nunca me importó demasiado.

...

A medida que las cosas van aparte de eso:

• las columnas son siempre singulares (las tablas son siempre plurales)
• todos los nombres son minúsculas, en caso de que haya algo que distinga entre mayúsculas y minúsculas
• Como resultado de lo anterior, use guiones bajos en lugar de mayúsculas y minúsculas.

actualización : para aquellos que no están familiarizados con el comportamiento de combinación de Oracle, consulte el último ejemplo sobre Dominio de Oracle SQL: Condiciones de combinación , donde menciona:

¿Que pasó? La razón radica en el hecho de que, además de supplier_id, estas dos tablas tienen otro par de columnas con un nombre común. Esa columna es el nombre. Entonces, cuando solicita una unión natural entre el proveedor y las tablas de partes, la unión se lleva a cabo no solo al igualar la columna proveedor_id de las dos tablas, sino que también se iguala la columna de nombre de las dos tablas. Como ningún nombre de proveedor es igual al nombre de parte de ese mismo proveedor, la consulta no devuelve filas.

Bajo 'antigua sintaxis de unión' (8i y anterior), 'NATURAL JOIN' era el comportamiento de unión predeterminado, y creo que todavía lo es si no especifica una condición de unión. Una vez que 'NATURAL JOIN' era una opción oficial en 9i, la recomendación general era no usarla , porque el mal nombre de la columna puede arruinarte, lo cual es mi defensa de los buenos nombres de columna.

1. Nunca use comillas dobles " porque al hacerlo, anula el plegado de mayúsculas y minúsculas nativo de la base de datos. La especificación SQL exige que todos los identificadores se plieguen en mayúsculas. Algunas bases de datos, como PostgreSQL, las pliegan en minúsculas. Si no se cita nada, funcionará en todas las bases de datos y pueden plegarlas según la especificación o el valor predeterminado específico de rdbms.
2. Use un under_score ( _), porque según lo anterior, no debe usar camelCase.

3. use {entity}_idpara identificadores (y claves foráneas que apuntan a esos identificadores). Porque entonces puedes usar la USINGcláusula. Los nombres de clave globalmente únicos utilizados en condiciones de unión son una convención establecida en la especificación.

   SELECT *
   FROM employee
   INNER JOIN department
     USING (department_id);
   
     -- compare to
     ON employee.department_id = department.department_id;