내보내기(0) 인쇄
모두 확장

데이터베이스 디자인 및 성능(SQL Server Compact)

SQL Server 데이터베이스 및 게시를 적절히 디자인하여 SQL Server Compact 4.0 응용 프로그램 성능을 크게 향상시킬 수 있습니다. 다음 섹션에서는 성능 향상을 위해 사용할 수 있는 기술에 대해 대략적으로 설명합니다.

데이터베이스를 정규화하면 데이터의 기능적 종속 관계가 사라지므로 데이터베이스를 쉽고 효율적으로 업데이트할 수 있습니다. 그러나 데이터베이스를 쿼리하려면 정보를 결합하기 위해 많은 테이블 조인이 필요할 수 있습니다. 조인 테이블 수가 증가할수록 쿼리 실행 시간이 크게 늘어납니다. 따라서 데이터베이스를 정규화하는 것이 항상 최선의 방법이 아닐 수 있습니다. 데이터베이스를 적절히 비정규화하면 업데이트 프로세스가 크게 복잡해지지 않으면서도 조인해야 하는 테이블 수를 줄일 수 있습니다. 이 방법이 유용한 경우가 종종 있습니다.

참고 참고

일반적으로 쿼리 수가 많아 다섯 개 또는 여섯 개 이상의 테이블 조인이 필요할 경우 비정규화를 고려해야 합니다.

다른 종류의 데이터베이스 비정규화도 있습니다. 예를 들어 데이터베이스에 Orders와 Order Details의 두 테이블이 있는 경우를 가정해 볼 수 있습니다. Orders 테이블에는 고객 주문 정보가 들어 있습니다. 각 주문에 포함된 개별 제품에 대한 정보는 Order Details 테이블에 들어 있습니다. 각 주문의 총 달러 금액을 쿼리하려고 합니다. 먼저 각 제품의 달러 금액(개수 * 단가 - 적용 가능한 할인액)을 결정해야 합니다. 그런 후 이 금액을 주문별로 그룹화해야 합니다. 이 경우 쿼리는 다음과 같습니다.

SELECT "Order ID", SUM("Unit Price" * Quantity * (1.0 - Discount))

AS Total FROM "Order Details"

GROUP BY "Order ID"

Order ID Total

----------------------------------------

10000 108

10001 1363.15000915527

10002 731.800003051758

10003 498.180023193359

10004 3194.19999694824

10005 173.400009155273

10006 87.2000007629395

10007 1405

10008 1171

10009 1530

10010 470

... ...

(1078 rows affected)

이 쿼리에 따른 계산은 간단하지 않습니다. 주문 집합이 많은 경우 쿼리 실행에 많은 시간이 소요될 수 있습니다. 주문 실행 시 주문의 달러 금액을 계산한 다음 이 금액을 Orders 테이블의 열에 저장하는 방법도 있습니다. 이 방법을 사용하는 경우 필요한 정보를 반환하려면 사전 계산한 열만 쿼리해야 합니다.

SELECT "Order ID", "Order Total" AS Total FROM Orders

사전 계산된 열을 만들면 쿼리 시간을 크게 단축할 수 있지만 테이블에 추가된 열을 유지 관리해야 합니다.

테이블을 디자인할 때 가변 길이 열과 고정 길이 열을 사용하는 데 따르는 장단점을 알면 도움이 됩니다. 가변 길이 열의 경우 실제 값을 저장하는 데 필요한 공간만 사용하므로 데이터베이스 크기가 줄어듭니다. 고정 길이 열은 실제 값이 비어 있는 경우에도 스키마에 정의된 최대 공간을 사용합니다. 가변 길이 열의 단점은 일부 연산이 고정 길이 열에서 수행하는 것만큼 효율적이지 못하다는 것입니다. 예를 들어 처음에는 작았던 가변 길이 열이 UPDATE로 인해 커진 경우 레코드를 다시 배치해야 할 수도 있습니다. 또한 업데이트를 자주 수행할 경우 시간이 경과함에 따라 데이터 페이지의 조각화가 심화됩니다. 따라서 데이터 길이에 큰 차이가 없고 업데이트를 자주 수행할 경우에는 고정 길이 열을 사용하는 것이 좋습니다.

한 페이지에 들어갈 수 있는 행의 수는 각 행이 얼마나 작은가에 따라 달라집니다. 행이 작을수록 한 페이지에 들어갈 수 있는 행 수가 늘어납니다. 따라서 작은 행을 포함하는 테이블에서 단일 디스크 연산을 수행할 경우 더 많은 행이 검색되어 연산의 효율성이 높아집니다. 또한 저장소 엔진 캐시에 들어가는 행 수가 늘어나 적중률이 향상될 수 있습니다. 행이 작으면 데이터 페이지의 공간 낭비도 줄일 수 있습니다. 이것은 행이 클 경우에는 흔히 나타나는 문제입니다.

다음과 같은 극단적인 예를 고려해 볼 수 있습니다. 레코드 크기가 데이터 페이지의 절반 크기보다 크면 각 데이터 페이지 공간의 절반이 낭비됩니다. 데이터베이스 디자이너들은 종종 테이블을 넓게 디자인하고 메인프레임 데이터베이스 스키마를 장치에 적용합니다. 이것은 효과적인 디자인이라고 볼 수 없습니다. 가장 중요한 테이블을 분리하는 것도 한 가지 방법입니다. 일부 열에는 매우 안정적인 값이 들어 있고 다른 열에는 자주 변경되는 값이 들어 있는 테이블을 가정해 봅니다. 이 경우 테이블을 자주 참조되는 열을 포함하는 테이블과 안정된 열을 포함하는 테이블의 두 개로 나눌 수 있습니다. 두 개의 테이블로 만들면 작은 길이의 행을 사용할 때의 이점을 모두 얻을 수 있습니다. 단, 정보를 결합하기 위해 조인이 필요하다는 것이 한 가지 단점입니다.

인덱스는 해당 인덱스가 만들어진 테이블의 정렬된 하위 집합입니다. 인덱스를 사용하면 빠른 범위 조회 및 정렬이 가능합니다. 인덱스 키가 작을수록 공간을 덜 차지하여 큰 키를 사용할 때보다 효과적입니다. 특히 기본 키는 다른 테이블에서 외래 키로 자주 참조되므로 작게 만들면 좋습니다. 원래부터 작은 길이의 기본 키가 없을 경우에는 정수로 구현된 ID 열을 대신 사용할 수 있습니다.

키 열이 하나이거나 소수인 인덱스를 좁은 인덱스라고 합니다. 키 열이 여러 개인 인덱스를 넓은 인덱스라고 합니다. 넓은 인덱스는 주로 키 길이가 넓습니다. 극단적인 예로 테이블 안에 모든 열을 포함된 인덱스를 들 수 있습니다. 이러한 인덱스를 만들면 원본 테이블을 효과적으로 중복할 수 있습니다. 그러나 이러한 인덱스는 데이터베이스 크기 및 쿼리 성능 면에서 비효율적입니다.

Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

참여하시겠습니까?
표시:
© 2014 Microsoft