2010-11-23 5 views
7

필자는 코드가 제대로 작성되지 않은 전자 상거래 사이트를 유지 관리하는 작업을 계승했으며 많은 코드를 리팩터링하고 진행중인 버그를 수정하려고합니다.데이터베이스 테이블의 인덱스에 auto_increment를 사용하지 않는 이유가 있습니까?

모든 데이터베이스 삽입 (항목을 장바구니에 추가하는 등)은 grab_new_id 함수로 시작합니다.이 함수는 테이블의 행 수를 계산 한 다음 그 수로 시작하여 데이터베이스를 쿼리하여 사용하지 않는 인덱스 번호를 찾습니다. 퍼포먼스 측면에서 끔찍한 것 (이미 40,000 개 이상의 행이 있고 인덱스가 정기적으로 삭제되므로 새 ID를 찾기 위해 수 초가 걸리는 경우도 있습니다) 두 개의 작업이 동시에 수행 될 때 두 개의 항목이 추가 될 때 정기적으로 중단됩니다 중복 된 ID 번호.

이것은 바보처럼 보입니다. 인덱스 필드에서 자동 증가를 사용하지 않는 이유는 무엇입니까? 나는 그것을 두 가지 방법으로 테스트했으며 인덱스 ID를 지정하지 않고 테이블에 행을 추가하는 것은 (분명히) 여러 번 더 빠릅니다. 내 질문은 : 누구든지 원래 프로그래머가 이것을했을 수도있는 어떤 이유라도 생각할 수 있습니까? auto_increment가 어떻게 든 나쁜 형태로 여겨지는 곳이 있다는 생각이 있습니까? 자동 증가 기능이없는 데이터베이스가 있습니까?

답변

8

나는 그 기능이 존재하지 않는 사람으로부터 전에 이것을 보아왔다. 확실히 자동 증가 기능을 사용하십시오.

일부 사용자는 모든 기능에 대해 "스스로 나름"방식을 사용합니다. 종종 사람들이 사용 가능한 기능인지 또는 다른 사람이 이미 사용하고 있는지를 알지 못해서 나타납니다. 이 사람들은 종종 미친 해결 방법이나 성능이 좋지 않거나 깨지기 쉬운 코드를 보게됩니다. 나쁜 데이터베이스를 상속하는 것은 전혀 재미 없다. 행운을 비네!

+2

나는 reverseBoolean이라는 C#의 함수를 한 번 보았습니다. 모든 것은 매개 변수로 부울을 받아들이고 그 결과로 역을 반환합니다. 지나치게 복잡하고 평범하지 않았습니다. 개발자가 not 연산자를 알지 못했기 때문에 모두. – theChrisKent

+2

데이터베이스에 플래그가 설정된 경우 모든 트래픽을 https로 강제 설정하는 웹 앱에 대한 모든 요청에 ​​대해 코드를 한 번 실행했습니다. 또한 https에서 IIS의 자동 처리 기능을 사용하여 무한 리디렉션 루프를 만들었습니다. 우리가 무슨 일이 일어나고 있는지 알기 전에 그것은 2 일간의 가벼운 awesomesauce였습니다. – Josh

+0

WTF FTW! 그게 내가 생각한 것 ... 그냥 뭔가를 놓치고 있는지 또는이 기능에 대한 숨겨진 이유가 있는지 알고 싶었습니다. – goldenapples

5

글쎄 오라클은 시퀀스를 가지고 있지만 자동 생성 ID는 이해할 수 없습니다. 그러나 일반적으로 이런 종류의 것들은 데이터베이스 프로그래밍을 이해하지 못하는 사용자와 데이터의 갭을 싫어하는 개발자가 수행합니다 (롤백에서 얻을 때). 또한 ID를 생성하기를 좋아하는 사람들이 있기 때문에 자식 테이블에 사용할 수있는 것이 가능하지만 자동 생성 된 ID가있는 대부분의 데이터베이스는 생성 당시 사용자에게 해당 ID를 반환 할 수있는 방법이 있습니다.

1

그들은 단지 자동 증가에 익숙하지 않은 경험이 없을 수도 있습니다. 필자가 생각할 수있는 한 가지 이유는 반드시 중요하지 않지만, 자동 증가 ID를 사용할 때 한 환경에서 다른 환경으로 데이터를 복사하는 것이 어렵지 않습니다.

이런 이유로 데이터를 쉽게 전환하기 위해 기본 키로 순차적 Guids를 사용했지만 ID를 채우기 위해 행을 계산하는 것은 약간 WTF입니다.

0

ID가 클라이언트에서 생성되어 데이터베이스에 푸시 된 것을 볼 수 있습니다. 이것은 속도가 필요할 때 일반적으로 수행되는 것이지만, 디스크로 작성한 내용은 맨 위에 있고 불필요한 것처럼 보입니다. 이를 제거하고 자동 증가 ID를 시작하십시오.

1

아마 역사적인 이유로 그랬을 것입니다. 즉, 이전 버전에는 autoinc 변수가 없습니다. autoinc 유형을 지원하지 않는 데이터베이스에서 수동 autoinc 필드를 사용하는 코드를 작성했지만 count()를 사용하는 것만큼이나 비효율적 인 코드는 아닙니다.

autoinc 필드를 기본 키로 사용하는 경우의 한 가지 문제점은 테이블로 또는 밖으로 레코드를 이동하면 기본 키가 변경 될 수 있다는 것입니다. 그래서, 테이블의 안팎으로 레코드를 이동할 때 기본 키의 미래 스토리지로 사용할 수있는 "LegacyID"필드를 디자인하는 것이 좋습니다.

3

부분적으로 합리적인 것으로 밝혀진 유일한 문제 (하지만 완전히 피할 수 없음!)는 auto_inc 값을 테이블 정의에 포함시키는 일부 백업 도구가 불편할 수있는 db 덤프에 데이터를 포함하지 않는 경우에도 해당됩니다.

3

특정 상황에 따라 기본 키로 연속 번호를 사용하지 않은 이유는 분명히 많습니다.

다음 내가 할 주어진에서

그러나, 기본 키, 나는이 (가) auto_increment 기능 MySQL을 내장 사용하지 않을 이유를 볼 연속 번호에 대한보고

1

두 가지를 제공합니다 1. RDBMS는 재시작시 자동 증가 값을 지능적으로 설정합니다. 우리 엔지니어는 서버가 다시 시작할 때마다 자동 증가 필드를 100000 단위로 점프하기 위해 자체 자동 증가 키를 돌리고있었습니다. 그러나 어떤 시점에서 Sybase는 자동 증가의 크기를 설정하는 옵션을 추가했습니다.

2. 데이터베이스를 복제하고 마스터 - 마스터 구성을 사용하는 경우 자동 증가가 불쾌해질 수있는 다른 장소입니다. 두 데이터베이스 모두에 대해 (ADVISED가 아닌) 작성하면 신원 충돌이 발생할 수 있습니다.

나는 이것들 중 어느 하나가 의심 스럽지만, 알아 두어야 할 것이있다.

관련 문제