Columna vs campo: ¿he estado usando estos términos incorrectamente?

Me siento un poco avergonzado aquí, siempre he usado los términos "columna" y "campo" de manera totalmente intercambiable, lo que recientemente causó cierta confusión en una discusión técnica.

Sin embargo, me dijeron que esto no era correcto, que debería serlo (traduciendo cada término a la terminología de la hoja de cálculo, ignorando los tipos de datos y todas las demás cosas que hacen que las bases de datos sean útiles):

• Columna de base de datos: como una columna de hoja de cálculo
• Registro de base de datos: como una fila de hoja de cálculo
• Campo de base de datos: como una "celda" de hoja de cálculo (una columna específica de una fila específica)

¿Es esto correcto? Podría haber jurado que la columna y el campo se usan de manera más intercambiable que eso. Ciertamente lo he sido.

Entonces, ¿no agregamos campos a una tabla, agregamos columnas a una tabla y los campos solo son relevantes cuando se habla de datos dentro de un registro?

¿Otras ideas sobre columna vs campo?

Editar: para aclarar, el contexto actual es MS SQL Server. Mi experiencia previa al servidor SQL era MS Access, lo que podría influir en mi uso de estos términos.

La teoría de la base de datos relacional no incluye el uso de la palabra Campo. El Dr. EF Codd, quien escribió la serie de documentos que proporcionan la base teórica para los RDBMS, nunca utilizó el término. Puede leer su seminal artículo de 1970 Un modelo relacional de datos para grandes bancos de datos compartidos si desea verificar.

Se utilizan términos como Dominio, Tabla, Atributo, Clave y Tupla. Una razón para esto es que sus documentos se referían en gran medida al álgebra relacional, y Codd no consideraba importante la forma en que una implementación particular definiría una tabla en una base de datos. Los vendedores desarrollarían eso más tarde. La gente también tiene que entender que históricamente, los RDBMS evolucionaron a partir de bases de datos jerárquicas y de red existentes que los preceden, Y el funcionamiento interno de un RDMBS todavía tiene que ver con la organización y el almacenamiento de datos.

De uso común, y puede verificar esto fácilmente simplemente buscando en Google, los campos y las columnas son lo mismo.

Las bases de datos de PC como DBase, Access y Filemaker generalmente usan "campo" en lugar de "columna". "Atributo" es otro término que se puede usar indistintamente.

Por ejemplo, aquí hay un enlace al manual de MS Access sobre cómo agregar un " campo " a una tabla. Está claro que en MS Access un "campo" es equivalente a una "columna".

Lo mismo vale para Dbase y Filemaker Pro.

A veces, las personas se refieren a un valor específico en una fila específica como un "campo" o más correctamente un "valor de campo", pero eso no hace que el uso de "campo" cuando se refiera a una columna o concepto de columna equivalente sea incorrecto. Esto tiende a causar un nivel de confusión porque las personas han usado "campo" para significar cosas diferentes durante muchos años. En teoría relacional, un único valor atómico se conoce como "Datum".

Si alguien declaró que un "campo" es un valor en una base de datos relacional y no es lo mismo que una columna, esa es su opinión, ya que el "campo" no es parte de la base de datos relacional vernácula. No son ni correctas ni incorrectas, sin embargo, en todo el mundo de la base de datos, el campo se usa con mayor frecuencia para significar columna.

Dicho esto, los proyectos y los equipos a menudo deben comprender cómo quieren usar una terminología particular dentro del proyecto para evitar confusiones.

No está equivocado, pero también puede decidir simplemente aceptar la convención que se está utilizando, o evitar usar el campo de palabras en favor de "columna". Con las bases de datos relacionales, "Tabla" y "Columna" son los componentes básicos que existen en DDL y es mejor usar esos términos y evitar el "campo" que no se usa, ni está claramente definido.

El SQL anterior : 92 se refiere fieldscomo componentes de elementos de fecha y hora:

"Campos en elementos de fecha y hora", especifica los campos que pueden constituir un valor de fecha y hora; un valor de fecha y hora se compone de un subconjunto de esos campos

Los campos aquí son año, mes, etc., y el término fieldno parece tener ningún otro significado en el resto del documento.

El nuevo estándar SQL: 2003 tiene esto:

Columnas, campos y atributos.

Los términos columna, campo y atributo se refieren a componentes estructurales de tablas, tipos de fila y tipos estructurados, respectivamente, de manera análoga. Como la estructura de una tabla consta de una o más columnas, la estructura de un tipo de fila consta de uno o más campos y la de un tipo estructurado de uno o más atributos. Cada elemento estructural, ya sea una columna, un campo o un atributo, es principalmente un nombre emparejado con un tipo declarado.

y después:

Un campo F se describe mediante un descriptor de campo. Un descriptor de campo incluye:
- El nombre del campo.
- El descriptor de tipo de datos del tipo declarado de F.
- La posición ordinal de F dentro del tipo de fila que simplemente lo contiene.

Este contraste con la columna, que se define como:

Una columna C se describe mediante un descriptor de columna. Un descriptor de columna incluye:
- El nombre de la columna.
- Si el nombre de la columna es un nombre dependiente de la implementación.
- Si la columna se basa en un dominio, entonces el nombre de ese dominio; de lo contrario, el descriptor del tipo de datos del tipo declarado de C.
- El valor de, si lo hay, de C.
- La característica de nulabilidad de C.
- La posición ordinal de C dentro de la tabla que lo contiene.
... (y más)

Luego más tarde nuevamente, al presentar tablas:

Una tabla es una colección de filas que tienen una o más columnas. Una fila es un valor de un tipo de fila. Cada fila de la misma tabla tiene el mismo tipo de fila. El valor del i-ésimo campo de cada fila en una tabla es el valor de la i-ésima columna de esa fila en la tabla . La fila es la unidad de datos más pequeña que se puede insertar en una tabla y eliminar de una tabla.

(énfasis mío). Esto parece respaldar lo que escribió en la pregunta: una columna específica de una fila específica .

¿Y cuántos ángeles pueden bailar alrededor de la cabeza de un alfiler?

La persona que lo corrigió podría ser corregida.

• Tabla = Relación

• Fila = Tupla

• Columna = Atributo

• Dominio = Tipo de datos

Vea la entrada de Wikipedia en bases de datos relacionales aquí .

Trabajé para una aerolínea y la palabra "vuelo" podría usarse de tres maneras diferentes dependiendo de si estaba hablando con pilotos / azafatas, ingenieros o marketing.

• pilotos / asistentes: un "vuelo" salió y regresó de la base (es decir, dos despegues y dos aterrizajes),

• ingenieros: un despegue y un aterrizaje, podrían ser pruebas, reparaciones, entrenamiento (es decir, un aeropuerto de regreso al mismo aeropuerto) o una "etapa", es decir, un aeropuerto a otro - lo que los "civiles" normalmente llamarían un vuelo, como en "Voy a tomar mi vuelo a casa mañana"),

• comercialización: una serie de "vuelos" de seis meses (típicamente dentro o fuera de temporada) desde / hacia un aeropuerto determinado en el contexto de un contrato.

La analogía de la hoja de cálculo es más que suficiente para el 99,99% de los casos, incluso en un discurso razonablemente técnico (a menos que uno sea profesor de álgebra relacional). ¿La persona que lo corrigió usa la palabra "quién" correctamente? El 99,99% de las personas no lo hacen y realmente no importa.

Generalmente uso "campo" y "columna" indistintamente, más recientemente tendiendo hacia "columna". Sin embargo, no he escuchado el término "campo" solo para indicar "datos". Tampoco he escuchado el término "atributo" para indicar "campo" o "columna". Una columna / campo tiene atributos, accesibles a través de la clase FieldInfo, por ejemplo.

Creo que "columna" es simplemente una evolución de la terminología. Los DB de escritorio (xBASE, MSAccess) generalmente usan "campo". M204 usa "campo". Esta terminología de "campo" se llevó a MSOffice xml y otros. Los documentos para Oracle (no me permitirá publicar más enlaces, lo siento) y MSSQL usan "campo" y "columna" indistintamente en todo momento. Sybase (ahora una compañía de SAP) usa predominantemente "columna" pero a veces "campo" en su documentación.

Mientras su grupo de trabajo acuerde un término, no importa cuál. Es un síndrome de "rosa con cualquier otro nombre".

Así que me doy cuenta de que esta es una vieja pregunta, pero es una que escucho a menudo. Mi opinión sobre esto proviene de la participación que nuestro equipo de datos tiene con nuestro equipo de desarrollo. Los desarrolladores definitivamente tienen campos dentro de los registros que se muestran en las pantallas y esos campos contienen datos que con frecuencia se pueden asignar a columnas con filas específicas. Sin embargo, en muchos casos, el método relacional utilizado para acceder a los datos puede alterar lo que termina en una pantalla en particular en un campo en particular.

Grabo es una representación del valor actual que entregan los datos. A medida que pasa el tiempo, esos valores pueden y probablemente cambiarán, por lo que el registro también cambia. Los datos para respaldar lo que es ahora y lo que era en un momento dado pueden almacenarse fácilmente en un conjunto de tablas. Las relaciones entre los datos determinan los significados que componen el registro en un momento dado.

La lógica que deriva los campos es algo que puede cambiar con el tiempo. Por ejemplo, un empleado es contratado como Susan Jones y ella fue contratada el 1 de diciembre de 2010 como empleado de ventas en la tienda # 101, quien reporta a Bill Anderson como gerente de la tienda. Al ser una empresa progresiva, también tienen un mentor asignado a cada empleado. La mentora de Susan es Mary Phillips. Mary Phillips es gerente de una tienda, pero también es gerente regional de la tienda en la que trabaja Susan. El 11/10/2011 Susan fue ascendida a gerente de la tienda. No sabemos qué le pasó a Bill, pero ahora Susan es la gerente de la tienda.

Tenemos una tabla de empleados con nombre, número, fecha de contratación, posición y ubicación.

Tenemos una tabla de mentores con los números de empleados para los mentores y el empleado al que están asesorando más las fechas que describen el comienzo y el final de la relación con el mentor.

Tenemos una tabla de regiones con un nombre para la región y un número de administrador asignado.

Tenemos otra tabla de ubicaciones con dirección, descripción, región y número de administrador.

Una pantalla que muestra información de la tienda podría tener un campo para el gerente de la tienda. El valor para el administrador de la tienda no es un campo de base de datos, pero es un valor computable que puede cambiar con el tiempo. También el gerente de una persona puede cambiar. Los datos que lo admiten todavía se almacenan en columnas, pero las relaciones entre las columnas han cambiado y, cuando se ensamblan para un propósito específico, se convierten en un campo.