SPA의 테이블에 대한 GUID 또는 ID

Question

오늘 오후 동료들과 GUIDS 필드와 IDENTITY 필드의 주요 장점을 기본 키로 논의했습니다. 큰 데이터 배경에서 나는 본능적으로 IDENTITY와 함께 갔지만 더 많은 웹 지향적 인 GUID를 선호했습니다.

장점과 단점의 대부분은 잘 문서화 및 훌륭하게 여기에 요약되어 있습니다 :

http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

을하지만 내 동료는 내가 대답 할 수있는 점을했고,도 구글을 수, 나는 생각 그것은 흥미로운 질문이었습니다. 단일 페이지 응용 프로그램 스타일 시스템에서 자바 스크립트 모델 (예 : Breeze JS)은 커밋하기 전에 서버 왕복을 줄이기 위해 가능한 많은 데이터베이스 변경 사항을 일시적으로 보관하는 데 자주 사용됩니다. 이렇게되면 다른 삽입으로 인해 표의 IDENTITY 필드가 증가 할 확률이 높아집니다. 물론, 커밋을 시도 할 때 혼란을 야기 할 수 있습니다.

이 시나리오에서는 SPA가 일반적으로 데이터베이스 수준에서 성능 병목 현상을 보이지 않기 때문에 일반적으로 대신 GUID를 사용하는 것이 더 바람직합니까? 또는 커밋 할 여러 변경 사항을 스택하는 잠재적 인 문제를 과장하고 있습니까?

Answer 1

Jay가 말했듯이 상점 생성 ID가있는 경쟁 조건에 대해 걱정할 필요가 없습니다. Breeze는 임시 키를 사용하여 데이터베이스 계층의 영구 키로 확인됩니다. 걱정 마세요.

그러나 나는 일반적으로 Guides를 다른 이유로 선호합니다. 이는 서버 측 효율성에 대한 관심과 관심이 적은 클라이언트 측 개발자로서 저를 대면하는 문제의 영향을 받았습니다.

분산 응용 프로그램 (예 : Breeze 응용 프로그램)에서 Guides를 사용하는 가장 좋은 이유는 오프라인 시나리오를 훨씬 쉽게 지원할 수 있다는 것입니다. 엔티티를 내보내고 가져올 때 Breeze가 매우 잘 처리하는 임시 키는 저장되지 않은 새 엔티티를 클라이언트 측 저장소 (예 : 브라우저 저장소)에 저장할 때 그대로 유지됩니다. 이 패턴은 오프라인 상태가 아니더라도 유용합니다. 사용자가 워크 플로우를 진행하면서 저장되지 않은 작업을 로컬에 숨겨 놓는 경우가 있습니다. 실수로 브라우저를 실수로 닫을 경우에 대비해.

사실, Guides는 서버 측 사람들에게별로 문제가되지 않습니다. 시간에 영향을받는 가이드 (예 : GuidComb)를 사용하여 조각화 문제를 해결할 수 있습니다. 스토리지 및 인덱싱 성능 문제는 빠른 h/w 및 향상된 DB로 줄어 듭니다.대리 키를 볼 필요가있는 유일한 사람은 개발자입니다. 우리는 고통을 겪기 위해 보수를 받는다.

필자는 많은 데모를 작성하며 정수 ID 키를 사용하면 작성자와 독자가 쉽게 작업 할 수 있다는 데는 의심의 여지가 없습니다. 데모가 건전한 안내를 제공한다고 생각하지 않습니다.

실제로는 ID가 아닐지라도 키 데이터 유형을 혼합하여 사용합니다. 내 정적 참조 엔터티 (조회 : 상태, 미국 상태 등) 및 거의 변경되지 않은 엔터티 (제품 카탈로그의 제품)는 일반적으로 정수 키입니다. 그들은 읽기 쉽고 설정하기 쉽습니다 (그리고 부수적으로 더 쉽게 저장). 고객이 자주 만드는 항목 (예 : 주문)은 Guides를 사용합니다.

답변이 하나도 없습니다. 마일리지는 다양합니다. 여기에 진부를 삽입하십시오.

Answer 2

질문에 대답하고 있지만 Breeze에서 ID 열을 사용하는 경우 Breeze는 저장하기 전에 새로운 엔터티에 대한 임시 ID 값을 자동으로 생성합니다. 서버에서 "실제"ID가 생성되면 Breeze는 임시 ID를 실제 ID로 매핑하여 클라이언트에 보내고 클라이언트 ID를 수정하여 새로운 "실제"ID와 일치시킵니다. ID 값 생성은 저장 중에 데이터베이스에 의해 완전히 처리되므로 실수로 ID를 재사용하고 ID 열을 사용할 때 커밋이 실패하는 실제 문제는 없습니다. 아티팩트는 "추가 된"모든 레코드 (ID 또는 서버 생성 키와 관련된 레코드)의 ID가 저장 완료에 따라 자동으로 변경된다는 것입니다.

그렇다면 Guides를 사용하면 아무 것도 필요하지 않습니다. 수정이 필요없고 클라이언트 ID는 저장의 결과로 변경되지 않습니다. Guids는 약간 더 커지는 경향이 있으며 '신원 정보 열 (identity column)'보다 지역성이 낮아 (따라서 저장 속도가 느려질 수 있음) 즉, 일반적으로 기존 테이블에 추가되는 대신 데이터베이스를 통해 분산됩니다. (Sequential Guids는 이것을 부분적으로 보완합니다).

두 기술 모두 실행 가능하며 지지자가 있습니다. 모든 것이 평등하지만, 나는 개인적으로 Guids를 선호합니다. 나는 단순함을 좋아한다.