왜 테이블의 기본 키 열 "Id"를 명명하는 것이 나쁜 습관으로 간주됩니까? [닫은]

내 t-sql 교사는 PK 열 "Id"의 이름을 지정하는 것은 더 이상의 설명 없이는 나쁜 습관으로 간주됩니다.

테이블 PK 열 "Id"의 이름을 지정하는 것이 나쁜 습관으로 간주되는 이유는 무엇입니까?

나는 나와서 말할 것입니다 : 그것은 실제로 나쁜 습관이 아닙니다 (그렇더라도 그렇게 나쁜 것은 아닙니다 ).

Chad가 지적한 대로 다음 쿼리와 같이 오류를 마스크 할 수 있다고 주장 할 수 있습니다.

SELECT * 
    FROM cars car
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

그러나 테이블 이름에 작은 별칭을 사용하지 않으면 쉽게 완화 할 수 있습니다.

SELECT * 
    FROM cars
    JOIN manufacturer
        ON manufacturer.Id = cars.ManufacturerId
    JOIN models
        ON models.Id = cars.ModelId
    JOIN colors
        ON manufacturer.Id = cars.ColorId

3 자 약어를 사용하는 항상 연습은 열 이름을 사용하는 것보다 훨씬 나빠 보입니다 id. (사례 : 실제로 테이블 이름 cars을 약어로 약칭하는 사람은 누구 car입니까? 그 끝은 무엇입니까?)

요점은 일관 적입니다. 회사에서 ID를 사용하고 일반적으로 위의 오류가 발생하면 전체 테이블 이름을 사용하는 습관을들이십시오. 회사에서 Id 열을 금지하는 경우이를 진지하게 취하고 원하는 명명 규칙을 사용하십시오.

이와 같은 문제를 다루지 않고 실제로는 나쁜 습관 (예 : 여러 개의 중첩 된 상관 하위 쿼리) 인 학습에 집중하십시오. 열의 이름을 "ID"로 지정하는 문제는 나쁜 습관보다는 맛의 문제에 더 가깝습니다.

편집자 주 :이 쿼리의 오류는 의도적 인 것이며 지적하는 데 사용됩니다. 편집하기 전에 전체 답변을 읽으십시오.

외래 키가있는 테이블이 있으면 해당 외래 키의 이름을 "Id"로 지정할 수 없기 때문입니다. 테이블 이름이 TableId입니다.

그리고 당신의 조인은

SELECT * FROM cars c JOIN manufacturer m ON m.Id = c.ManufacturerId

이상적으로는 조건이 양쪽에서 동일한 필드 이름을 가져야합니다.

SELECT * FROM cars c JOIN manufacturer m ON m.ManufacturerId = c.ManufacturerId

따라서 Id의 이름을 ManufacturerId로 지정하는 것은 불필요한 것처럼 보이지만 실수가 분명 해짐에 따라 결합 조건에 오류가있을 가능성이 줄어 듭니다.

이것은 간단 해 보이지만 여러 테이블을 조인하면 실수를 할 가능성이 높아지고 아래 테이블을 찾으십시오.

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.Id = car.ManufacturerId
    JOIN models mod
        ON mod.Id = car.ModelId
    JOIN colors col
        ON mfg.Id = car.ColorId

적절한 이름을 지정하면 오류가 발생합니다 ...

SELECT * 
    FROM cars car 
    JOIN manufacturer mfg
        ON mfg.ManufacturerId = car.ManufacturerId
    JOIN models mod
        ON mod.ModelId = car.ModelId
    JOIN colors col
        ON mfg.ManufacturerId = car.ColorId

ID의 이름을 "나쁜"것으로 지정하는 또 다른 이유는 여러 테이블에서 정보를 쿼리 할 때 ID 열의 이름을 바꿔야 구분할 수 있기 때문입니다.

SELECT   manufacturer.Id as 'ManufacturerId'
        ,cars.Id as 'CarId'
        --etc
    FROM cars 
    JOIN manufacturer
        ON manufacturer.Id = cars.Id

정확한 이름으로 이것은 문제가되지 않습니다

Ruby의 ActiveRecord 라이브러리와 Groovy의 GORM은 기본적으로 서로 게이트 키에 "id"를 사용합니다. 나는이 연습을 좋아한다. 각 열 이름에 테이블 이름을 복제하면 중복되고 작성하기가 지루하며 읽기가 더 지루합니다.

"Name"또는 "Id"와 같은 공통 또는 키 열 이름 앞에 TableName을 붙여야합니다.

모호성을 제거하고 쉽게 검색 할 수 있으며 두 "Id"값이 모두 필요한 경우 열 별칭이 훨씬 적습니다.

덜 사용되거나 감사 열 또는 키가 아닌 것 (예 : LastUpdatedDateTime)은 중요하지 않습니다

이 스레드는 죽었지 만 IMO 를 사용 하지 않는Id 것은 나쁜 습관 이라고 덧붙이고 싶습니다 . Id열은 특별하다; 그것은이다 기본 키. 모든 테이블에는 여러 개의 외래 키가있을 수 있지만 기본 키는 하나만있을 수 있습니다. 모든 기본 키가 호출되는 데이터베이스에서 테이블을 확인하자마자 기본 열이 어떤 열인지 정확히 알 수 있습니다.Id

나를 믿어, 지금 몇 달 동안 매일 많은 데이터베이스 (Salesforce)에서 일하면서 하루를 보냈고 스키마에 대해 말할 수있는 가장 좋은 것은 모든 테이블에 기본 키가 있다는 것 Id입니다. PK가 호출되기 때문에 기본 키를 외래 키에 조인하는 것에 대해 절대 혼란스러워하지 않을 것 Id입니다. 사람들이 언급하지 않은 또 다른 사항은 테이블이 길고 바보 같은 이름을 가질 수 있다는 것입니다 Table_ThatDoesGood_stuff__c. 그 이름은 건축가가 그 테이블을 생각한 아침에 숙취가 있었기 때문에 충분하지 않지만 이제는 기본 키를 호출하지 않는 것이 나쁜 습관이라고 말하고 있습니다 Table_ThatDoesGood_stuff__cId (SQL 열 이름은 일반적으로 대소 문자를 구분하지 않음을 기억하십시오).

솔직히 말해서, 컴퓨터 프로그래밍을 가르치는 대부분의 사람들이 가진 문제는 수년 동안 생산 코드 라인을 작성하지 않았으며 작동하는 소프트웨어 엔지니어가 실제로 무엇을하는지 전혀 모른다는 것입니다. 당신이 일을 시작할 때까지 기다렸다가 자신의 생각이 좋은 생각인지 아닌지 스스로 생각하십시오.

나는 그것이 나쁜 습관이라고 생각하지 않습니다. 평소와 같이 일관성은 왕입니다.

나는 그것이 맥락에 관한 것이라고 생각합니다. 표 자체의 맥락에서 "id"는 정확히 예상 한 것을 의미하며, 그렇지 않으면 동일하거나 다른 것처럼 보일 수있는 다른 라벨과 고유하게 식별하는 데 도움이되는 레이블입니다.

조인의 맥락에서 조인을 구성하여 귀하와 팀이 읽을 수 있도록하는 것은 귀하의 책임입니다. 잘못된 문구 나 이름을 지정하여 상황을 어렵게 만들 수있는 것처럼 별칭과 주석을 효과적으로 사용하여 의미있는 쿼리를 구성 할 수 있습니다.

'Foo'라는 Java 클래스에는 'Foo'라는 접두사가 붙지 않는 속성이 있으므로 테이블 ID 앞에 테이블 이름을 붙일 필요가 없습니다. 일반적으로 컨텍스트 에서 참조되는 ID가 무엇인지 명확 합니다.

에서 data.stackexchange.com

붐, 질문에 대답했다.
이제 교사에게 나쁜 데이터베이스 디자인을 연습한다고 알려주십시오.

테이블에서 자연스러운 조인을 수행하기가 어렵고 혼란 스럽습니다. 그래서별로 나쁘지 않으면 나쁩니다.

자연 조인은 SQL Lore (예 : 관계형 대수)의 고대 유물이며 다음 중 하나를 보았을 것입니다. 내 말은 Natrual Join은 DBMS가 그것을 구현하는 데 영원히 걸리는 것처럼 보이지만 새로운 SQL 아이디어가 아니라는 것을 의미합니다. 따라서 그것을 구현하는 새로운 아이디어는 아닙니다. 오늘날의 존재.

기본 키의 ID를 모두 지정하면 자연스러운 조인의 간편함과 단순함을 잃게됩니다. 또는을 select * from dudes natural join cars작성해야합니다 . 자연스럽게 참여할 수 있다면 관계가 실제로 무엇인지 무시할 수 있습니다.select * from dudes inner join cars where cars.dudeid = dudes.idselect * from dudes inner join cars where dudes.carid = cars.id

모든 테이블에서 "ID"를 사용하는 것이 최선의 아이디어가 아닌 상황이 있습니다. USING키워드 (지원되는 경우). 우리는 MySQL에서 자주 사용합니다.

예를 들어 fooTablecolumn fooTableId과 barTableforeign key가 fooTableId있으면 쿼리를 다음과 같이 구성 할 수 있습니다.

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

그것은 타이핑을 절약 할뿐만 아니라 대안에 비해 훨씬 더 읽기 쉽다 :

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)

왜 선생님에게 물어 보지 않겠습니까?

모든 테이블 PK 열의 이름을 지정할 때 ID외래 키로 사용하면 악몽이됩니다.

열 이름은 의미 적으로 중요해야합니다. ID일반입니다.

다음과 같은 이유로 ID가 잘못되었습니다.

많은보고 쿼리를 수행하는 경우 둘 다 표시하려면 항상 열의 별칭을 지정해야합니다. 따라서 처음에는 이름을 올바르게 지정할 수있는 시간 낭비가됩니다. 이 복잡한 쿼리는 불필요한 작업을 수행하는 추가 부담없이 충분히 어렵습니다 (수백 줄 길이의 쿼리 작성).

코드 오류가 발생할 수 있습니다. 자연 조인을 사용할 수있는 데이터베이스를 사용하는 경우 (내가 사용하지 않아야한다고 생각하지만 기능을 사용할 수있을 때 누군가가 사용할 것입니다) 그것을 사용하는 개발자가 있으면 잘못된 일에 참여하게됩니다.

복잡한 쿼리를 만들기 위해 조인을 복사하는 경우 별칭을 원하는 별칭으로 변경하고 잘못된 조인을 얻는 것을 잊어 버리기 쉽습니다. 각 ID의 이름이 테이블 이름을 따서 명명되면 일반적으로 구문 오류가 발생합니다. pPK 이름과 FK 이름이 일치하면 복잡한 쿼리의 조인이 잘못되었는지 쉽게 확인할 수 있습니다.

테이블에서 기본 키의 열 이름으로 "id"를 사용하지 않는 가장 중요한 이유 인 일관성 및 모호성 감소에 대한 몇 가지 대답이 있습니다.

그러나 유지 보수 프로그래머, 특히 원래 개발에 관여하지 않은 유지 보수 프로그래머는 주요 이점을 실현할 수 있습니다. Person 테이블의 ID에 "PersonID"라는 이름을 사용하고 해당 이름을 외래 키로 일관되게 사용한 경우 "PersonID"를 유추하지 않고 PersonID가있는 테이블을 찾기 위해 스키마에 대해 쿼리를 작성하는 것이 쉽지 않습니다. 외래 키일 때 사용되는 이름입니다. 옳고 그른 외래 관계가 모든 프로젝트에 항상 적용되는 것은 아닙니다.

하나의 테이블에 동일한 테이블에 대한 두 개의 외래 키가 필요할 수있는 가장 좋은 경우가 있지만이 경우 원래 키 이름을 열의 접미사 이름으로 지정하면 와일드 카드 일치 % PersonID를 쉽게 찾을 수 있습니다 그 경우도 마찬가지입니다.

예, "id"를 갖고 항상 "tableNameID"로 사용한다는 표준을 통해이 중 상당 부분을 달성 할 수 있습니다.하지만 실제로는 연습이 적절한 지 알고 있으며 원래 개발자에 따라 덜 수행해야합니다. 직관적 인 표준 연습.

일부 사람들은 더 긴 열 이름을 작성하기 위해 추가 키 입력이 필요하다고 지적했지만 코드 작성은 프로그램의 활성 수명의 작은 부분 일 뿐이라고 주장합니다. 개발자 키 입력을 저장하는 것이 목표라면 주석을 작성해서는 안됩니다.

수백 개의 테이블이있는 대규모 프로젝트를 유지 관리하는 데 오랜 세월을 보낸 사람으로서 테이블 전체의 키에 대해 일관된 이름을 선호합니다.

기본 키 필드로 ID를 사용하면 모든 테이블에 ID가 추가됩니다. 많은 테이블에는 이미 레코드를 고유하게 식별하는 고유 정보가 있습니다. THAT를 기본 키로 사용하고 각 테이블에 추가하는 id 필드가 아닙니다. 이것이 관계형 데이터베이스의 기초 중 하나입니다.

그렇기 때문에 id를 사용하는 것이 나쁜 습관입니다. id는 종종 자동 증가 정보가 아닙니다.

다음 표를 고려하십시오.

PK id | Countryid   | Countryname
    1 |         840 | United States
    2 |         528 | the Netherlands

이 표의 문제점은 사용자가 다른 코드를 추가 할 수 있다는 것입니다. 물론 개별 열에 고유성을 적용하거나 이미 사용 가능한 기본 키를 사용할 수 있습니다.

PK Countryid   | Countryname
           840 | United States
           528 | the Netherlands

이렇게하면 관계형 데이터베이스 디자인의 핵심 인 기본 키로 이미 가지고있는 정보를 사용할 수 있습니다.

나는 항상 사용하는 프레임 워크 (Ruby on Rails, CakePHP)의 규칙이기 때문에 모든 테이블의 기본 열 이름으로 'id'를 사용하므로 항상 재정의 할 필요가 없습니다.

그것은 저에게 학문적 인 이유를 이길 수 없습니다.

제대로 사용하면 나쁜 습관이라고 생각하지 않습니다. "ID"라는 자동 증분 ID 필드를 사용하면 손대지 않아도되고 응용 프로그램에 대해보다 친숙한 식별자를 사용하는 것이 일반적입니다. 코드를 작성하는 것은 약간 번거로울 from tableA a inner join tableB b on a.id = b.a_id수 있지만 해당 코드를 숨길 수 있습니다.

개인적 선호로 ID 앞에 접두사 이름을 붙이는 경향이 있지만 Id데이터베이스가 완전히 처리 하는 경우 에만 실제 문제가 발생하지 않습니다 .

ID는 충분히 일반적이므로 다른 사람을 혼란스럽게 생각하지 않습니다. 항상 테이블을 알고 싶을 것입니다. 테이블 / 별칭을 포함하지 않고 필드 이름을 프로덕션 코드에 넣는 것은 좋지 않습니다. 임시 쿼리를 신속하게 입력 할 수있는 것에 대해 너무 걱정이된다면 스스로해야합니다.

ID가 예약어 인 SQL 데이터베이스를 아무도 개발하지 않기를 바랍니다.

CREATE TABLE CAR (ID);

하나의 멋진 작은 2 문자 패키지에서 1부터 시작하여 필드 이름, 기본 키 및 자동 증분을 1 씩 처리합니다. 아, 그리고 그것을 CARS라고 불렀을 것입니다. 그러나 우리가 키 스트로크를 절약하고 누가 CAR이라는 테이블이 하나만 가질 것이라고 생각한다면?

이 질문은 계속해서 되풀이되어 왔지만 저 역시 저의 의견을 추가 할 것이라고 생각했습니다.

1. id를 사용하여 각 테이블의 식별자임을 의미하므로 테이블에 조인하고 기본 키가 필요할 때 자동으로 기본 키에 조인합니다.

2. id 필드는 자동 증분이며 부호가 없습니다 (값을 설정할 필요가 없으며 음수가 될 수 없음을 의미)

3. 외래 키의 경우 tablenameid (스타일 문제)를 사용하지만 결합하는 기본 키는 테이블의 id 필드이므로 일관성은 항상 쿼리를 쉽게 확인할 수 있음을 의미합니다.

4. id도 짧고 달콤합니다

5. 추가 규칙-모든 테이블 및 열 이름에 소문자를 사용하므로 대소 문자로 인한 문제가 없습니다.

고려해야 할 또 다른 사항은 기본 키 이름이 외래 키 이름과 다른 경우 특정 타사 도구를 사용할 수 없다는 것입니다.

예를 들어 Visio와 같은 도구에 스키마를로드하고 정확한 ERD를 생성 할 수 없습니다.

여기서 사람들이 거의 모든 측면을 다루고 있지만 "id"는 "식별자"로 읽히지 않아야하며 "인덱스"로 읽혀서는 안된다고 덧붙이고 싶습니다. (여기서 잘못된 단어를 사용했을 수도 있습니다.

사람들이 테이블 데이터를 읽는 방법과 코드를 작성하는 방법은 어느 정도입니다. 나는 개인적으로 그리고 가장 많이 이것이 내가 가장 자주 보는 방법은 코더 table.id가 노조 또는 조인을 할 필요가 없더라도 전체 참조를로 쓰는 것 입니다. 예를 들면 다음과 같습니다.

SELECT cars.color, cars.model FROM cars WHERE cars.id = <some_var>

그렇게하면 "번호가 매겨진 자동차의 색상과 모델을 알려주십시오."로 영어로 번역 할 수 있습니다. "번호로 식별되는 자동차의 색상과 모델을 알려주십시오." ID는 어떤 식 으로든 차를 나타내지 않습니다. 차의 색인 일뿐입니다. 배열에서 세 번째 요소를 가져 오려는 경우와 같습니다.

그래서 내가 추가하고 싶은 것을 요약하면 그것은 단지 선호의 문제이며 설명 된 SQL 읽기 방법이 가장 인기가 있다는 것입니다.

그러나 ID가 실제로 설명하는 문자열 인 경우와 같이 사용되지 않는 경우가 있습니다 (훨씬 드문 예). 예를 들어 id = "RedFordMustang1970"또는 이와 유사한 것. 아이디어를 얻기 위해 적어도 이것을 설명 할 수 있기를 바랍니다.