5
Partner Id 또는 Account Number과 같이 비즈니스 엔티티 식별자로 자동 증가 기본 키를 사용하는 것이 좋지 않습니까?데이터베이스의 기본 키를 비즈니스 객체 식별자로 사용하는 것은 나쁜 생각입니까?
또한 접근 방식을 선택하면 내가 당할 수있는 함정은 무엇입니까?
A
답변
5
나는 모두가 같은 의견을 가지고 있다고 생각하지 않지만, 나는 나쁜 습관이라고 생각한다. 내 생각에 여러 가지 이유로 '키'가 사용자에게 ID를 전달하는 데는 여러 가지 이유가 있습니다.
- ID는 사용자에게 자연스럽지 않습니다. 그들은 '1474623'프로젝트에 대해 이야기하지 않고 있으며, 그들은 'ABC'프로젝트에 대해 이야기하고 있습니다. 그들은 사람 '363528'에 대해 말하지 않고 있으며, 그들은 'Patrick Hofman'에 대해 이야기하고 있습니다.
- ID가 깨지기 쉽습니다. 당신은 정말로 변하지 않는 그들에게 의지 할 수 없습니다. 다른 데이터베이스 플랫폼 또는 현재 플랫폼의 새 버전으로 이동하고 'insert'문을 사용하여 모든 데이터를 이동하려는 경우 ID 필드를 잃어 버릴 수 있습니다.
우리 제품에는 항상 사람이 이해할 수있는 기본 키 옆에 'natural key'이 사용됩니다.
사람이 이해할 수있는 자연 키가 없으면 (예 : 로깅 테이블 인 경우) 인공 키로 되돌릴 수 있습니다.
+0
나는 OP가 자신이 만든 PK에 그것을 사용하는 것이 좋은지 물어보고있다. 또한 수년간 지원 개발자 역할로 응용 프로그램 사용자와 함께 작업하면서 사용자가 실제로 ID 형식 번호에 래치하는 경향이 있음을 발견했습니다. "안녕하세요? 레코드 번호 14567을 보시고 설명이 혼란 스럽다면 알려주시겠습니까?" 내주의 사항은 GUID가 PK로 사용되는 경우입니다. 그렇다면 자연 키를 사용하는 것이 좋습니다.하지만이 경우 사용자에게 실제 PK를 표시하지 않습니다. – MER
+0
@mer : 나는 pk를 대체 할 충고를 절대 추천하지 않는다. 그것은 심지어 불가능합니다. –
+0
나는 명확성이 결여되어 사과드립니다. 나는 그에게 PK로 자연스러운 키를 사용하도록 말할 것을 제안하지 않았다. (http://www.agiledata.org/essays/keys.html (point 2)가 가능할지라도 그것은 나쁜 생각이다) . 나의 경험에서, 사용자는 숫자를 참조하는 아이디어를 좋아하지 않지만 생성 된 숫자를 응용 프로그램의 주어진 레코드에 대한 기본 참조 지점으로 사용하는 것으로 빠르게 전환해야합니다 (레코드 의미 계정 #, 파일 # 또는 프로젝트 # etc ...와 같은 응용 프로그램에 표시된 모든 수집 된 데이터). – MER
3
키를 선택하거나 디자인 할 때 염두에 두어야 할 3 가지 바람직한 특성이 있습니다 (단순성, 안정성 및 친숙 함). 실제로 사람들은 종종 단순한 숫자가 아닌 단어와 문자로 기억하고 작업하는 것이 더 간단하다는 것을 알기 때문에 영숫자 식별자가 일반적으로 숫자 전용 식별자 (영숫자 식별자의 예 : 자동차 번호판, 항공사 편명 번호, 좌석 예약 번호, 주 및 국가 번호, 우편 번호, 이메일 주소). 영숫자 키가 숫자 만 사용하는 것보다 더 유용하다는 아이디어를 뒷받침하는 연구 및 기념 증거가 있습니다. 또한 영숫자 식별자는 종종 숫자 식별자보다 짧을 수 있습니다. 반면, 순차 숫자 전용 식별자는 일부 애플리케이션 (예 : 인보이스 번호, 은행 계좌 번호)에서 매우 일반적입니다. 따라서 이러한 사항을 결정할 때는 사용자/비즈니스 요구 사항에 따라 안내해야합니다.
DBMS 엔진 수준의 시퀀스 생성기에는 종종 일부 응용 프로그램에 적합하지 않은 제한이 있습니다. 예를 들어 분산 데이터베이스 아키텍처에서 업데이트하거나 사용하는 것이 쉽지 않을 수 있습니다. 다른 공통 제한 사항은 테이블 당 하나의 "자동 증가"열만 허용 될 수 있기 때문에 같은 테이블에 대한 대리 키를 원할 경우 비즈니스 키로 사용할 수 없습니다.
+0
은 이전에 언급 할 수있는 부분이 없다는 점을 지적하면서, 자동 증분 된 기본 키는 데이터가 여러 데이터베이스에서 고유해야하는 응용 프로그램 설계에서 문제가 될 수 있습니다.이 경우 PK로 GUID에 의존합니다. 그러나 실제 응용 프로그램을 사용하는 실제 사용자의 일화에 대한 경험은 처음에 질문 할 때 이름이 더 쉬울 것이라고 믿었지만 응용 프로그램을 사용하는 몇 주 이내에 대리 키 값을 훨씬 더 자주 언급한다고 생각했습니다. 이름, (심지어 완전한 숫자 값). – MER
관련 문제
- 1. 기본 키를 계산하는 것은 나쁜 생각입니까?
- 2. ScheduledActionService.LaunchForTest를 사용하는 것은 나쁜 생각입니까?
- 3. 왜 Object [] 배열을 사용하는 것은 나쁜 생각입니까?
- 4. 큰 정적 변수를 사용하는 것은 나쁜 생각입니까?
- 5. recordId를 해시 코드로 사용하는 것은 나쁜 생각입니까?
- 6. mod_perl2에서 fork하는 것은 나쁜 생각입니까?
- 7. 네이티브 메서드를 재정의하는 것은 왜 나쁜 생각입니까?
- 8. 안드로이드에 SQLite Cursor를 저장하는 것은 나쁜 생각입니까?
- 9. ORM없이 ASP.NET MVC를 수행하는 것은 나쁜 생각입니까?
- 10. 데이터베이스에 속성 테이블을 포함시키는 것은 나쁜 생각입니까?
- 11. 모델을 디렉토리로 나누는 것은 나쁜 생각입니까?
- 12. WxWidgets 및 GTK를 실행하는 것은 나쁜 생각입니까?
- 13. 클로저를 사용하여 캡슐화를 에뮬레이트하는 것은 나쁜 생각입니까?
- 14. JFrame을 확장하는 것은 항상 나쁜 생각입니까?
- 15. 하위 뷰로 nil을 추가하는 것은 나쁜 생각입니까?
- 16. Ruby와 Python을 동시에 배우는 것은 나쁜 생각입니까?
- 17. NSUserDefaults를 글로벌 인스턴스 변수의 일종으로 사용하는 것은 나쁜 생각입니까?
- 18. 프록시 톰캣에 아파치 HTTPD를 사용하는 것은 나쁜 생각입니까
- 19. 새로운 동적 키워드를 대체 switch 문으로 사용하는 것은 나쁜 생각입니까?
- 20. Rhino.Commons의 단위 작업과 저장소를 사용하는 것은 나쁜 생각입니까?
- 21. jQuery에서 모든 선택자에 [name = X]를 사용하는 것은 나쁜 생각입니까?
- 22. 사용자 정의 pk를 문자열로 사용하는 것은 나쁜 생각입니까?
- 23. 한정된 Queue에서 배열을 데이터 구조로 사용하는 것은 왜 나쁜 생각입니까?
- 24. backbonejs를 유료 서비스 사이트로 사용하는 것은 나쁜 생각입니까?
- 25. 좋은/나쁜 비즈니스 객체 디자인?
- 26. 유니 코드 기호를 Java 식별자로 사용하는 것이 좋은 생각입니까?
- 27. 레일 : 모델 내에 더블 바이트 문자를 넣는 것은 나쁜 생각입니까?
- 28. C에서 매크로를 사용하여 버퍼를 지우는 것은 나쁜 생각입니까?
- 29. 헬프 데스크 할당을위한 RSS 피드를 구현하는 것은 나쁜 생각입니까?
- 30. 소멸자를 구하기 - 나쁜 생각입니까?
ID 나 숫자를 사용하는 것이 나쁜 생각이라고는 생각하지 않습니다. 그것은 달려있다. 종종 ID와 숫자가 완벽합니다. 자신에게 물어보십시오 : 다른 열쇠는 무엇을 생각하고 있었습니까? 그리고 그게 더 나아질까요? 나는 본질적으로 더 좋다고 생각하지 않는다. 숫자가있는 속임수는 1로 시작하지 않고 한 ID는 1000000으로 시작하고 다른 하나는 20000000 등으로 시작합니다. – tvCa
@tvCa : 물론 ID 또는 숫자 자체는 아닙니다. 데이터베이스 고유 정보의 일부로 자동 증가 ID를 의미합니다. – Vokinneberg
@Vokinneberg 질문을 명확히하십시오. "사업자 식별자로"라고 말하면 이는 명확한 진술이 아닙니다. 우리 대부분은 비즈니스를 고객으로 생각한다고 생각합니다. 그러나 귀하의 의견은 당신이 테이블에 대한 기본 키에 이상적이라는 것을 의미합니다. 그리고 그 질문에 대한 대답은 당신이 자동 증분 컬럼과 PK로 정의 할 때 PK에 대한 좋은 적합성입니다 ... GUID를 생성하지 않는 한 ... 또한 고객에게 자동 증가 값인 계좌 번호를 표시하는 것은 괜찮습니다 ...GUID가 아닌 한 – MER