Coluna x Campo: tenho usado esses termos incorretamente?

A teoria de banco de dados relacional não inclui o uso da palavra Campo. Dr. EF Codd, que escreveu a série de artigos que fornecem a base teórica para RDBMS, nunca usou o termo. Você pode ler seu artigo seminal de 1970, A Relational Model of Data for Large Shared Data Banks , se quiser verificar.

Termos como Domínio, Tabela, Atributo, Chave e Tupla são usados. Uma razão para isso é que seus artigos 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 por 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 simplesmente 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 Dbase e Filemaker Pro.

Às vezes, as pessoas se referem a um valor específico em uma linha específica como sendo um "campo" ou, mais propriamente, um "valor de campo", mas isso não torna incorreto o uso de "campo" ao se referir a uma coluna ou a um conceito de coluna equivalente. Isso tende a causar um nível de confusão porque as pessoas usaram "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, projetos e equipes geralmente precisam entender como desejam usar uma terminologia específica dentro do projeto para evitar confusão.

Você não está errado, mas também pode decidir simplesmente seguir a convenção que está sendo usada ou evitar usar a palavra campo completamente em favor de "coluna". Com bancos de dados relacionais, "Tabela" e "Coluna" são os blocos de construção que existem em DDL e é melhor usar apenas esses termos e evitar "campo" que não é usado, nem claramente definido.

O SQL:92 mais antigo refere-se a fieldscomponentes 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 por um subconjunto desses campos

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

O padrão SQL:2003 mais recente tem isso:

Colunas, campos e atributos

Os termos coluna, campo e atributo referem-se a componentes estruturais de tabelas, tipos de linha e tipos estruturados, respectivamente, de maneira análoga. Assim 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 em um ou mais atributos. Cada elemento estrutural, seja uma coluna, um campo ou um atributo, é principalmente um nome emparelhado com 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 dentro do tipo de linha que simplesmente o contém.

Este 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, 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 dentro da tabela que o contém.
... (e mais)

Depois, 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 em uma tabela é o valor da i-ésima coluna dessa linha na tabela . A linha é a menor unidade de dados que pode ser inserida em uma tabela e excluída de uma tabela.

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

E quantos anjos podem dançar em volta da cabeça de um alfinete?

A pessoa que corrigiu você poderia ser corrigida.

• Tabela = Relação

• Linha = Tupla

• Coluna = Atributo

• Domínio = Tipo de dados

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

Trabalhei para uma companhia aérea e a palavra "voo" pode ser usada de três maneiras diferentes, dependendo de você estar falando com pilotos/comissários de bordo, engenheiros ou marketing.

• pilotos/atendentes: um "voo" estava saindo e voltando da base (ou seja, duas decolagens e duas aterrissagens),

• engenheiros: uma descolagem e uma aterragem, pode ser teste, reparação, treino (ou seja, um aeroporto de volta ao mesmo aeroporto) ou uma "perna", ou seja, um aeroporto para outro - o que os "civis" normalmente chamariam de voo, como em "Vou pegar meu voo para casa amanhã"),

• marketing: uma série de seis meses (normalmente na temporada ou fora da temporada) de "voos" 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 discurso razoavelmente técnico (a menos que um seja professor de álgebra relacional). A pessoa que corrigiu você 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, mais recentemente tendendo 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.

Acredito que "coluna" é simplesmente uma evolução da terminologia. DBs de desktop (xBASE, MSAccess) geralmente usam "campo". M204 usa "campo". Essa terminologia de "campo" foi transportada para o xml do MSOffice e outros. Os documentos para Oracle (não me deixarão postar mais links, desculpe) e MSSQL usam "campo" e "coluna" 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. É uma síndrome de "rosa por qualquer outro nome".

Então eu percebo que esta é uma pergunta antiga, mas é uma que eu ouço com frequência. Minha opinião sobre isso vem do envolvimento que nossa equipe de dados tem com nossa equipe de desenvolvimento. Os desenvolvedores definitivamente têm campos dentro de 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.

Eu registro é uma representação do valor atual que os dados entregam. Com o passar do tempo, esses valores podem e provavelmente mudarão, então 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. As relações entre os dados determinam os significados que compõem o registro em um determinado momento.

A lógica que deriva os campos é algo que pode mudar ao longo do tempo. Por exemplo, uma funcionária é contratada como Susan Jones e ela foi contratada em 01/12/2010 como balconista na loja nº 101 que se reporta a Bill Anderson como gerente da loja. Sendo uma empresa progressista, eles também têm um mentor atribuído a cada funcionário. A mentora de Susan é Mary Phillips. Mary Phillips é gerente de loja, mas também é gerente regional da loja em que Susan trabalha. Em 10/11/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 mais as 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 as informações da loja pode ter um campo para gerente da loja. O valor para gerente de loja não é um campo de 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 montados para uma finalidade específica, tornam-se um campo.