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

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

예 : 불치병에 걸린 직원; 360 일 연도의 은행 (대부분 365 사용) 기타

-알.

---

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

---

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

---

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

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

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

---

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

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

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

---

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

---

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

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

So, while not illegal, in general you probably should not have a table with just one column.

---

All my tables have at least four tech fields, serial primary key, creation and modification timestamps, and soft delete boolean. In any blacklist, you will also want to know who did add the entry. So for me, answer is no, a table with only one column would not make sense except when prototyping something.

---

Yes that is perfectly fine. but an ID field couldn't hurt it right?

참고URL : https://stackoverflow.com/questions/951686/is-a-one-column-table-good-design