2.1 조작하려는 엘리먼트 선택하기

  • jQuery는 우리에게 익숙한 CSS문법을 사용한다.
  • jQuery 정의 메서드 역시 CSS문법을 확장해서 사용한다.

2.1.1 기본 CSS 셀렉터 사용하기

  • a - 모든링크(<a>) 엘리먼트와 일치하는 셀렉터
  • #specialID - specialID를 아이디로 가지는 엘리면트와 일치 셀렉터
  • .specialClass - specialClass를 클래스로 가지는 셀렉터
  • a#specialID.specialClass - 아이디가 specialID이고 specialClass를 클래스로 가지는 링크와 일치하는 셀렉터
  • p a.specialClass - <p> 에리먼트 내에 선언되고 specialClass를 클래스로 가지는 모든링크와 일치하는 셀렉터
  • 몇몇 예외사항을 제외하고 CSS3를 완벽하게 준수한다.

2.1.2 자식셀렉터, 컨테이너 셀렉터, 어트리뷰트 셀렉터

  • p > a - 자식셀렉터
  • a[href^=http://] - 어트리뷰트 셀렉터 (^)는 값의 시작부분이 일치함을 의미함
  • form[method] - 특정 어트리뷰트를 가진 셀렉터 선택
  • input[type=text] - 일치하는 어트리뷰트를 가짐
  • a[href$=.pdf] - 끝값이 일치하는 어트리뷰트 셀렉터
  • a[href*=jquery.com] - 문자열을 포함하는 어트리뷰트 셀렉터
  • li:has(a) - <a>엘리먼트를 포함하는 모든 <li>엘리먼트와 일치한다.

2.1.3 위치로 선택하기

  • :first - 첫번째 일치 엘리먼트
  • :last - 마지막 일치 엘리먼트
  • :first-child - 첫번째 자식 엘리먼트
  • :last-child - 마지막 자식 엘리먼트
  • :only-child - 형제가 없는 엘리먼트
  • :nth-child(n) - n번째 자식 엘리먼트
  • :nth-child(even|odd) - 짝수 또는 홀수 자식 엘리먼트
  • :nth-child(Xn+Y) - 공식에 따른 엘리먼트 ex)li:nth-child(3n)
  • :even / :odd -  짝수 홀수 엘리먼트
  • :eq(n) - n번째 일치 엘리먼트 (인덱스 0부터 시작)
  • :gt(n) - n번째 엘리먼트(포함되지 않음) 이후의 엘리먼트와 일치
  • :lt(n) - n번째 엘리먼트(포함되지 않음) 이전의 엘리먼트와 일치
  • 자식셀렉터는 1부터 시작

2.1.4 jQuery 정의 셀렉터 사용하기

  • :animated - 에니메이션 적용된
  • :button - 모든 버튼
  • :checkbox - 체크박스엘리먼트
  • :checked - 선택된 체크박스
  • :contains(foo) - 문자열 foo를 포함하는 엘리먼트
  • :disabled - 비활성화 상태인 모든 폼엘리먼트
  • :enabled - 활성화 상태인 모든 폼엘리먼트
  • :file - 파일엘리먼트
  • :header - 헤더 엘리먼트
  • :hidden - 감춰진 엘리먼트
  • :image - 폼 이미지 선택
  • :input - 폼 엘리먼트만 선택(input, select, textarea, button)
  • :not(filter) - 필터의 값을 반대로 변경
  • :parent - 빈 엘리먼트 제외 텍스트포함 자식엘리먼트를 가지는 엘리먼트
  • :password - 패스워드 엘리먼트
  • :radio - 라디오 버튼
  • :reset - 리셋 버튼
  • :selected - 선택된 엘리먼트
  • :submit - 전송 버튼
  • :text - 텍스트 엘리먼트
  • :visible - 보이는 엘리먼트

2.2 새로운 HTML 생성하기

  • $("<div>안녕</div>")
  • $("<div>") 는 $("<div></div>")와 같다
  • .appendTo() 메서드도 있다.

2.3 확장된 엘리먼트 집합 관리하기

2.3.1 확장된 집합의 크기 결정하기

  • $('#someDiv').html('페이지에는 총 '+$('a').size() + '개의 링크가 있다');
  • 확장집합의 엘리먼트 개수

2.3.2 확장 집합에서 엘리먼트 획득하기

  • $('img[alt]')[0] - 배열을 이용
  • $('img[alt]').get(0) - 위와 동일. 0 생략시 배열 반환
  • $('img').index($('img#findMe')[0]) - 이미지들중 id가 findMe인 이미지가 몇번째인지 인덱스를 반환

2.3.3 확장 엘리먼트 집합 재편성하기

  • $('img[alt]').add('img[title]') - 엘리먼트를 확장집합에 추가한다.
  • $('p').add('<div>안녕!</div>') - 새 html 생성해서 추가
  • $('img'[title]').not('[title*=puppy]') - title 어트리뷰트를 지닌 모든 img엘리먼트 선택할때 puppy를 포함은 제외(true를 제외)
  • $('img').addClass('seeThrough').filter('[title*=dog]') - not 메서드와는 반대의 결과 (부합하지 않는 false를 제외)
  • $('*').slice(0,4); - 전체 엘리먼트에서 처음부터 4개의 엘리먼트를 포함한 집합생성
  • $('*').slice(4); - 4개 이후(5번째 부터)에서 끝까지의 확장 집합생성

2.3.4 관계를 이용해 확장집합 얻기

  • children() - 고유한 자식으로 구성된 확장집합 반환
  • contents() - 엘리먼트 콘텐츠로 구성된 확장집합 반환. 주로 iframe 엘리먼트 콘텐츠를 얻고자 함(텍스트 노드포함)
  • next() - 확장집합내의 각 확장 엘리먼트 바로 다음에 나오는 형제
  • nextAll() - 확장집합내의 각 확장 엘리먼트 다음에 나오는 모든 형제
  • parent() - 모든 확장 엘리먼트의 바로 위 부모로 구성된 엘리먼트
  • parents() - 모든 확장 엘리먼트의 조상으로 구성된 확장집합 반환(root 미포함)
  • prev() - 각 확장 엘리먼트 바로 이전 형제로 구성된 확장집합
  • prevAll() - 각 확장엘리먼트 이전에 나오는 모든 형제로 구성된 확장집합
  • sibilings() - 확장 엘리먼트의 모든 형제를 포함하는 확장집합을 반환

2.3.5 확장집합을 이용하는 기타 방법들

  • wrappedSet.find('p cite') - wrappedSet 집합에서 <p>에 포함된 <cite>엘리먼트 구성 확장집합
  • var hasImage=$('*').is('img'); - img 엘리먼트가 있는지 true false 반환

2.3.6 jQuery 체인 관리하기

  • $('img').clone().appendTo('#somewhere').end() - appendTo() 이전 확장 집합으로 돌아간다.
  • andSelf() - 커멘드체인에서 이전 확장집합 두개를 하나로 합친다.

 


1.1 jQuery인가?

1.2 튀지 않는 자바스크립트

  •  쉽게 동작을 분리해 낼 수 있도록 라이브러리를 설계 
  • 튀지 않는(unobstrusive) 자바스크립트는 HTML 페이지의 <body>테그에 포함된 자바스크립트 표현식이나 구문을 잘못된 것으로 본다. 
  • 이는 명확하게 책임을 분리해주지만 많은 코드를 짜야하는 비용이 따른다. 
  • jQuery를 이용하면 튀지 않는 자바스크립트 적용한 페이지를 작성하는 일이 한층 쉽고 즐거운 작업이 될 수 있다. 
  •  적은 코드로 코딩이 가능하다.

1.3 jQuery 기초

1.3.1 jQuery() 함수

  • p a  -  <p> 엘리먼트에 포함된 모든링크(<a> 엘리면트)의 그룹을 참조한다.
  • CSS에서 사용되는 일반적인 셀렉터 이외에도 대부분의 브라우저에서 아직 완벽히 구현하지 못한 강력한 셀렉터도 지원한다. CSS3도 지원
  • $()는 jQuery() 함수의 별칭
  • $("div.notLongForThisWorld").fadeOut() -> 사라지게 한후 동일한 엘리먼트 그룹 반환
  • $("div.notLongForThisWorld").fadeOut().addClass("removed"); -> 무한대로 연결가능
  • $("#someElement").html("엘리먼트에 텍스트를 추가한다."); -> 작업이 복잡할 수록 jQuery체인을 사용하면 우리가 원하는 결과를 얻는데 필요한 코드의 양이 확연히 준다.
  • $("#someElement")[0].innerHTML = "엘리먼트에 텍스트를 추가한다."); -> 배열처럼 사용 할 수 있다.

1.3.2 유틸리티 함수

1.3.3 문서 준비 핸들러

  • window.onload는 DOM트리 생성 후 모든 이미지와 다른 외부리소스까지 로드 후에야 실행되므로 이미지나 다른 리소스를 로드하는데 시간이 오래걸리게되면 방문자가 그만큼 기다려야 하므로 전체 페이지에 사용 하기는 어렵다.
  • jQuery는 크로스 브라우져 환경으로 이를 지원
  • $(document).ready(function){     }); - ready()메서드를 통해 ready상태가 되었을때 호출
  • $(function({       }); - DOM이모두 로드될 때까지 코드실행을 기다린다. 문서내에 여러번 사용 가능
  • window.onload는 오직 한 함수만 허용한다.

1.3.4 DOM 엘리먼트 생성하기

  • $("<p>안녕!</p>").insertAfter("#followMe");

1.3.5 jQuery 확장하기

  • jQuery 라이브러리에는 필요한 기능만을 포함시켰다.
  • 필요한 기능을 확장해서 사용 가능하다.
  • $("form#myForm input.special").disable();
  • $.fn.disable = function() {                                                             // disable 함수를 추가하겠다.

retun this.each(function() {

    if (typeof this.disabled != "undefined") this.disabled = true; // this는 위와 다른 this

});

}

1.3.6 다른 라이브러리들과 함께 jQuery 사용하기 

 

 1.     데이터베이스 파일과 로그 파일은 별도의 드라이브로 분리한다.

è  IO를 분산하여 병목현상을 감소시킨다.

 

2.     Ad Hoc 쿼리 (동적 쿼리) : 정적 쿼리로 대체

è  코드의 실행 시점에 SQL 문이 동적으로 구성되고 실행되는 쿼리

è  문제점 : 실행 시마다 컴파일을 반복하게 됨으로 Cache 재사용을 저해함으로써 CPU, Memory 등 여러가지 문제 발생

è  SP의 이점

n  실행 계획 Caching 을 통한 성능 이득

n  Network Traffic 최소화

n  출력 Parameter, Return 값 사용

n  Ownership Chain 을 통한 권한 처리, SQL Injection 차단 등의 보안 기능

n  업무 논리의 캡슐화, 모듈화

n  SQLXML 3.0 이후 릴리스에서 XML WebService 노출 기능

è  SP 안에 동적 쿼리 형태로 작성 하지 않는다.

 

3.     인덱스 생성 Guide

è  where절에서 자주 사용되는 컬럼

è  between A and B (클러스터인덱스가 유리) : 범위 쿼리 문에서는 클러스터 인덱스가

유리 하다.

è  order by가 항상 사용되는 컬럼

è  join으로 자주 사용되는 컬럼

è  100만건 중에 10개 조회 OR 1000개 조회와 같이 찾는 것이 적은 컬럼 : 중복 데이터가 많은 (조회되는 것이 많은) 컬럼은 인덱스에 좋은 영향은 아님.

è  인덱스로 인해 얻는 손해 : H/W 용량 증가, DML(Data Manipulation Language : INSERT, UPDATE, DELETE) Performance 저하 (특히 INSERT)

 

4.     쿼리 Guide

è  WHERE 절에 가공 컬럼 비교 금지 : WHERE REPLACE(USER_ID, ‘ ’, ‘’) = ‘11111’ 와 같이 컬럼을 가공하게 되면 인덱스를 사용하지 못한다. - INSERT USER_ID에는 ‘ ‘ INSERT 되지 않도록 하고, 조건절은 WHERE USER_ID = ‘11111’

è  WHERE 절에서 LIKE 사용 시 ‘%’ 로 시작하는 비교 금지 : NAME LIKE '%홍길동%' 와 같이 LIKE ‘%’로 시작하는 비교는 TABLE SCAN 한다. - 해당 TABLE의 데이터 건수가 소량이고 일정량을 유지한다면 시스템 Capacity내에서 사용 가능하나 일정량의 데이터가 주기적으로 증가하고 해당 쿼리가 빈번히 사용되는 쿼리라면 '%홍길동%' 기능을 '홍길동%' 으로 바꾸던가 시스템 Capacity 를 고려하여 데이터를 삭제하여야 한다.

è  SELECT 절에 사용자 정의 함수 사용 : 무조건 사용하지 않는다. – join 으로 변경

è  SELECT 절에 하위쿼리 사용 : 무조건 사용하지 않는다. – join 으로 변경

è  잠금 문제 : SELECT 쿼리에 with (nolock) 혹은 with (readuncommitted) Hint 사용 – Commit 되지 않은 데이터를 읽어 나중에 없어지거나 변경될 수 있으나 회계와 같은 중요한 데이터가 아니라면 반드시 사용한다.

SQL Server 의 기본 격리수준은 read committed 이다. 그래서 읽을 때는 공유 잠금이 유지되어, 테이블을 SELECT 할 경우 INSERT, UPDATE등은 BLOCK 된다. 이럴 경우 SELECT DB의 성능이 떨어지게 된다.

각 구문에 적용을 해야 하는 불편함을 해결하는 방법은 SP 상단에 아래 문구를 삽입한다.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

è  Ad Hoc 쿼리 : 정적 쿼리로 변경 (SP)

è  SELECT * 을 사용하는 것은 피한다. : 사용하지 않는 데이터를 호출하는 것만으로도 이미 많은 부하가 생긴다. 특히 text 타입의 데이터를 호출하는 경우는 그 정도가 심해진다. - 필요한 컬럼만 SELECT 한다.

è  COUNT(*)을 사용하라. : COUNT(컬럼)으로 호출하는 경우가 있다. 이 경우 해당 컬럼의 NULL값을 제외한 COUNT를 가져오게 된다. NULL값을 일일이 체크하면 호출 속도가 저하되게 된다. NULL을 체크해야 하는 경우가 아닌 대부분의 경우 COUNT(*)을 사용한다. COUNT(*) NULL값의 경우도 모두 count에 추가하지만 그로 인해 성능의 저하가 많이 줄어든다.

è  1 row 만 필요하다면 TOP 1을 사용한다.

è  커서 및 임시테이블의 내용을 최대한 자제하라. : 커서보다는 임시 테이블이, 임시테이블 보다는 테이블 변수를 사용하는 것이 성능에 좋다.

è  뷰의 사용을 줄여라. : 직접 쿼리가 단계를 줄이므로 가급적 뷰를 사용하지 않는다.

è  JOIN을 사용하는 경우 INNER JOIN을 되도록 사용하라.
.
동일한 효과를 가지는 쿼리를 작성할 경우 INNER JOIN이 아닌 LEFT OUTER JOIN을 쓰는 경우가 있다. (습관적으로?) 확연히 속도가 차이가 나므로 INNER JOIN을 사용하는 것이 좋다.

è  반드시 인덱스를 사용하도록 한다. : 실행 계획을 통해 인덱스의 사용 유무와 올바른 인덱스를 사용하는지 확인한다.

è  SP에서 데이터 형식 우선 순위에 따른 형식 변환이 일어나지 않도록 컬럼 타입과 동일한 타입의 파라미터를 사용 한다.

@searchColumnA NVARCHAR(12)

SELECT * FROM A WITH (READUNCOMMITTED)

WHERE columnA = @searchColumnA

-       columnA 의 타입이 VARCHAR 이면 NVARCHAR 의 우선순위가 높아 아래와 같이 CONVERT 가 발생하여 Performance 를 저하 시킨다.

SELECT * FROM A WITH (READUNCOMMITTED) WHERE CONVERT(NVARCHAR(12), columnA)

è  set nocount on 을 먼저 실행하라 : 불필요한 메시지를 표시하지 않는다.

 

5.     예상 실행 계획을 자주 확인하라.

실행계획의 내용은 꼼꼼히 따져봐야 한다. 튜닝의 시작은 성능 분석이다.

(그래픽 실행 계획 아이콘)

 

6.     Index를 타는지 항상 체크하라.

Index를 활용하지 않은 검색은 데이터가 많으면 많을수록 성능은 급격히 떨어진다.

7.     Clustered Index Seek를 항상 체크하라.

Clustered Index Scan을 타는 것 만으로도 속도는 향상이 되지만 완전하진 않다.
Clustered Index column
의 일정 구간을 타는 Seek여야 한다.

일반 Non Clustered Index의 경우는 Clustered를 찾기 위해 해당 column Clustered Index 정보를 호출해야 하는 부담이 생긴다.

Clustered Index Non Clustered Index Index 구조의 차이 : (클러스터형 인덱스 구조) , (비클러스터형 인덱스 구조)

 

8.     기타…..

è  Index 설정시 DESC 정렬을 해야 빠른가 ?

그렇지 않다.
오름차순이건 내림차순이건 Index가 걸려있으면 조건에 따라 Clustered Index를 찾아 가게 된다.

è  Clustered Index Seek를 타면 무조건 빠른가 ?

그렇지 않다.

è  Non Clustered Index column은 무조건 마지막엔 Clustered Index Column을 조회하는가 ?

그렇지 않다.

è  Clustered Index Table 당 하나만 존재 한다.

è  Table로부터 하나 혹은 소수의 Row들을 리턴하는 SQL Query인 경우에 Nonclustered Index가 적합하고, 많은 수의 Row들을 리턴하는 것이 필요한 Query들의 경우에는 Clustered Index가 더 적합하다.


'DataBase' 카테고리의 다른 글

샘플 재귀 쿼리문  (0) 2010.06.28
Windows Server 2008 R2에서 SQL Server 2008 원격 접속 허용하기  (1) 2010.06.25
SQL index 초기화  (0) 2009.11.25
새로운 SQL 잘라내기 공격 및 대처 방법  (0) 2009.07.06
MS-SQL 트리거  (0) 2009.07.03

+ Recent posts