101102 endofdb select.1_rdbms
TRANSCRIPT
SELECT(1) &R-DBMS
SELECT [내용] FROM [테이블]
WHERE [조건] ORDER BY [순서]
SELECT 쿼리문의 기본적인 형태. 보다 상세한 내용은 5장에서 다룬다.
SELECT [내용] FROM [테이블] WHERE [조건]
• 테이블에서 얻어오고 싶은 데이터가 있는 필드의 리스트를 기술.
• 테이블 전체를 얻어올 때는 select * from …
• 성능상의 이슈가 있고, 컴파일 최적화의 이슈도 있다.
• SELECT COUNT(*) FROM dbo.Users(NOLOCK) – 가입자수
• 불필요하게 모든 컬럼을 다 가져오는 비효율적인 쿼리
• 최신 버전의 MSSQL은 모든 컬럼을 다 가져오지 않는다.
• 추후 이 부분에 대한 추가적인 학습 필요.
SELECT [내용] FROM [테이블] WHERE [조건]
테이블의 필드명을 보고 싶을 땐 sp_help / sp_columns
SELECT [내용] FROM [테이블] WHERE [조건]
MSSQL 2008에서는 자동완성 기능이 아주 훌륭해졌다.
SELECT [내용] FROM [테이블] WHERE [조건]
주요 시스템 변수 (시스템 함수)
@@ERROR
@@IDENTITY
@@ROWCOUNT
@@TRANCOUNT
SELECT [내용] FROM [테이블] WHERE [조건]
마지막 sql문의 수행시 발생한 에러
해당 세션에서 마지막으로 입력된 ID값.
수행된 sql문에 의해 영향받은 행의 수.
트랜잭션의 중첩 정도.
SELECT [내용] FROM [테이블] WHERE [조건]
Year >= 2000 AND Year <= 2010
-> Year BETWEEN 2000 AND 2010
title_id = ‘BU1032’ OR ‘BU1111’ OR ‘MC3021’
-> title_id IN ( ‘BU1032’, ‘BU1111’, ‘MC3021’ )
조건 : c/c++ 스타일 기술 외 다른 문법 지원.
SELECT [내용] FROM [테이블] WHERE [조건]
_ : any one character. 어떤 것이든 한 문자를 허용.
% : any zero or more. 아무것도 없는 경우를 포함, 뭐든지 허용.
[(text)] : [] 안에 적힌 글자만 허용.
[^(text)] : ^뒤에 적힌 글자를 제외한 글자들을 허용.
패턴 : 문자열 검색시 이용.
SELECT [내용] FROM [테이블] WHERE [조건]
WHERE price * 1.1 < 20.0
-> WHERE price < 20.0 / 1.1
WHERE DATEPART(yy, pubdate) = 1991
-> WHERE pubdate BETWEEN ‘1991.1.1’
AND ‘1991.12.31 23:59:59.999’
튜닝 팁 : 연산자 앞에는 column만 오도록 한다.
자료형 (Data Type)에 대한 자세한 언급은 생략.
성능 향상을 위해 가능한 작은 자료형을 써야하는 점과,
var..로 시작하는 가변길이 타입에 대한 성능 관련 이슈가 있는 점을
알아두기만 하고 넘어가자.
사용자 정의 자료형 (User Defined Data Type)
여러 개발자가 공동 개발하는 경우
혼동을 줄일 수 있다.
exec sp_addtype <새로운 타입 이름>, ‘<sql 데이터 타입>’
형 변환 : CONVERT() / CAST()
CAST ( expression AS datatype )
CONVERT( datatype, expression [, style] )
두 함수 모두 형 변환용 함수.
CAST는 ansi 표준 함수 : 다른 DBMS에서도 지원하고
CONVERT는 T-SQL : 날짜 변환에 관한 추가기능 지원.
DECLARE @data INTSET @data = NULL -- 변수를 NULL로 만든다.
IF @data = NULL -- 문법 오류 없이 오동작(?)한다.…
IF @data IS NULL -- 올바른 NULL 체크 방식.…
실수하기 쉬운 NULL 체크
SET ANSI_NULLS OFF 을 해주면 = NULL도 동작한다.
SELECT(1) &R-DBMS
관계형 데이터베이스 : Relational-Data Base
관계 : Entity (테이블)간의 논리적 관계를 지정해준다.
관계로 표현된 논리에 어긋나는 조작은 처리 불가능. 데이터 이상의 의미.
-> 예 : 계정 - 캐릭터 - 스킬
ER-diagram : Entity-Relation diagram. 엔티티간의 관계를 기술.
계정 캐릭터 스킬1:n 관계 1:n 관계
1:1 관계 - 테이블을 합치는 것을 고려해보자.
1:n 관계 - 가장 흔한 경우. 자식 테이블에 부모를 참조하는 컬럼 선언.
m:n 관계 - R-DB에서 인정되지 않는 관계. 제 4 정규화 필요.
( 예 : 친구리스트. 여러 캐릭터와 여러 캐릭터가 관계 지어진다. )
Entity A Entity B
Entity A Entity BA와 B의 관계
두 엔티티가 m:n 관계이고, 이를 모델링 해야 한다면
각각의 엔티티를 테이블로 만들고,
A와 B의 관계를 기술하는 별도의 테이블을 만들어 표현한다.
m:n
1:n n:1
m:n 관계 모델링의 예시
-> 캐릭터 기반의 친구리스트
Entity A : 캐릭터
Entity B : 캐릭터
A와 B의 관계를 FriendList로 표현.
관계의 부모가 지워질(변경될) 때, 연결된 자식 데이터도 함께 적용.
-> 계정을 지우면, 해당 계정의 캐릭터 삭제 및 캐릭터의 스킬도 삭제되도록 설정 가능.
• 정규화 (Normalization ) :
• 중복된 데이터를 제거해서 성능을 향상 시키는 것.
• 중복 데이터가 포함된 테이블을 분리하는 작업.
• 1정규화(1NF)부터 4정규화(4NF)로 구분한다.
• 나뉘어진 테이블을 필요에 따라 JOIN해서 사용한다.
• 비정규화 (Denormalization) :
• 나누어 놓은 테이블을 성능 향상의 목적으로 다시 합치는 것.
• 데이터가 중복되지만, 지나치게 빈번한 JOIN을 피할 수 있다.
- 캐릭터와 캐릭터의 보유 스킬은 1:n 관계를 가진다.
- 왼쪽은 한 테이블에 모두 표시. 오른쪽은 별도 테이블로 정규화.
캐릭터 스킬을 개별구매하는 부분유료화 게임이라고 치자.
해당 스킬을 어느 유저(계정)가 구매했는지에 대한 정보가 빈번히 필요하다.
위의 구조라면 테이블 세 개를 JOIN해야 관련 정보를 얻을 수 있다.
이 런 경우 스킬 테이블에 소유자 유저의 UID값을 중복해 넣는다.
데이터는 중복되지만, JOIN을 줄이거나 없앨 수 있다.
Fin.Q & A