Kolumna a pole: czy nieprawidłowo używałem tych terminów?

Czuję się trochę zawstydzony, zawsze używałem terminów „kolumna” i „pole” całkowicie zamiennie, co ostatnio spowodowało pewne zamieszanie w dyskusji technicznej.

Powiedziano mi jednak, że to nie jest poprawne, że powinno być (tłumaczenie każdego terminu na terminologię arkuszy kalkulacyjnych, ignorowanie typów danych i wszystkich innych rzeczy, które sprawiają, że bazy danych są przydatne):

• Kolumna bazy danych: jak kolumna arkusza kalkulacyjnego
• Rekord bazy danych: jak wiersz arkusza kalkulacyjnego
• Pole bazy danych: jak „komórka” arkusza kalkulacyjnego (konkretna kolumna określonego wiersza)

Czy to jest poprawne? Mógłbym przysiąc, że kolumna i pole są używane bardziej zamiennie. Z pewnością byłem.

Więc nie dodajemy pól do tabeli, dodajemy kolumny do tabeli, a pola mają znaczenie tylko wtedy, gdy mówimy o danych w rekordzie?

Inne przemyślenia na temat kolumny vs pola?

Edycja: aby wyjaśnić, bieżącym kontekstem jest MS SQL Server. Moim tłem przed serwerem SQL był MS Access, co może mieć wpływ na korzystanie z tych terminów.

Teoria relacyjnych baz danych nie obejmuje użycia słowa Field. Dr EF Codd, który napisał serię artykułów, które stanowią teoretyczne podstawy RDBMS, nigdy nie używał tego terminu. Możesz przeczytać jego przełomowy artykuł z 1970 roku Relacyjny model danych dla dużych banków wspólnych danych, jeśli chcesz to sprawdzić.

Używane są terminy, takie jak Domena, Tabela, Atrybut, Klucz i Tuple. Jednym z powodów tego jest fakt, że jego prace dotyczyły głównie algebry relacyjnej, a sposób, w jaki określona implementacja zdefiniowałaby tabelę w bazie danych, nie był uważany przez Codda za ważny. Sprzedawcy dopracują to później. Ludzie muszą również zrozumieć, że historycznie RDBMS ewoluował z istniejących hierarchicznych i sieciowych baz danych, które je poprzedzały, ORAZ wewnętrzne funkcjonowanie RDMBS nadal musi dotyczyć organizacji i przechowywania danych.

W powszechnym użyciu, i możesz to łatwo zweryfikować, po prostu robiąc trochę google, Pola i kolumny to to samo.

Bazy danych PC, takie jak DBase, Access i Filemaker, zwykle używają „pola” zamiast „kolumny”. „Atrybut” to kolejny termin, którego można używać zamiennie.

Na przykład, oto link do instrukcji MS Access na temat dodawania „ pola ” do tabeli. Widać wyraźnie, że w MS Access „pole” jest równoważne „kolumnie”.

To samo dotyczy Dbase i Filemaker Pro.

Czasami ludzie będą odnosić się do konkretnej wartości w określonym wierszu jako do „pola”, a ściślej do „wartości pola”, ale to nie powoduje, że użycie „pola” w odniesieniu do kolumny lub koncepcji ekwiwalentu kolumny jest nieprawidłowe. Powoduje to zamieszanie, ponieważ ludzie używali słowa „pole” do oznaczania różnych rzeczy przez wiele lat. W teorii relacyjnej pojedyncza wartość atomowa nazywana jest „punktem odniesienia”.

Jeśli ktoś stwierdził, że „pole” to jedna wartość w relacyjnej bazie danych, a nie to samo co kolumna, to jest to ich opinia, ponieważ „pole” nie jest częścią języka relacyjnego w języku narodowym. Nie są ani dobre, ani złe, jednak w całym świecie baz danych pole jest częściej używane do oznaczenia kolumny.

Mając to na uwadze, projekty i zespoły często muszą zrozumieć, w jaki sposób chcą używać określonej terminologii w projekcie, aby uniknąć nieporozumień.

Nie mylisz się, ale możesz także zdecydować się po prostu zastosować konwencję lub uniknąć używania pola słowa na rzecz „kolumny”. W relacyjnych bazach danych „Tabela” i „Kolumna” są elementami składowymi istniejącymi w DDL i najlepiej jest po prostu używać tych terminów i unikać „pola”, które nie jest używane ani jasno zdefiniowane.

Starszy SQL: 92 odnosi się do fieldselementów składowych datetime:

„Pola w elementach daty i godziny” określa pola, które mogą stanowić wartość daty i godziny; wartość daty i godziny składa się z podzbioru tych pól

Pola tutaj to rok, miesiąc itd. ... i fieldwydaje się, że termin ten nie ma żadnego innego znaczenia w pozostałej części dokumentu.

Nowszy standard SQL: 2003 ma to:

Kolumny, pola i atrybuty

Terminy kolumna, pole i atrybut odnoszą się odpowiednio do komponentów strukturalnych tabel, typów wierszy i typów strukturalnych w analogiczny sposób. Ponieważ struktura tabeli składa się z jednej lub więcej kolumn, tak też struktura typu wiersza składa się z jednego lub więcej pól, a struktura typu strukturalnego z jednego lub więcej atrybutów. Każdy element konstrukcyjny, czy kolumna, pole czy atrybut, to przede wszystkim nazwa sparowana z zadeklarowanym typem.

i później:

Pole F jest opisane przez deskryptor pola. Deskryptor pola obejmuje:
- nazwę pola.
- Deskryptor typu danych zadeklarowanego typu F.
- Pozycja porządkowa F w typie wiersza, który ją po prostu zawiera.

Ten kontrast z kolumną, która jest zdefiniowana jako:

Kolumna C jest opisany w deskryptorze kolumny. Deskryptor kolumny obejmuje:
- Nazwę kolumny.
- Czy nazwa kolumny jest nazwą zależną od implementacji.
- Jeśli kolumna jest oparta na domenie, to nazwa tej domeny; w przeciwnym razie deskryptor typu danych deklarowanego typu C.
- Wartość, jeśli w ogóle, C.
- Charakterystyka zerowalności C.
- Pozycja porządkowa C w tabeli, która ją zawiera.
... (i więcej)

Potem, ponownie, wprowadzając tabele:

Tabela to zbiór wierszy mających jedną lub więcej kolumn. Wiersz jest wartością typu wiersza. Każdy wiersz tej samej tabeli ma ten sam typ wiersza. Wartość i-tego pola każdego wiersza w tabeli jest wartością i-tej kolumny tego wiersza w tabeli . Wiersz jest najmniejszą jednostką danych, którą można wstawić do tabeli i usunąć z tabeli.

(moje podkreślenie). Wydaje się to potwierdzać to, co napisałeś w pytaniu: określoną kolumnę określonego wiersza .

A ilu aniołów może tańczyć wokół głowy szpilki?

Osoba, która cię poprawiła, może sama zostać poprawiona.

• Tabela = Relacja

• Row = Tuple

• Kolumna = atrybut

• Domena = typ danych

Zobacz wpis w Wikipedii dotyczący relacyjnych baz danych tutaj .

Pracowałem dla linii lotniczej, a słowa „lot” można używać na trzy różne sposoby, w zależności od tego, czy rozmawiasz z pilotami / stewardessami, inżynierami czy marketingiem.

• piloci / asystenci: „lot” odbył się w obie strony z bazy (tj. dwa starty i dwa lądowania),

• inżynierowie: jeden start i jedno lądowanie mogą być testem, naprawą, szkoleniem (tj. z jednego lotniska z powrotem do tego samego lotniska) lub „etapem”, tj. z jednego lotniska do drugiego - to, co „cywile” normalnie nazywaliby lotem, ponieważ w „Jutro łapię swój lot do domu”),

• marketing: sześciomiesięczna (zazwyczaj w sezonie lub poza sezonem) seria „lotów” z / do danego lotniska w kontekście umowy.

Analogia arkusza kalkulacyjnego jest wystarczająco dobra dla 99,99% przypadków, nawet w rozsądnej mowie technicznej (chyba że ktoś jest profesorem algebry relacyjnej). Czy osoba, która cię poprawiła, poprawnie używa słowa „kogo”? 99,99% ludzi nie ma i to naprawdę nie ma znaczenia.

Ogólnie używam „pola” i „kolumny” zamiennie, ostatnio zmierzając w kierunku „kolumny”. Jednak nie słyszałem terminu „pole” jako określenia „dane”. Nie słyszałem też terminu „atrybut” oznaczający „pole” lub „kolumnę”. Kolumna / pole ma atrybuty, dostępne na przykład za pośrednictwem klasy FieldInfo.

Uważam, że „kolumna” jest po prostu ewolucją terminologii. Pulpity DB (xBASE, MSAccess) zazwyczaj używają „pola”. M204 używa „pola”. Ta terminologia „polowa” została przeniesiona do MSOffice xml i innych. Dokumenty dotyczące Oracle (nie pozwolę, żebym opublikował więcej linków, przepraszam) i MSSQL używają zamiennie „pola” i „kolumny”. Sybase (obecnie firma SAP) używa głównie „kolumny”, ale czasem „pola” w swojej dokumentacji.

Tak długo, jak twoja grupa robocza zgadza się na termin, nie ma znaczenia, który z nich. To syndrom „różany pod jakąkolwiek inną nazwą”.

Zdaję sobie sprawę, że to stare pytanie, ale często to słyszę. Moje podejście wynika z zaangażowania naszego zespołu danych w nasz zespół programistów. Programiści zdecydowanie mają pola w rekordach, które są wyświetlane na ekranach, a pola te zawierają dane, które często można mapować na kolumny z określonymi wierszami. Jednak w wielu przypadkach metoda relacyjna zastosowana do uzyskania dostępu do danych może zmienić to, co kończy się na określonym ekranie w określonym polu.

Zapisuję jest reprezentacją bieżącej wartości dostarczanej przez dane. Z biegiem czasu te wartości mogą i prawdopodobnie będą się zmieniać, więc rekord również się zmienia. Dane wspierające to, co jest teraz i co było w danym momencie, można łatwo przechowywać w zestawie tabel. Zależności między danymi określają znaczenia, które składają się na zapis w danym momencie.

Logika wywodząca się z pól jest czymś, co może się zmieniać w czasie. Na przykład pracownik zostaje zatrudniony jako Susan Jones, a ona została zatrudniona 12/01/2010 jako sprzedawca w sklepie nr 101, który podlega Billowi Andersonowi jako kierownik sklepu. Ponieważ jest to firma postępowa, do każdego pracownika przypisany jest także mentor. Mentorem Susan jest Mary Phillips. Mary Phillips jest kierownikiem sklepu, ale jest także regionalnym kierownikiem sklepu, w którym pracuje Susan. W dniu 11/10/2011 Susan awansowała na kierownika sklepu. Nie wiemy, co się stało z Billem, ale Susan jest teraz kierownikiem sklepu.

Posiadamy tabelę pracowników z imieniem, numerem, datą zatrudnienia, stanowiskiem i lokalizacją.

Mamy tabelę mentorów z numerami pracowników dla mentorów i pracownika, którego mentorują oraz daty opisujące początek i koniec relacji mentora.

Mamy tabelę regionów z nazwą regionu i przypisanym numerem menedżera.

Mamy kolejną tabelę lokalizacji z adresem, opisem, regionem i numerem kierownika.

Ekran, który wyświetla informacje o sklepie, może mieć pole dla menedżera sklepu. Wartość dla menedżera sklepu nie jest polem bazy danych, ale jest wartością obliczalną, która może się zmieniać w czasie. Również menedżer danej osoby może się zmienić. Dane, które ją obsługują, są nadal przechowywane w kolumnach, ale relacje między kolumnami uległy zmianie, a po złożeniu w określonym celu stają się polem.