SQL Server 데이터베이스 개발 의 21 가지 법칙

여기 서 저 는 SQL Server 를 사용 하 는 요령 을 소개 하지 않 고 모든 병 을 치료 하 는 방안 을 제공 할 수 없습니다.제 가 한 것 은 경험 을 정리 하 는 것 입 니 다.-어떻게 좋 은 디자인 을 형성 하 는 지 에 관 한 것 입 니 다.이런 경험 은 내 가 지난 몇 년 동안 겪 은 교훈 에서 비롯 되 었 다.나 는 똑 같은 디자인 오류 가 반복 되 는 것 을 많이 보 았 다.1.당신 이 사용 하 는 도 구 를 이해 하고 이 점 을 경시 하지 마 세 요.이것 은 제 가 이 글 에서 말 한 가장 관건 적 인 것 입 니 다.아마도 많은 SQL Server 프로그래머 들 이 T-SQL 명령 과 SQL Server 가 제공 하 는 유용 한 도 구 를 모두 파악 하지 못 한 것 을 보 았 을 것 입 니 다."뭐?나 는 영원히 사용 하지 않 을 SQL 명령 을 배 우 는 데 한 달 의 시간 을 낭비 할 것 이다.그렇게 말 할 지도 몰라.그래,너 는 이렇게 할 필요 가 없어.하지만 주말 에 모든 T-SQL 명령 을 훑 어 봐 야 합 니 다.여기 서 당신 의 임 무 는 미래 에 당신 이 조 회 를 설계 할 때'맞다,여기 내 가 필요 로 하 는 기능 을 완전히 실현 할 수 있 는 명령 이 있다'는 것 을 알 게 되 는 것 입 니 다.그래서 MSDN 에 가서 이 명령 의 정확 한 문법 을 보 세 요.2.커서 를 사용 하지 마 세 요.다시 한 번 말씀 드 리 겠 습 니 다.커서 를 사용 하지 마 세 요.만약 당신 이 전체 시스템 의 성능 을 파괴 하고 싶다 면,그것들 은 오히려 당신 의 가장 효과 적 인 첫 번 째 방법 입 니 다.대부분의 초보 자 들 은 성능 에 미 치 는 영향 을 의식 하지 못 하고 커서 를 사용한다.그들 은 메모 리 를 차지 하고 신기 한 방식 으로 시 계 를 잠 그 며 마치 달팽이 같다.최 악의 경 우 는 DBA 가 할 수 있 는 모든 성능 을 최적화 시 킬 수 있다 는 것 이다.매번 FETCH 를 실행 할 때마다 SELECT 명령 을 실행 하 는 것 과 같다 는 것 을 아 십 니까?이것 은 만약 당신 의 커서 가 10000 개의 기록 이 있다 면,그것 은 10000 번 의 SELECT 를 실행 할 것 이라는 것 을 의미 합 니 다!만약 당신 이 SELECT,UPDATE 또는 DELETE 를 사용 하여 해당 하 는 일 을 완성 한다 면 훨씬 효율 적일 것 입 니 다.초보 자 들 은 일반적으로 커서 를 사용 하 는 것 이 비교적 익숙 하고 편안 한 프로 그래 밍 방식 이 라 고 생각 하지만 불행 하 게 도 이것 은 나 쁜 성능 을 초래 할 수 있다.분명히 SQL 의 전체적인 목적 은 무엇 을 실현 하 는 것 이지 어떻게 실현 하 는 것 이 아니다.저 는 T-SQL 로 커서 기반 저장 과정 을 다시 썼 습 니 다.그 시 계 는 100,000 개의 기록 만 있 고 원래 의 저장 과정 은 40 분 이 걸 려 서 실 행 했 습 니 다.새로운 저장 과정 은 10 초 밖 에 걸 리 지 않 았 습 니 다.여기 서 당신 은 직무 에 적합 하지 않 은 프로그래머 가 도대체 무엇 을 하고 있 는 지 볼 수 있 을 것 이 라 고 생각 합 니 다!!우 리 는 작은 프로그램 을 써 서 데 이 터 를 얻 고 처리 하 며 데이터 베 이 스 를 업데이트 할 수 있다.이렇게 하면 때때로 더욱 효과 적일 수 있다.기억 하기:순환 에 있어 서 T-SQL 은 무력 합 니 다.나 는 다시 한 번 일 깨 워 주 었 다.커서 를 사용 하면 좋 을 게 없다.DBA 작업 외 에 나 는 커서 를 사용 하면 어떤 일 도 효과적으로 완성 할 수 있다 는 것 을 본 적 이 없다.3.데이터 시트 를 규범화 하 는 것 은 왜 데이터 베 이 스 를 규범화 하지 않 습 니까?성능 에 대한 고려 와 순 전 히 게 으 름 때 문 이라는 두 가지 핑계 가 있 을 것 이다.두 번 째 점 에 대해 서 는 조만간 이 때문에 대 가 를 치 러 야 한다.성능 에 관 한 문 제 는 느 리 지 않 은 것 을 최적화 할 필요 가 없다.나 는 일부 프로그래머 들 의'반 규범화'데이터 베 이 스 를 자주 본다.그들의 이 유 는'원래 의 디자인 이 너무 느리다'는 것 이지 만 결 과 는 그들 이 시스템 을 더욱 느리게 만 들 었 다.DBMS 는 규범 화 된 데이터 베 이 스 를 처리 하기 위해 설계 되 었 으 므 로 규범 화 된 요구 에 따라 데이터 베 이 스 를 설계 하 는 것 을 기억 하 라.4.SELECT*를 사용 하지 마 세 요.이 점 은 쉽 지 않 습 니 다.저 는 너무 잘 알 고 있 습 니 다.제 가 자주 이렇게 하기 때 문 입 니 다.그러나 SELECT 에서 필요 한 열 을 지정 하면 다음 과 같은 장점 을 가 져 올 수 있 습 니 다.1.메모리 소모 와 네트워크 대역 폭 을 줄 이 고 2.더 안전 한 디자인 을 얻 을 수 있 습 니 다.그 러 려 면 예술 이 야.표 에 색인 을 추가 할 때마다 SELECT 는 더 빨 라 집 니 다.그러나 INSERT 와 DELETE 는 크게 느 려 집 니 다.색인 을 만 들 려 면 추가 작업 이 필요 하기 때 문 입 니 다.분명히 이 문제 의 관건 은 네가 이 시계 에 대해 어떤 조작 을 하려 고 하 느 냐 하 는 것 이다.이 문 제 는 잘 파악 되 지 않 습 니 다.특히 DELETE 와 UPDATE 와 관련 될 때 이 문 구 는 WHERE 부분 에 SELECT 명령 을 자주 포함 하기 때 문 입 니 다.6.'성별'열 에 색인 을 만 들 지 마 십시오.우선 색인 이 표 에 대한 접근 을 어떻게 가속 화 하 는 지 알 아야 합 니 다.색인 을 일정한 기준 에 따라 표를 구분 하 는 방식 으로 이해 할 수 있다.만약 당신 이'성별'과 같은 열 에 색인 을 만 들 었 다 면,당신 은 시 계 를 두 부분 으로 나 누 었 을 뿐 입 니 다.남자 와 여자.당신 은 1,000,000 개의 기록 이 있 는 시 계 를 처리 하고 있 습 니 다.이런 구분 은 어떤 의미 가 있 습 니까?기억 하기:색인 을 유지 하 는 데 시간 이 걸 립 니 다.색인 을 디자인 할 때 이러한 규칙 을 따 르 십시오.열 에 따라 서로 다른 내용 을 포함 할 수 있 는 수량 이 많 을 때 부터 적 게 배열 할 수 있 습 니 다.예 를 들 어 이름+성+성별.7.사 무 를 사용 할 때 사 무 를 사용 하 십시오.특히 조회 시간 이 비교적 오래 걸 립 니 다.만약 시스템 에 문제 가 생기 면,이렇게 하면 너의 생명 을 구 할 것 이다.일반적으로 일부 경험 이 있 는 프로그래머 들 은 모두 경험 을 가지 고 있 습 니 다.-당신 은 예측 할 수 없 는 상황 에 자주 부 딪 히 면 저장 과정 이 무 너 질 수 있 습 니 다.8.자물쇠 가 일정한 순서에 따라 당신 의 시 계 를 방문 하지 않도록 조심 하 세 요.만약 당신 이 먼저 시계 A 를 잠 그 고 시계 B 를 잠 그 면 모든 저장 과정 에서 이 순서에 따라 그것들 을 잠 가 야 합 니 다.만약 당신 이(무심코)어떤 저장 과정 에서 먼저 표 B 를 잠 그 고 표 A 를 잠 그 면 자물쇠 가 사라 질 수 있 습 니 다.잠 금 순서 가 미리 상세 하 게 설계 되 지 않 으 면 잠 금 자 물 쇠 는 쉽게 발견 되 지 않 는 다.9.큰 데이터 세트 를 열지 마 세 요.자주 제기 되 는 문 제 는 제 가 어떻게 해야만 100000 개의 기록 을 ComboBox 에 신속하게 추가 할 수 있 습 니까?이것 은 옳지 않다.너 는 이렇게 할 필요 도 없다.간단 합 니 다.사용 자 는 100000 개의 기록 을 훑 어 봐 야 필요 한 기록 을 찾 을 수 있 습 니 다.그 는 반드시 당신 을 저주 할 것 입 니 다.여기 서 더 좋 은 UI 가 필요 합 니 다.사용자 에 게 100 개 이상 또는 200 개 이상 의 기록 을 표시 해 야 합 니 다.10.서버 엔 드 커서 와 서버 엔 드 커서 를 사용 하지 마 십시오.클 라 이언 트 커서 는 서버 와 네트워크 의 시스템 비용 을 줄 일 수 있 고 잠 금 시간 도 줄 일 수 있 습 니 다.11.매개 변 수 를 사용 하여 조회 할 때 저 는 CSDN 기술 포럼 에서 이와 같은 문 제 를 보 았 습 니 다."SELECT*FROM a WHERE a.id='A'B,작은 따옴표 조회 에 이상 이 생 겼 기 때문에 저 는 어떻게 해 야 합 니까?"일반적인 대답 은 작은 따옴표 대신 작은 따옴표 두 개 를 사용 하 는 것 이다.이것 은 잘못된 것 이다.이렇게 하면 근본 적 인 문 제 를 해결 하지 못 합 니 다.왜냐하면 당신 은 다른 문자 에서 이런 문 제 를 만 날 수 있 기 때 문 입 니 다.게다가 이렇게 하면 심각 한 bug 를 초래 할 수 있 습 니 다.그 밖 에 이렇게 하면 SQL Server 의 버퍼 시스템 이 제 역할 을 발휘 하지 못 할 수도 있 습 니 다.매개 변 수 를 사용 하여 조회 하고,근본 적 인 문 제 는 모두 존재 하지 않 는 다.12.프로그램 인 코딩 을 할 때 빅 데 이 터 를 사용 하 는 데이터 베이스 프로그래머 가 개발 에서 사용 하 는 테스트 데이터 베 이 스 는 보통 데이터 양 이 많 지 않 지만 최종 사용자 의 데이터 양 이 매우 많다.우리 의 일반적인 방법 은 옳지 않다.이 유 는 매우 간단 하 다.현재 하드디스크 는 그리 비 싸 지 않 지만,왜 성능 문 제 는 이미 돌 이 킬 수 없 을 때 까지 기 다 려 야 주 의 를 받 아야 하 는가?13.INSERT 를 사용 하여 대량의 데 이 터 를 가 져 오지 마 십시오.그것 이 필요 하지 않 으 면 이렇게 하지 마 십시오.UTS 나 BCP 를 사용 하면 단번에 유연성 과 속 도 를 동시에 얻 을 수 있다.14.시간 초과 문제 에 주의 하여 데이터 베 이 스 를 조회 할 때 일반 데이터 뱅 크 의 부족 은 모두 비교적 적다.예 를 들 어 15 초 또는 30 초 이다.일부 조회 운행 시간 은 이보다 길다.특히 데이터베이스 의 데이터 양 이 끊임없이 커 질 때.15.같은 기록 을 동시에 수정 하 는 문 제 를 소홀히 하지 마 세 요.가끔 은 두 사용자 가 같은 기록 을 동시에 수정 합 니 다.그러면 다음 수정 자 는 앞의 수정 자의 조작 을 수정 하면 일부 업 데 이 트 는 잃 어 버 릴 수 있 습 니 다.이러한 상황 을 처리 하 는 것 은 어렵 지 않 습 니 다.timestamp 필드 를 만 들 고 쓰기 전에 검사 합 니 다.허용 되면 수정 을 합 쳐 충돌 이 있 으 면 사용자 에 게 알려 줍 니 다.16.세부 표 에 기록 을 삽입 할 때 메 인 표 에서 SELECT MAX(ID)를 실행 하지 마 십시오.이것 은 일반적인 오류 입 니 다.두 사용자 가 같은 시간 에 데 이 터 를 삽입 할 때 오류 가 발생 할 수 있 습 니 다.SCOPE 를 사용 할 수 있 습 니 다.IDENTITY，IDENT_CURRENT 와 IDENTITY.가능 하 다 면 IDENTITY 를 사용 하지 마 세 요.트리거 가 있 는 상황 에서 문제 가 생 길 수 있 기 때 문 입 니 다.17.열 을 NULLable 로 설정 하 는 것 을 피해 야 합 니 다.가능 하 다 면 열 을 NULLable 로 설정 하 는 것 을 피해 야 합 니 다.시스템 은 NULLable 열의 모든 줄 에 추가 바이트 하 나 를 할당 하고 조회 할 때 더 많은 시스템 비용 을 가 져 옵 니 다.또한,열 을 NULLable 로 설정 하여 인 코딩 을 복잡 하 게 만 듭 니 다.이 열 에 접근 할 때마다 먼저 검 사 를 해 야 하기 때 문 입 니 다.비록 어떤 사람들 은 그렇게 생각 하지만,나 는 NULLS 가 번 거 로 운 근원 이 라 고 말 하 는 것 은 아니다.업무 규칙 에'빈 데이터'가 허용 된다 면 NULLable 로 설정 하 는 것 이 좋 을 때 가 있다 고 생각 합 니 다.하지만 아래 와 같은 상황 에서 NULLable 을 사용 하면 고생 을 사서 하 는 것 입 니 다.Customer Name 1 Customer Address 1 Customer Email 1 Customer Name 2 Customer Address 2 Customer Email 3 Customer Name 1 Customer Address 2 Customer Email 3 이런 상황 이 발생 하면 시 계 를 규범화 해 야 합 니 다.18.TEXT 데이터 형식 을 사용 하지 마 십시오.TEXT 로 큰 데 이 터 를 처리 하지 않 으 면 사용 하지 마 십시오.조회 가 쉽 지 않 고 속도 가 느 려 서 잘 쓰 지 못 하면 많은 공간 을 낭비 할 수 있 기 때문이다.일반적으로,VARCHAR 는 당신 의 데 이 터 를 더욱 잘 처리 할 수 있 습 니 다.19.당신 이 반드시 이렇게 해 야 하지 않 는 한 임시 표를 사용 하지 마 세 요.일반적으로 하위 조 회 를 사용 하면 임시 표를 대체 할 수 있다.임시 표를 사용 하면 시스템 비용 을 가 져 올 수 있 습 니 다.만약 에 COM+로 프로 그래 밍 을 한다 면 큰 번 거 로 움 을 가 져 올 수 있 습 니 다.COM+는 데이터 베 이 스 를 사용 하여 풀 을 연결 하 는데 임시 표 는 처음부터 끝까지 존재 하기 때 문 입 니 다.SQL Server 는 Table 데이터 형식 과 같은 대체 방안 을 제공 합 니 다.20.분석 조회 SQL Server 조회 분석 기 는 좋 은 파트너 입 니 다.이 를 통 해 조회 와 색인 이 성능 에 어떻게 영향 을 미 치 는 지 알 수 있 습 니 다.21.완전 성 을 참조 하여 주 건,유일 성 제약 과 외 키 를 정의 하면 대량의 시간 을 절약 할 수 있다.