Coluna vs Campo: eu tenho usado esses termos incorretamente?

Sinto-me meio embaraçado aqui, sempre usei os termos "coluna" e "campo" de forma totalmente intercambiável, o que recentemente causou alguma confusão em uma discussão técnica.

Disseram-me, porém, que isso não estava correto, que deveria estar (traduzindo cada termo na terminologia da planilha, ignorando os tipos de dados e todas as outras coisas que tornam os bancos de dados úteis):

• Coluna do banco de dados: como uma coluna de planilha
• Registro do banco de dados: como uma linha da planilha
• Campo do banco de dados: como uma "célula" da planilha (uma coluna específica de uma linha específica)

Isto está certo? Eu poderia jurar que coluna e campo são usados ​​de maneira mais intercambiável que isso. Eu certamente tenho sido.

Portanto, não adicionamos campos a uma tabela, adicionamos colunas a uma tabela e os campos são relevantes apenas quando se fala de dados em um registro?

Outros pensamentos sobre coluna vs campo?

Editar: para esclarecer, o contexto atual é o MS SQL Server. Meu histórico no SQL Server era o MS Access, o que pode influenciar o uso desses termos.

A teoria do banco de dados relacional não inclui o uso da palavra Campo. O Dr. EF Codd, que escreveu a série de artigos que fornecem a base teórica para os RDBMS, nunca usou o termo. Você pode ler o artigo seminal de 1970, Um modelo relacional de dados para grandes bancos de dados compartilhados, se quiser verificar.

Termos como Domínio, Tabela, Atributo, Chave e Tupla são usados. Uma razão para isso é que seus trabalhos estavam amplamente preocupados com álgebra relacional, e a maneira como uma implementação específica definiria uma tabela em um banco de dados não foi considerada importante pelo Codd. Os fornecedores aprofundariam isso mais tarde. As pessoas também precisam entender que, historicamente, os RDBMS evoluíram a partir de bancos de dados hierárquicos e de rede existentes que os antecedem, E o funcionamento interno de um RDMBS ainda precisa se preocupar com a organização e o armazenamento de dados.

No uso comum, e você pode verificar isso facilmente, pesquisando um pouco, campos e colunas são a mesma coisa.

Bancos de dados de PC como DBase, Access e Filemaker normalmente usam "campo" em vez de "coluna". "Atributo" é outro termo que pode ser usado de forma intercambiável.

Por exemplo, aqui está um link para o manual do MS Access sobre como adicionar um " campo " a uma tabela. É claro que no MS Access um "campo" é equivalente a uma "coluna".

O mesmo vale para o Dbase e o Filemaker Pro.

Às vezes, as pessoas se referem a um valor específico em uma linha específica como sendo um "campo" ou, mais adequadamente, um "valor de campo", mas que não faz uso de "campo" ao se referir a uma coluna ou conceito de equivalente equivalente a uma coluna. Isso tende a causar um nível de confusão, porque as pessoas usam "campo" para significar coisas diferentes por muitos anos. Na teoria relacional - um único valor atômico é chamado de "Datum".

Se alguém afirmou que um "campo" é um valor em um banco de dados relacional e não o mesmo que uma coluna, essa é a opinião deles, pois "campo" não faz parte do vernáculo do banco de dados relacional. Eles não estão certos nem errados, no entanto, em todo o mundo do banco de dados, o campo é mais frequentemente usado para significar coluna.

Com isso dito, os projetos e as equipes geralmente precisam entender como desejam usar uma terminologia específica no projeto para evitar confusão.

Você não está errado, mas também pode optar por simplesmente concordar com a convenção que está sendo usada ou evitar usar o campo de palavras por completo em favor de "coluna". Com bancos de dados relacionais, "Tabela" e "Coluna" são os blocos de construção que existem no DDL e é melhor usar esses termos e evitar "campos" que não são usados, nem claramente definidos.

O SQL: 92 mais antigo se refere fieldscomo componentes de itens de data e hora:

"Campos em itens de data e hora", especifica os campos que podem compor um valor de data e hora; um valor de data e hora é composto de um subconjunto desses campos

Os campos aqui são ano, mês e assim por diante ... e o termo fieldnão parece ter outro significado no restante do documento.

O mais recente padrão SQL: 2003 possui:

Colunas, campos e atributos

Os termos coluna, campo e atributo referem-se a componentes estruturais de tabelas, tipos de linhas e tipos estruturados, respectivamente, de maneira análoga. Como a estrutura de uma tabela consiste em uma ou mais colunas, a estrutura de um tipo de linha consiste em um ou mais campos e a de um tipo estruturado, um ou mais atributos. Todo elemento estrutural, seja uma coluna, um campo ou um atributo, é principalmente um nome associado a um tipo declarado.

e depois:

Um campo F é descrito por um descritor de campo. Um descritor de campo inclui:
- O nome do campo.
- O descritor de tipo de dados do tipo declarado de F.
- A posição ordinal de F no tipo de linha que simplesmente o contém.

Esse contraste com a coluna, que é definida como:

Uma coluna C é descrita por um descritor de coluna. Um descritor de coluna inclui:
- O nome da coluna.
- Se o nome da coluna é um nome dependente da implementação.
- Se a coluna for baseada em um domínio, então o nome desse domínio; caso contrário, o descritor de tipo de dados do tipo declarado de C.
- O valor de, se houver, de C.
- A característica de nulidade de C.
- A posição ordinal de C na tabela que o contém.
... (e mais)

Mais tarde, novamente, ao introduzir tabelas:

Uma tabela é uma coleção de linhas com uma ou mais colunas. Uma linha é um valor de um tipo de linha. Cada linha da mesma tabela tem o mesmo tipo de linha. O valor do i-ésimo campo de cada linha de uma tabela é o valor da i-ésima coluna dessa linha da tabela . A linha é a menor unidade de dados que pode ser inserida em uma tabela e excluída de uma tabela.

(ênfase minha). Isso parece apoiar o que você escreveu na pergunta: uma coluna específica de uma linha específica .

E quantos anjos podem dançar ao redor da cabeça de um alfinete?

A pessoa que o corrigiu pode ser corrigida.

• Tabela = Relação

• Row = Tuple

• Coluna = Atributo

• Domínio = Tipo de Dados

Veja a entrada da Wikipedia sobre bancos de dados relacionais aqui .

Eu trabalhei para uma companhia aérea e a palavra "vôo" poderia ser usada de três maneiras diferentes, dependendo de você estar falando com pilotos / comissários de bordo, engenheiros ou marketing.

• pilotos / comissários de bordo: um "voo" estava saindo e voltando da base (ou seja, duas decolagens e dois pousos),

• engenheiros: uma decolagem e uma aterrissagem podem ser teste, reparo, treinamento (ou seja, um aeroporto de volta ao mesmo aeroporto) ou uma "perna", ou seja, um aeroporto para outro - o que "civis" normalmente chamam de vôo, como em "Vou pegar meu voo para casa amanhã"),

• marketing: uma série de "voos" de seis meses (normalmente na estação ou fora da estação) de / para um determinado aeroporto no contexto de um contrato.

A analogia da planilha é mais do que suficiente para 99,99% dos casos, mesmo em discursos razoavelmente técnicos (a menos que se seja professor de álgebra relacional). A pessoa que o corrigiu usa a palavra "quem" corretamente? 99,99% das pessoas não, e isso realmente não importa.

Eu geralmente uso "campo" e "coluna" de forma intercambiável, tendendo mais recentemente para "coluna". Eu não ouvi o termo "campo" sozinho para indicar "dados". Também não ouvi o termo "atributo" para indicar "campo" ou "coluna". Uma coluna / campo possui atributos acessíveis através da classe FieldInfo, por exemplo.

Eu acredito que "coluna" é simplesmente uma evolução da terminologia. Os bancos de dados da área de trabalho (xBASE, MSAccess) geralmente usam "campo". M204 usa "campo". Essa terminologia de "campo" foi transportada para o MSOffice xml e outros. Os documentos para Oracle (não me permitem publicar mais links, desculpe) e o MSSQL usam "field" e "column" de forma intercambiável. A Sybase (agora uma empresa SAP) usa predominantemente "coluna", mas às vezes "campo" em sua documentação.

Desde que seu grupo de trabalho concorde com um termo, não importa qual deles. É uma síndrome de "rosa com qualquer outro nome".

Entendo que essa é uma pergunta antiga, mas que ouço com frequência. Minha opinião vem do envolvimento de nossa equipe de dados com nossa equipe de desenvolvimento. Os desenvolvedores definitivamente têm campos nos registros que são mostrados nas telas e esses campos contêm dados que podem ser frequentemente mapeados para colunas com linhas específicas. No entanto, em muitos casos, o método relacional usado para acessar os dados pode alterar o que acaba em uma tela específica em um campo específico.

Registro é uma representação do valor atual que os dados oferecem. Conforme o tempo passa, esses valores podem e provavelmente mudarão, portanto o registro também muda. Os dados para suportar o que é agora e o que era em um determinado momento podem ser facilmente armazenados em um conjunto de tabelas. Os relacionamentos entre os dados determinam os significados que compõem o registro a qualquer momento.

A lógica que deriva dos campos é algo que pode mudar com o tempo. Por exemplo, um funcionário é contratado como Susan Jones e foi contratado em 01/12/2010 como balconista da loja nº 101, que se reporta a Bill Anderson como gerente da loja. Sendo uma empresa progressiva, eles também têm um mentor designado para cada funcionário. O mentor de Susan é Mary Phillips. Mary Phillips é gerente de loja, mas também é gerente regional da loja em que Susan trabalha. Em 11/10/2011, Susan foi promovida a gerente de loja. Não sabemos o que aconteceu com Bill, mas Susan agora é a gerente da loja.

Temos uma tabela de funcionários com nome, número, data de contratação, cargo e localização.

Temos uma tabela de mentores com números de funcionários para os mentores e o funcionário que eles estão orientando, além de datas que descrevem o início e o fim do relacionamento do mentor.

Temos uma tabela de regiões com um nome para a região e um número de gerente atribuído.

Temos outra tabela de locais com endereço, descrição, região e número do gerente.

A tela que exibe informações da loja pode ter um campo para o gerente da loja. O valor para o gerente da loja não é um campo do banco de dados, mas é um valor computável que pode mudar com o tempo. Também o gerente de uma pessoa pode mudar. Os dados que o suportam ainda são armazenados em colunas, mas os relacionamentos entre as colunas foram alterados e, quando reunidos para uma finalidade específica, tornam-se um campo.