열 대 필드 :이 용어를 잘못 사용 했습니까?

나는 여기서 "난"과 "필드"라는 용어를 완전히 상호 교환 적으로 사용하여 최근에 기술적 인 논의에서 약간의 혼동을 일으켰습니다.

그러나 이것이 정확하지 않다는 말을 들었습니다 (각 용어를 스프레드 시트 용어로 번역하고 데이터 유형과 데이터베이스를 유용하게 만드는 다른 모든 것을 무시 함).

• 데이터베이스 열 : 스프레드 시트 열과 유사
• 데이터베이스 레코드 : 스프레드 시트 행
• 데이터베이스 필드 : 스프레드 시트 "셀"(특정 행의 특정 열)

이게 옳은 거니? 나는 그 열과 필드가 그보다 더 상호 교환 가능하게 사용되었다고 맹세 할 수있었습니다. 나는 그랬다.

따라서 테이블 에 필드 를 추가 하지 않고 테이블에 열 을 추가 하며 필드는 레코드 내의 데이터에 대해 이야기 할 때만 관련이 있습니까?

열 대 필드에 대한 다른 생각?

편집 : 명확히하기 위해 현재 컨텍스트는 MS SQL Server입니다. SQL Server 이전의 저의 배경은 MS Access였습니다.이 용어의 사용에 영향을 줄 수 있습니다.

관계형 데이터베이스 이론에는 Field라는 단어의 사용이 포함되지 않습니다. RDBMS의 이론적 근거를 제공하는 일련의 논문을 쓴 EF Codd 박사는 결코이 용어를 사용하지 않았습니다. 당신 이 확인하고 싶다면 그의 1970 년대 논문 A 공유 데이터 뱅크를위한 데이터의 관계형 모델을 읽을 수 있습니다 .

도메인, 테이블, 속성, 키 및 튜플과 같은 용어가 사용됩니다. 이것의 한 가지 이유는 그의 논문이 관계형 대수학에 크게 관심이 있었고 특정 구현이 데이터베이스에서 테이블을 정의하는 방식이 Codd에 의해 중요하지 않은 것으로 간주 되었기 때문입니다. 공급 업체는 나중에이를 제거 할 것입니다. 또한 사람들은 역사적으로 RDBMS가 이전의 기존 계층 및 네트워크 데이터베이스에서 발전했으며 RDMBS의 내부 작업은 여전히 ​​데이터 구성 및 스토리지와 관련되어 있어야한다는 것을 이해해야합니다.

일반적으로 약간의 인터넷 검색을 수행하여이를 쉽게 확인할 수 있습니다. 필드와 열 은 동일합니다.

DBase, Access 및 Filemaker와 같은 PC 데이터베이스는 일반적으로 "열"대신 "필드"를 사용합니다. "속성"은 서로 바꾸어 사용할 수있는 또 다른 용어입니다.

예를 들어, 다음 은 테이블에 " field "를 추가하는 데 대한 MS Access 매뉴얼 링크 입니다. MS Access에서 "필드"는 "열"과 동일합니다.

Dbase와 Filemaker Pro도 마찬가지입니다.

때때로 사람들은 특정 행의 특정 값을 "필드"또는보다 적절하게 "필드 값"으로 언급하지만 열 또는 열에 해당하는 개념을 잘못 참조 할 때 "필드"를 사용하지 않습니다. 사람들이 "필드"를 사용해 여러 해 동안 다른 것을 의미했기 때문에 이것은 혼동의 정도를 일으키는 경향이 있습니다. 관계 이론에서-단일 원자 값을 "데이텀"이라고합니다.

누군가가 "필드"가 관계형 데이터베이스에서 하나의 값이고 열과 동일하지 않다고 언급 한 경우, "필드"는 관계형 데이터베이스의 고유 한 부분이 아니기 때문에 의견입니다. 그러나 데이터베이스 세계에서 필드는 열을 의미하는 데 더 자주 사용됩니다.

따라서 프로젝트와 팀은 종종 혼동을 피하기 위해 프로젝트 내에서 특정 용어를 어떻게 사용하고 싶은지 이해해야합니다.

당신은 틀리지 않지만, 또한 사용되는 관습을 따르거나 "열"에 찬성하여 단어 필드를 사용하지 않기로 결정할 수도 있습니다. 관계형 데이터베이스에서 "테이블"과 "열"은 DDL에 존재하는 구성 요소이며 이러한 용어를 사용하고 사용되지 않거나 명확하게 정의되지 않은 "필드"를 피하는 것이 가장 좋습니다.

이전 SQL : 92 는 fields날짜 / 시간 항목의 구성 요소입니다.

"날짜 시간 항목의 필드"는 날짜 시간 값을 구성 할 수있는 필드를 지정합니다. 날짜 시간 값은 해당 필드의 서브 세트로 구성됩니다.

여기의 필드는 년, 월 등입니다.이 용어 field는 문서의 나머지 부분에서 다른 의미를 갖지 않는 것 같습니다.

최신 SQL : 2003 표준은 다음과 같습니다.

열, 필드 및 속성

열, 필드 및 속성이라는 용어는 각각 테이블, 행 유형 및 구조화 된 유형의 구조적 구성 요소를 유사한 방식으로 나타냅니다. 테이블의 구조는 하나 이상의 열로 구성되므로 행 유형의 구조는 하나 이상의 필드와 구조화 된 유형의 하나 이상의 속성으로 구성됩니다. 열, 필드 또는 속성에 관계없이 모든 구조 요소는 주로 선언 된 유형과 쌍을 이루는 이름입니다.

그리고 나중에 :

필드 F는 필드의 설명에 의해 설명된다. 필드 설명자에는 다음
이 포함됩니다. — 필드 이름.
— 선언 된 F 유형의 데이터 유형 설명자
— 단순히 그것을 포함하는 행 유형 내에서 F의 서수 위치.

컬럼과의 대조는 다음과 같이 정의됩니다.

열 C는 컬럼 서술자에 의해 설명된다. 열 설명자는 다음을 포함합니다.
— 열 이름.
— 열 이름이 구현 종속적 인 이름인지 여부.
— 열이 도메인을 기반으로하는 경우 해당 도메인의 이름입니다. 그렇지 않은 경우 선언 된 C 유형의 데이터 유형 설명자
— C 의 값 (있는 경우)
— C 의 Null 허용 특성
— C를 포함하는 테이블 내에서 C의 서수 위치입니다.
... (그리고 더)

그런 다음 나중에 테이블을 소개 할 때 :

테이블은 하나 이상의 열이있는 행의 모음입니다. 행은 행 유형의 값입니다. 동일한 테이블의 모든 행은 동일한 행 유형을 갖습니다. 테이블에있는 모든 행의 i 번째 필드 값은 테이블에있는 해당 행의 i 번째 열 값입니다 . 행은 테이블에 삽입하고 테이블에서 삭제할 수있는 가장 작은 데이터 단위입니다.

(강조 광산). 이것은 당신이 질문에 쓴 것을 지원하는 것 같습니다 : 특정 행의 특정 열 .

그리고 핀 머리 주위에 얼마나 많은 천사들이 춤을 출 수 있습니까?

당신을 수정 한 사람은 스스로 고칠 수 있습니다.

• 테이블 = 관계

• 행 = 튜플

• 열 = 속성

• 도메인 = 데이터 유형

관계형 데이터베이스에 대한 Wikipedia 항목을 참조 하십시오 .

나는 항공사를 위해 일했으며 조종사 / 비서 교환 원, 엔지니어 또는 마케팅과 대화하는지에 따라 "비행"이라는 단어가 세 가지 방식으로 사용될 수 있습니다.

• 조종사 / 보조원 : "비행"이 기지에서 나왔다가 (즉, 이륙 및 착륙 2 개),

• 엔지니어 : 이륙 및 착륙은 테스트, 수리, 훈련 (예 : 하나의 공항을 같은 공항으로 다시 연결) 또는 "다리", 즉 하나의 공항을 다른 공항으로 이동시킬 수 있습니다. "내일 비행기를 타려고 해요"에서

• 마케팅 : 계약의 맥락에서 특정 공항을 오가는 6 개월 (일반적으로 온 시즌 또는 오프 시즌) 일련의 "비행".

스프레드 시트 비유는 합리적인 기술 연설에서도 (관계형 대수 교수가 아닌 한) 99.99 %의 경우에 충분합니다. 수정 한 사람이 "whom"이라는 단어를 올바르게 사용합니까? 99.99 %의 사람들은 중요하지 않으며 실제로 중요하지 않습니다.

나는 일반적으로 "필드"와 "컬럼"을 상호 교환 가능하게 사용하며, 더 최근에는 "컬럼"으로 향합니다. 그래도 "데이터"를 나타내는 "필드"라는 용어는 듣지 못했습니다. 또한 "필드"또는 "열"을 나타내는 "속성"이라는 용어를 듣지 못했습니다. 열 / 필드 에는 예를 들어 FieldInfo 클래스를 통해 액세스 할 수있는 속성이 있습니다.

나는 "열"이 단순히 용어의 진화라고 믿습니다. 데스크톱 DB (xBASE, MSAccess)는 일반적으로 "필드"를 사용합니다. M204 는 "필드"를 사용합니다. 이 "필드"용어는 MSOffice xml 및 기타 용어로 사용되었습니다. Oracle 용 문서 (더 이상 링크를 게시 할 수 없으므로 죄송합니다)와 MSSQL은 "필드"와 "열"을 상호 교환하여 사용합니다. Sybase (현재 SAP 회사)는 주로 문서에서 "열"을 사용하지만 때로는 "필드"를 사용합니다.

작업 그룹이 용어에 동의하는 한 어떤 것이 중요하지 않습니다. "다른 이름으로 장미"증후군입니다.

그래서 나는 이것이 오래된 질문이라는 것을 알고 있지만 자주 듣는 질문입니다. 데이터 팀이 개발 팀과의 관계에서 가져 왔습니다. 개발자에게는 화면에 표시되는 레코드 내에 필드가 있고 해당 필드에는 특정 행이있는 열에 자주 매핑 될 수있는 데이터가 들어 있습니다. 그러나 대부분의 경우 데이터에 액세스하는 데 사용되는 관계형 방법은 특정 필드의 특정 화면에서 끝나는 내용을 변경할 수 있습니다.

나는 기록이 데이터가 제공하는 현재 가치를 나타냅니다. 시간이 지남에 따라 해당 값이 변경 될 수 있으며 변경 될 수 있으므로 레코드도 변경됩니다. 현재의 데이터와 주어진 시간의 데이터를 지원하는 데이터를 일련의 테이블에 쉽게 저장할 수 있습니다. 데이터 간의 관계에 따라 주어진 시간에 레코드를 구성하는 의미가 결정됩니다.

필드를 도출하는 논리는 시간이 지남에 따라 변경 될 수 있습니다. 예를 들어, 직원은 Susan Jones로 고용되고 2010 년 12 월 1 일에 상점 # 101의 영업 직원으로 고용되어 Bill Anderson은 매장 관리자로보고합니다. 이것은 진보적 인 회사이기 때문에 각 직원에게 멘토가 할당됩니다. 수잔의 멘토는 Mary Phillips입니다. Mary Phillips는 매장 관리자이지만 Susan이 근무하는 매장의 지역 관리자이기도합니다. 2011 년 11 월 10 일 Susan은 매장 관리자로 승진했습니다. 우리는 Bill에게 무슨 일이 있었는지 알지 못하지만 Susan은 이제 매장 관리자입니다.

우리는 이름, 번호, 고용 날짜, 위치 및 위치를 가진 직원 테이블을 보유하고 있습니다.

우리는 멘토의 직원 번호와 멘토하는 직원과 멘토 관계의 시작과 끝을 설명하는 날짜가있는 멘토 테이블을 가지고 있습니다.

지역 이름과 관리자 번호가 지정된 지역 테이블이 있습니다.

주소, 설명, 지역 및 관리자 번호가있는 다른 위치 테이블이 있습니다.

상점 정보를 표시하는 화면에는 상점 관리자 용 필드가있을 수 있습니다. 상점 관리자의 값은 데이터베이스 필드가 아니지만 시간이 지남에 따라 변경 될 수있는 계산 가능한 값입니다. 또한 개인의 관리자가 변경 될 수 있습니다. 이를 지원하는 데이터는 여전히 열에 저장되지만 열 간의 관계는 변경되었으며 특정 목적으로 조립 될 때 필드가됩니다.