Colonna vs campo: ho usato questi termini in modo errato?

Mi sento un po 'imbarazzato qui, ho sempre usato i termini "colonna" e "campo" in modo completamente intercambiabile, il che di recente ha causato confusione in una discussione tecnica.

Mi è stato detto, tuttavia, che ciò non era corretto, che dovrebbe essere (traducendo ogni termine nella terminologia del foglio di calcolo, ignorando i tipi di dati e tutte le altre cose che rendono utili i database):

• Colonna del database: come una colonna del foglio di calcolo
• Record del database: come una riga del foglio di calcolo
• Campo del database: come una "cella" di foglio di calcolo (una colonna specifica di una riga specifica)

È giusto? Avrei potuto giurare che colonna e campo fossero usati in modo più intercambiabile di quello. Lo sono stato sicuramente.

Quindi non aggiungiamo campi a una tabella, aggiungiamo colonne a una tabella e i campi sono rilevanti solo quando si parla di dati all'interno di un record?

Altri pensieri su colonna vs campo?

Modifica: per chiarire, il contesto attuale è MS SQL Server. Il mio background prima di SQL Server era MS Access, che potrebbe influenzare il mio uso di questi termini.

La teoria dei database relazionali non include l'uso della parola Field. Il Dr. EF Codd, che ha scritto la serie di articoli che forniscono le basi teoriche per i RDBMS non ha mai usato il termine. Puoi leggere il suo fondamentale documento del 1970 Un modello relazionale di dati per grandi banche dati condivise se vuoi controllare.

Vengono utilizzati termini come dominio, tabella, attributo, chiave e tupla. Uno dei motivi di ciò è che i suoi articoli erano in gran parte interessati all'algebra relazionale e il modo in cui una particolare implementazione avrebbe definito una tabella in un database non era considerato da Codd importante. I venditori lo avrebbero risolto più tardi. Le persone devono anche capire che storicamente, i RDBMS si sono evoluti dai database gerarchici e di rete esistenti che li precedono, E i meccanismi interni di un RDMBS devono ancora occuparsi dell'organizzazione e della memorizzazione dei dati.

Nell'uso comune, e puoi verificarlo facilmente semplicemente facendo un po 'di ricerche su Google, i campi e le colonne sono la stessa cosa.

Database di PC come DBase, Access e Filemaker utilizzano in genere "campo" anziché "colonna". "Attributo" è un altro termine che può essere usato in modo intercambiabile.

Ad esempio, ecco un link al manuale di MS Access sull'aggiunta di un " campo " a una tabella. È chiaro che in MS Access un "campo" equivale a una "colonna".

Lo stesso vale per Dbase e Filemaker Pro.

A volte le persone faranno riferimento a un valore specifico in una riga specifica come un "campo" o più correttamente un "valore di campo", ma ciò non rende errato l'uso di "campo" quando si fa riferimento a un concetto di colonna o equivalente di colonna. Questo tende a creare un livello di confusione perché le persone hanno usato "campo" per significare cose diverse per molti anni. Nella teoria relazionale - un singolo valore atomico è indicato come "Datum".

Se qualcuno ha dichiarato che un "campo" è un valore in un database relazionale e non uguale a una colonna, è questa la sua opinione, poiché "campo" non fa parte del volgare del database relazionale. Non sono né giusti né sbagliati, tuttavia, nel mondo del database, il campo è più spesso usato per indicare la colonna.

Detto questo, i progetti e i team devono spesso capire come vogliono usare una particolare terminologia all'interno del progetto per evitare confusione.

Non ti sbagli, ma potresti anche decidere di seguire semplicemente la convenzione in uso, o evitare di usare del tutto il campo parola a favore di "colonna". Con i database relazionali, "Tabella" e "Colonna" sono i mattoni che esistono in DDL ed è meglio usare solo quei termini ed evitare "campo" che non viene utilizzato, né chiaramente definito.

Il precedente SQL: 92 si riferisce a fieldscome componenti di elementi datetime:

"Campi in elementi datetime", specifica i campi che possono costituire un valore di data e ora; un valore datetime è costituito da un sottoinsieme di tali campi

I campi qui sono anno, mese e così via ... e il termine fieldnon sembra avere alcun altro significato nel resto del documento.

Il nuovo standard SQL: 2003 ha questo:

Colonne, campi e attributi

I termini colonna, campo e attributo si riferiscono a componenti strutturali di tabelle, tipi di riga e tipi strutturati, rispettivamente, in modo analogo. Poiché la struttura di una tabella è composta da una o più colonne, la struttura di un tipo di riga è composta da uno o più campi e quella di un tipo strutturato uno o più attributi. Ogni elemento strutturale, che sia una colonna, un campo o un attributo, è principalmente un nome associato a un tipo dichiarato.

e più tardi:

Un campo F è descritto da un descrittore di campo. Un descrittore di campo include:
- Il nome del campo.
- Il descrittore del tipo di dati del tipo dichiarato di F.
- La posizione ordinale di F all'interno del tipo di riga che semplicemente lo contiene.

Questo contrasto con la colonna, definita come:

Una colonna C è descritta da un descrittore di colonna. Un descrittore di colonna include:
- Il nome della colonna.
- Se il nome della colonna è un nome dipendente dall'implementazione.
- Se la colonna si basa su un dominio, quindi il nome di quel dominio; in caso contrario, il descrittore del tipo di dati del tipo dichiarato di C.
- Il valore, se presente, di C.
- La caratteristica di nullità di C.
- La posizione ordinale di C all'interno della tabella che lo contiene.
... (e altro)

Poi di nuovo, quando si introducono le tabelle:

Una tabella è una raccolta di righe con una o più colonne. Una riga è un valore di un tipo di riga. Ogni riga della stessa tabella ha lo stesso tipo di riga. Il valore dell'i-esimo campo di ogni riga in una tabella è il valore dell'i-esima colonna di quella riga nella tabella . La riga è la più piccola unità di dati che può essere inserita in una tabella ed eliminata da una tabella.

(enfasi la mia). Questo sembra supportare ciò che hai scritto nella domanda: una colonna specifica di una riga specifica .

E quanti angeli possono ballare intorno alla testa di uno spillo?

La persona che ti ha corretto potrebbe essere corretta.

• Tabella = relazione

• Riga = Tupla

• Colonna = Attributo

• Dominio = Tipo di dati

Vedi la voce di Wikipedia sui database relazionali qui .

Ho lavorato per una compagnia aerea e la parola "volo" potrebbe essere usata in tre modi diversi a seconda che tu parlassi con piloti / assistenti di volo, ingegneri o marketing.

• piloti / assistenti: un "volo" era di andata e ritorno dalla base (ovvero due decolli e due atterraggi),

• ingegneri: un decollo e un atterraggio, potrebbero essere test, riparazioni, addestramento (ad esempio un aeroporto di ritorno nello stesso aeroporto) o una "tratta", ovvero un aeroporto per un altro - ciò che i "civili" normalmente chiamerebbero un volo, come in "Prenderò il mio volo di ritorno a casa domani"),

• marketing: una serie di sei voli (tipicamente di stagione o fuori stagione) di sei voli da / per un determinato aeroporto nel contesto di un contratto.

L'analogia del foglio di calcolo è più che sufficiente per il 99,99% dei casi, anche in discorsi ragionevolmente tecnici (a meno che uno non sia un professore di algebra relazionale). La persona che ti ha corretto usa correttamente la parola "chi"? Il 99,99% delle persone non importa e non importa davvero.

In genere uso "campo" e "colonna" in modo intercambiabile, più recentemente tendendo verso "colonna". Tuttavia, non ho sentito il termine "campo" da solo per indicare "dati". Inoltre non ho sentito il termine "attributo" per indicare "campo" o "colonna". Una colonna / campo ha attributi, accessibili ad esempio tramite la classe FieldInfo.

Credo che "colonna" sia semplicemente un'evoluzione della terminologia. I DB desktop (xBASE, MSAccess) utilizzano generalmente "field". M204 usa "campo". Questa terminologia "sul campo" è stata introdotta in MSOffice xml e altri. I documenti per Oracle (non mi consente di pubblicare altri collegamenti, mi dispiace) e MSSQL usano "campo" e "colonna" in modo intercambiabile in tutto. Sybase (ora una società SAP) utilizza prevalentemente "colonna" ma talvolta "campo" nella sua documentazione.

Fintanto che il gruppo di lavoro concorda un termine, non importa quale. È una sindrome "rosa con qualsiasi altro nome".

Quindi mi rendo conto che questa è una vecchia domanda, ma è una che sento spesso. La mia opinione deriva dal coinvolgimento del nostro team di dati con il nostro team di sviluppo. Gli sviluppatori hanno sicuramente dei campi all'interno dei record che vengono mostrati sugli schermi e quei campi contengono dati che possono essere frequentemente associati a colonne con righe specifiche. Tuttavia, in molti casi il metodo relazionale utilizzato per accedere ai dati può modificare ciò che finisce su una determinata schermata in un determinato campo.

Ho registrato è una rappresentazione del valore corrente che i dati forniscono. Col passare del tempo questi valori possono e probabilmente cambieranno, quindi anche il record cambia. I dati per supportare ciò che è ora e ciò che era in un determinato momento possono essere facilmente archiviati in un set di tabelle. Le relazioni tra i dati determinano i significati che compongono il record in qualsiasi momento.

La logica che deriva i campi è qualcosa che può cambiare nel tempo. Ad esempio, un dipendente viene assunto come Susan Jones e lei è stata assunta il 12/01/2010 come commessa nel negozio n. 101 che riferisce a Bill Anderson come responsabile del negozio. Essendo una società progressista, hanno anche un mentore assegnato a ciascun dipendente. Il mentore di Susan è Mary Phillips. Mary Phillips è una responsabile del negozio ma è anche una responsabile regionale del negozio in cui Susan lavora. L'11 / 10/2011 Susan è stata promossa responsabile del negozio. Non sappiamo cosa sia successo a Bill, ma Susan ora è il responsabile del negozio.

Abbiamo una tabella di dipendenti con nome, numero, data di assunzione, posizione e posizione.

Abbiamo una tabella di mentori con i numeri dei dipendenti per i mentori e il dipendente che stanno guidando più le date che descrivono l'inizio e la fine della relazione del mentore.

Abbiamo una tabella delle regioni con un nome per la regione e un numero gestore assegnato.

Abbiamo un'altra tabella di posizioni con indirizzo, descrizione, regione e numero gestore.

Lo schermo che visualizza le informazioni del negozio potrebbe avere un campo per il gestore del negozio. Il valore per store manager non è un campo di database ma è un valore calcolabile che può cambiare nel tempo. Anche il manager di una persona può cambiare. I dati che lo supportano sono ancora archiviati in colonne ma le relazioni tra le colonne sono cambiate e quando vengono assemblate per uno scopo specifico diventa un campo.