우리는 아직 사용자가 접근 할 수없는 웹 애플리케이션을 개발하고 있습니다. 상사는 테이블에 100 개 미만의 레코드 만 있더라도 새로 작성된 레코드의 ID가 10,000 이상임을 알았습니다. 그녀는 어떤 이유로 든 웹 인터페이스가 실제 레코드보다 100 배 더 많은 임시 레코드를 작성 (삭제)하여 릴리스 후 몇 개월 내에 범위를 벗어날 수 있다고 가정했습니다.
나는 그녀가 ID 인플레이션의 원인에 대해 옳지 않다고 생각합니다 (이에 대답 할 수있는 동료는 휴가 중이므로 확실하지 않습니다). 그녀가 있다고 가정합시다. 그녀는 bigint 열을 사용하는 것을 싫어하고 ID 열 자동 증가를 중지하고 첫 번째 "사용하지 않은"정수를 선택하고이를 ID로 사용하는 서버 측 코드를 작성하고 싶다고 말했습니다.
나는 실무 경험이 거의없는 컴퓨터 공학 대학원생으로, 주니어 개발자 역할을 맡고 있습니다. 그녀는 조직의 모든 데이터베이스를 관리하고 대부분을 설계 한 경험이 있습니다. 나는 이 경우 그녀가 틀렸다고 생각 하고, bigint ID는 두려워 할 것이 없으며 DBMS 기능을 모방하면 반 패턴 냄새가 난다. 그러나 나는 아직 내 판단을 믿지 않습니다.
각 입장에 대한 논쟁은 무엇입니까? bigint를 사용하면 어떤 나쁜 일이 생길 수 있으며 휠 자동 증분 기능 을 다시 개발하면 어떤 위험이 있습니까? 둘 중 하나보다 나은 세 번째 솔루션이 있습니까? ID 액면가의 인플레이션을 피하기 위해 그녀의 이유는 무엇입니까? 나는 실용적 이유에 대해서도 듣고 싶습니다. bigint ID는 이론 상으로는 효과가 있지만 실제로 두통을 유발합니까?
응용 프로그램은 대량의 데이터를 처리 할 것으로 예상되지 않습니다. 앞으로 몇 년 안에 10 만 건의 실제 기록을 달성 할 것으로 의심됩니다.
차이가 있다면 Microsoft SQL Server를 사용하고있는 것입니다. 응용 프로그램은 C #으로 작성되었으며 Linq to SQL을 사용합니다.
최신 정보
감사합니다. 기존 답변과 의견이 흥미로 웠습니다. 그러나 나는 당신이 내 질문을 오해하는 것을 두려워서, 내가 알고 싶은 것을 포함하고 있습니다.
나는 ID가 높은 실제 이유에 대해 정말로 걱정하지 않습니다. 우리가 직접 찾지 못하면 다른 질문을 할 수 있습니다. 내가 관심이있는 것은이 경우의 의사 결정 프로세스를 이해하는 것입니다. 이를 위해 애플리케이션이 하루에 1000 개의 레코드를 작성한 다음 9999 개를 삭제한다고 가정하십시오 . 나는 이것이 사실이 아니라고 확신하지만, 그녀가 요청했을 때 내 상사가 믿었던 것입니다. 따라서 이러한 가상의 상황에서 bigint를 사용하거나 ID를 할당하는 자체 코드를 작성하는 장단점은 무엇입니까 (이미 삭제 된 레코드의 ID를 재사용하여 간격이 없도록)?
실제 이유로, 이것은 나중에 다른 마이그레이션을 어느 정도 수행 할 수 있다는 개념의 증거로 다른 데이터베이스에서 데이터를 가져 오는 코드를 작성했기 때문이라고 생각합니다. 내 동료가 실제로 가져 오는 동안 수천 개의 레코드를 만들어 나중에 삭제했다고 생각합니다. 이것이 실제로 사실인지 확인해야하지만, 그렇다면 실제로 조치가 필요하지 않습니다.