나는 외래 키와 그 같은 것들을 포스트 그레스 (postgres)에 대해 읽었으며 외래 키에 대한 계단식 업데이트가 가능하다는 것을 알았다.언제 기본 키 값을 변경해야합니까?
음, 내 질문은 언제 행의 기본 키를 업데이트해야합니까?
분명히이 사람은 http://www.oreillynet.com/onlamp/blog/2004/10/hey_sql_fans_check_out_foreign.html이 필요하지만 분명히 유용 할 수있는 방법을 이해하지 못했습니다.
편집 : 자연 기본 키의 경우 사용 방법을 참조하십시오. 그러나 기술 기본 키는 어떻습니까? 그 의미는 없으며 거의 항상 자동으로 자동 생성됩니다.
음 ... 우리는 사람이 읽을 수있는 코드로 정의 된 많은 기본 키를 가지고 있습니다. 끔찍한 생각이지만 문제는별로 선택하지 않습니다.
누군가가 철자가 틀리거나 의미가 변경되었다는 것을 깨달을 때 PK와 모든 종속 레코드를 수정할 수 있으면 매우 편리합니다.
기본 키를 대용 키 대신 자연 키로 선택한 다음 나중에 사용자가 성을 변경했거나 응용 프로그램 양식에 SSN을 잘못 작성했다는 사실을 알게 된 경우이를 수행해야합니다.
이야기의 도덕 : 기본 키로 자연 키를 사용하지 마십시오.
자연어 기본 키 (문제 도메인에 실제 의미가있는 키)를 사용하는 경우이 작업이 필요할 수 있습니다. 의미가 바뀌면 변경 사항을 캐스케이드해야합니다.
나는 나쁜 예가 학교 캠퍼스에있는 건물의 데이터베이스이며 건물 이름을 기본 키로 가정했습니다 (집에서하지 마십시오). 건물의 이름이 으로 바뀌면 뇌물을 기증 한 후 키를 변경해야합니다.
내 PK를 제 3 자 시스템에 노출시킬 때 PK를 여러 번 변경해야했습니다. 때로는 데이터베이스에서 기록을 맞추기 위해 PK를 변경하라고 요청하는 경우가 종종있었습니다 (기술 문제로 인해 수시로 두 시스템 간의 동기화가 실패 함).
몇 번이고 PK를 노출하고 새로운 열을 추가했습니다.
자동 증가 열과 같은 합성, 의미없는 기본 키의 경우 PK 값을 업데이트 할 이유가 없어야합니다 (예외는 있음). PK가 사용자가 볼 수있는 값이면이를 업데이트해야 할 수도 있습니다 (이는 합성 키를 사용하는 많은 인수 중 하나입니다). 이 상황의 예는 보험 증권 번호입니다. 어떤 경우에는 그 해가 그 숫자의 일부이며 매 갱신마다 똑같은 일을 반복 할 수 있습니다. 일부 데이터 모델에서는 레코드가 그대로 업데이트됩니다.
이렇게되면 다른 항목이 보이는 숫자에 종속되지 않도록 합성 키를 사용하는 것이 좋습니다.
두 개 이상의 응용 프로그램 데이터베이스를 함께 병합하는 경우 통합 키를 업데이트해야 할 수도 있습니다. 이 경우 다른 소스의 레코드 키와의 충돌을 피하려면 키를 한꺼번에 이동해야 할 수도 있습니다.
자연어 기본 키를 사용하면 이러한 상황이 발생할 수 있습니다.
크로아티아 정부에서는 기업 및 개인의 세금 식별 번호를 변경했습니다. 2010 년 1 월 1 일에 새 법률이 도입되었습니다.
작년에 저는 회사가 기존 응용 프로그램에서 자연어 (이전 세금 번호)를 변경하여 여러 프로젝트에서 컨설턴트를 맡았습니다. Natural Key는 법률에 의해 정의 되었기 때문에 이러한 앱의 원 디자이너에게 논리적 인 선택으로 보였습니다. 그리고 그것은 바뀌었다.
자동 생성 된 키의 경우 두 개의 데이터베이스 테이블을 병합해야하는 경우 여기에 나온 (예를 들어 기억할 수없는) 한 가지 예가 있습니다. 이 경우 키가 충분히 벗어난 경우를 제외하고는 중복이 발생할 가능성이 높습니다.
기본 키는 '시리얼'(자동 증가 고유 번호) 이외의 다른 것을 사용하기 때문에 기본적으로 작동하지 않습니다 (이유가 있음). – Earlz
다 대다 관계를 설명하는 표는 어떨까요? 기본 키는 관련 두 외래 키의 조합입니까? 당연히 불필요한 직렬 기본 키가 필요하지 않습니까? –
전체 다중 열 기본 키 비트가 작동하는 방식에 너무 현명하지 않습니다. – Earlz