SQL 2008 데이터 형식 - 사용할 항목은 무엇입니까?

Question

SQL Express 2008 에디션을 사용하고 있습니다. 종이에 내 데이터베이스 테이블/관계를 계획하고 시작할 준비가되었습니다. 내 pkID_Officer에 대한 데이터 형식을 클릭하면

불행하게도, 나는 내가 기대했던 것보다 더 많은 것을 제공하고, 따라서 의심 설정했습니다.

이

사람이 날짜 유형의 설명과 예제가있는 곳으로 날 포인트 어떤 필드가 어떤 데이터 유형에서 더 잘 작동하는지 알려줍니다.

예 :

• 여전히 ID (기본 키) 확실한 선택을 위해 INT거나 고유 식별자가 크라운의 필요합니까?

• 숫자가 '.'로 분리 된 전화 번호. (01.02.03.04.05)

• 이메일 하이퍼 링크

• NCHAR 및 vChar 될 것

• 항목을?

언제나 감사드립니다.

감사합니다.

마이크.

Answer 1

MSDN 사이트에는 SQL 2008 데이터 형식에 대한 개요가 있습니다.

http://msdn.microsoft.com/en-us/library/ms187752.aspx

은 ID 필드의 경우는 별도의 시스템 또는 테이블에서 고유해야 또는 데이터베이스의 외부 ID를 생성 할 수 있기를 원하는 경우가 GUID를 사용합니다. 그렇지 않으면 int/identity 값이 잘 작동합니다.

저는 계산을하지 않을 것이므로 문자 데이터를 저장합니다. 나는 이메일이 같은 방식으로 저장 될 것이라고 생각한다.

하이퍼 링크는 기본적으로 하이퍼 링크를 varchar로 저장하고 클라이언트에 링크를 렌더링하거나 데이터베이스 자체에 마크 업을 저장할 수 있습니다. 상황에 따라 달라집니다.

현재 또는 향후 더블 바이트 언어를 지원해야한다고 생각하는 경우 nvarchar를 사용하십시오.

Answer 2

기본 키의 경우 항상 자동 증가 int를 사용하는 것이 좋습니다 (시작점). 모든 것을 더 유용하게 만들고 실제 데이터와 "자연스런"관계가 없습니다. 물론

Answer 3

고유 식별자가 GUID가 있습니다 ... 이것에 예외가있을 수 있습니다 http://de.wikipedia.org/wiki/Globally_Unique_Identifier

GUID를
- 전 세계적으로 고유 한 - DOTNET 예를 들어,에가 자신의 개체 (System.Guid) - 길이가 16 자리입니다.

그런 것이 있으면 사용하십시오. int-ids를 사용해도 괜찮 으면 괜찮습니다.

전화 번호/이메일/하이플링은 일반적인 문자열입니다.

Answer 4

NCHAR/NVARCHR은 CHAR/VARCHAR 데이터 유형의 유니 코드 대위법입니다. 나는 거의 항상 내 앱에서 사용합니다. 사용하지 않을 강력한 이유가 없다면 말입니다.

Answer 5

• 여전히 ID (기본 키)에 대한 확실한 선택 INT거나 고유 식별자는 크라운의 필요합니까?

개인적으로 GUID보다 특히 클러스터 된 인덱스의 경우 INT ID를 선호합니다. GUID는 본질적으로 무작위이므로 SQL Server에서 클러스터 된 인덱스로 사용될 때 인덱스 조각화가 많아 성능이 떨어집니다. INT는 이러한 문제가 없으며 16 바이트 대 4 바이트 밖에되지 않으므로 많은 행이 있고 비 클러스터형 인덱스가 많으면 (클러스터되지 않은 키가 각각의 모든 항목에 추가됩니다. GUID를 사용하면 공간 요구 사항이 불필요하게 늘어납니다 (디스크 및 컴퓨터의 RAM에도)

• 숫자가 '.'로 구분되는 전화 번호. (01.02.03.04.05)
• 이메일 나는이의 모든 문자열 필드를 사용하십시오 하이퍼 링크

될 것

항목.

"외국어"언어 지원이 필요하지 않는 한 VARCHAR는 좋습니다. 영어와 서유럽 어는 괜찮지 만 동유럽과 아시아 언어 (키릴 어, 중국어 등)에서는 실패합니다.

NVARCHAR는 모든 추가 성가신 언어를 가격으로 처리합니다. 각 문자는 2 바이트로 저장됩니다. 100 자의 문자열은 항상 200 바이트의 저장소를 사용합니다.

희망이 조금 도움이 되었어요!

마크