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


30

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é?


¿Qué base de datos? La forma en que etiqueto en Oracle es diferente de la mayoría de las demás bases de datos debido a su característica de seleccionar automáticamente columnas para basar las uniones si los nombres coinciden.
Joe

@ Joe, bueno, siempre he usado MySQL y SQLite3, pero debería aplicarse a la mayoría de las otras bases de datos.
Thomas O

@joe nunca notó que Oracle es diferente. ¿Puedes dar un enlace?
bernd_k

@bernd_k: He agregado algunos enlaces a mi respuesta , a continuación
Joe

Respuestas:


33

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.


1
Sí, me enfurece cuando la gente hace eso. También cuando llaman a toda su mesa tbl_whatever.
Cayo el

Esto también es relevante para el concepto de "palabras de clase", y parece haber cierto debate en la comunidad cuando las palabras de clase son y no son apropiadas. (una palabra de clase es una herramienta para: Identificar una categoría o clasificación de datos distinta, Delinear el tipo de datos que se describe por el nombre de los datos y Describir la clasificación principal de los datos asociados con un elemento de datos.)
Jon Schoning

17

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,? "


55
Una vez trabajé en una base de datos donde el DBA decidió usar ID en algunas tablas e id en otras y teníamos MySQL configurado para ser sensible a mayúsculas y minúsculas ... ¡momentos divertidos!
Toby

66
Usualmente usamos tablename.tablename_id. Por ejemplo, car.car_id; person.person_id. Nombres singulares para tablas.
Brillante

Decisión inteligente @glasnt.
garik

1
Esta es realmente una muy mala idea, y perderá la capacidad de usar la USINGcláusula SQL (va en contra de la especificación).
Evan Carroll

9

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


7

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.


¿Cómo nombraría la columna para un nombre de empleado y un nombre de sitio, por ejemplo? ¿Cómo evitaría la redundancia de la columna de etiqueta de nombre?
Spredzy

@Spredzy: Simplemente iría con la redundancia.
Peter Eisentraut

1
La respuesta a estas preocupaciones: alias.
Jon of All Trades

7

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.


+1 para "encuentra el estilo que te gusta y quédate con él". La consistencia es mejor que cumplir exactamente con cualquier estándar en particular (aunque si aún no ha elegido un estándar, algunos son mejores que otros)
Jon of All Trades

5

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


44
¿eso cuenta como un fk_cluster?
Kaji

5

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.


3

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.


2
-1 porque CamelCase no funciona en todos los sistemas de bases de datos y no especificó un sistema de base de datos. Por ejemplo, es una mala noticia usar CamelCase en Oracle (requeriría el uso de comillas dobles para crearlo, pero a partir de entonces, todos los que accedan a él tendrían que saltar a través de los aros para acceder / usarlo). Qué pesadilla.
ScottCher

@ScottCher: no sabía que no funciona en Oracle, pero tampoco soy un DBA de Oracle. Pensé que se consideraría un hecho que los nombres de las columnas deben cumplir primero con las reglas establecidas por el DBS en cuestión.
Toby

3

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.


44
¿Te refieres a "Uniones naturales" en tu segundo párrafo? Si es así, SHUDDER ... Siempre que sea posible, debe especificar cómo desea que su sistema de base de datos se una a sus tablas. Dejarlo a la base de datos para decidir puede producir resultados inesperados / inconsistentes. Además, las Uniones naturales se limitan a las uniones entre dos tablas y, por lo tanto, su usabilidad es relativamente limitada.
ScottCher

2
NATURAL JOIN nunca ha sido el valor predeterminado. Si no se proporciona una unión explícita, se realizará una unión cartesiana (es decir, todas y cada una de las filas de una tabla unidas a todas y cada una de las filas de la otra tabla). Antes de que se admitieran las uniones ANSI (es decir, las especificadas en la cláusula FROM), las uniones tenían que hacerse en la cláusula WHERE.
Gary

1
-1 para uniones naturales. Cuando un cambio de esquema no relacionado puede romper las uniones, o peor aún, cambiarlas sin causar ningún error, te encontrarás en un mundo de dolor. Por favor, piense en los niños y SIEMPRE especifique sus campos de unión.
Jon of All Trades

2
@ScottCher: "Dejarlo a la base de datos para decidir" - primero, presumiblemente te refieres a "DBMS" en lugar de "base de datos". En segundo lugar, no hay IA ni mecanismo antropomorfista en Oracle; más bien NATURAL JOINes determinista.
cuando el

1
@Joe cross joines, fue y siempre será el 'predeterminado'. Oracle nunca ha coincidido con el nombre de la columna a menos que natural joinse haya usado explícitamente
Jack Douglas

1
  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;

1
Actualicé esto para ser más explícito.
Evan Carroll
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.