1 열 테이블이 좋은 디자인입니까? [닫은]

열이 하나만있는 테이블이 있어도 괜찮습니까? 기술적으로 불법이 아니라는 것을 알고 있지만 설계 불량으로 간주됩니까?

편집하다:

다음은 몇 가지 예입니다.

• 50 개의 유효한 미국 주 코드가있는 테이블이 있지만 자세한 주 이름을 저장할 필요가 없습니다.
• 이메일 블랙리스트.

누군가 키 필드 추가를 언급했습니다. 내가보기에이 단일 열이 기본 키가 될 것입니다.

예, 가장 효율적인 방식으로 테이블을 디자인하는 것은 확실히 좋은 디자인입니다. "Bad RDBMS Design"은 일반적으로 비 효율성에 중점을 둡니다.

그러나 단일 컬럼 설계의 대부분의 경우 추가 컬럼이 도움이 될 수 있음을 발견했습니다. 예를 들어 주 코드는 일반적으로 두 번째 열에 전체 주 이름을 입력 할 수 있습니다. 또는 블랙리스트에 노트가 연결되어있을 수 있습니다. 그러나 디자인에 실제로 해당 정보가 필요하지 않은 경우 단일 열을 사용하는 것이 좋습니다.

의 측면에서 relational algebra이 "의미하는 단항 관계 것 이 일이 존재합니다 "

예, 이러한 관계를 정의하는 테이블이 있어도 좋습니다. 예를 들어 도메인을 정의하는 경우입니다.

물론 이러한 테이블의 값은 자연스러운 기본 키 여야합니다.

의 룩업 테이블이 prime numbers가장 먼저 떠오르는 것입니다.

나는 과거에 그것들을 사용했습니다. 내 고객 중 한 명은 자신이 갖고있는이 큰 목록에있는 전화 번호로 가입하려는 사람을 자동 차단하기를 원했기 때문에 하나의 큰 블랙리스트에 불과했습니다.

타당한 필요가 있다면 문제가 없습니다. 어떤 이유로 든 표시 할 가능성 목록을 원하고 동적으로 변경할 수 있기를 원하지만 다른 테이블에 연결할 필요는 없습니다.

가끔 발견 한 한 가지 사례는 다음과 같습니다.

countries_id 테이블 에는 각 국가에 대한 숫자 ID가있는 열이 하나만 있습니다.

countries_description 테이블 에는 국가 ID가있는 열, 언어 ID가있는 열 및 현지화 된 국가 이름이있는 열이 포함됩니다.

company_factories 테이블 에는 Wich의 국가를 포함하여 회사의 각 공장에 대한 정보가 포함되어 있습니다.

따라서 테이블에서 데이터 일관성 및 언어 독립적 데이터를 유지하기 위해 데이터베이스는 언어 종속성없이 외래 키를 허용하기 위해 단 하나의 열이있는 테이블이있는이 스키마를 사용합니다.

이 경우 하나의 열 테이블의 존재가 정당하다고 생각합니다.

댓글에 대한 응답으로 편집 됨 : Quassnoi

_{(출처 : ggpht.com )}

이 스키마에서 테이블에 Language 열을 포함 할 필요가없는 company_factories 테이블에 외래 키를 정의 할 수 있지만, countries_id 테이블이없는 경우 외래 키를 정의하기 위해 테이블에 Language 열을 포함해야합니다. .

단일 열 테이블이 의미가있는 드문 경우가 있습니다. 유효한 언어 코드 목록이 외래 키로 사용되는 단일 열 테이블 인 데이터베이스를 만들었습니다. 코드 자체가 핵심이기 때문에 다른 키를 갖는 것은 의미가 없습니다. 그리고 언어 코드 설명이 일부 상황에 따라 언어별로 다르기 때문에 고정 된 설명이 없었습니다.

일반적으로 추가 속성이없는 신뢰할 수있는 값 목록이 필요한 경우에는 1 열 테이블에 적합합니다.

물론 앱 디자인이 이미 데이터베이스를 사용하는지 여부에 따라 항상 단일 열 테이블을 사용합니다. 데이터베이스 연결을 설정하는 설계 오버 헤드를 견디고 나면 가능한 모든 변경 가능한 데이터를 테이블에 넣습니다.

단일 열 테이블 OTMH의 두 가지 용도를 생각할 수 있습니다.

1) 데이터 항목이 있습니다. 드롭 다운 목록에서 자주 사용됩니다. 간단한 합법성 테스트에도 사용됩니다.

예 : 두 글자로 된 미국 주 약어; 우리가 배송하는 우편 번호 스크래블에서 합법적 인 단어; 기타

2) 희소 이진 속성, 즉 큰 테이블에서 매우 적은 수의 레코드에만 적용되는 이진 속성. 새 부울 열을 추가하는 대신 속성이 참인 레코드의 키를 포함하는 별도의 테이블을 만들 수 있습니다.

예 : 말기 질병이있는 직원; 360 일 연도의 은행 (대부분 365 사용) 기타

-알.

고유 한 값을 포함하는 한 문제 없습니다.

대부분 설명하신 상태 테이블과 같은 조회 유형 테이블에서 이것을 보았습니다. 그러나 이렇게하는 경우 고유성을 강제하기 위해 열을 기본 키로 설정해야합니다. 이 값을 고유하게 설정할 수없는 경우 하나의 열을 사용하지 않아야합니다.

나는 일반적으로 그렇습니다. 하나의 열만 필요한 이유를 잘 모르겠습니다. 이것에 대한 몇 가지 예외는 내가 효과적으로 사용 된 것으로 보았습니다. 달성하려는 목표에 따라 다릅니다.

데이터베이스의 스키마를 생각할 때 정말 좋은 디자인은 아니지만 실제로는 유틸리티 테이블로만 사용해야합니다.

과거에 효과적으로 사용 된 숫자 테이블을 보았습니다 .

데이터베이스의 목적은 정보를 서로 연관시키는 것입니다. 관련 데이터가 없을 때 어떻게 할 수 있습니까?

아마도 이것이 어떤 종류의 컴파일 테이블 (예 : FirstName + LastName + Birthdate) 일 수도 있지만, 왜 그렇게 하려는지 잘 모르겠습니다.

편집 : 나는 일종의 간단한 목록을 위해 이런 종류의 테이블을 사용하는 것을 볼 수 있습니다. 그것이 당신이 그것을 사용하는 것입니까?

예, 말한대로 필드가 기본 키이면 가능합니다. 그 이유는 중복 데이터를 삽입하면 해당 행이 읽기 전용이기 때문입니다. 중복 된 행 중 하나를 삭제하려는 경우. 서버가 삭제할 행을 알지 못하기 때문에 작동하지 않습니다.

내가 생각할 수있는 유일한 사용 사례는 아마도 단어 게임을위한 단어 표입니다. 문자열이 단어인지 확인하기 위해 테이블에 액세스합니다. 단어 =? 인 단어에서 단어를 선택합니다. 그러나 관계형 데이터베이스 보다 단어 목록을 보관하는 데 훨씬 더 나은 데이터 구조가 있습니다.

그렇지 않으면 데이터베이스의 데이터는 일반적으로 데이터의 다양한 속성 간의 관계를 활용하기 위해 데이터베이스에 배치됩니다. 데이터에 가치 이상의 속성이없는 경우 이러한 관계는 어떻게 발전할까요?

따라서 불법은 아니지만 일반적으로 열이 하나만있는 테이블이 있으면 안됩니다.

모든 테이블에는 4 개 이상의 기술 필드, 직렬 기본 키, 생성 및 수정 타임 스탬프, 소프트 삭제 부울이 있습니다. 블랙리스트에서 누가 항목을 추가했는지 알고 싶을 것입니다. 그래서 저에게 대답은 아니오입니다. 단 하나의 열만있는 테이블은 무언가를 프로토 타이핑 할 때를 제외하고는 의미가 없습니다.

네, 완벽합니다. 그러나 ID 필드는 그것을 다치게 할 수 없었습니까?