시드라엘

1. 인덱스의 개념

- 책의 뒷부분에 있는 색인과 비슷한 개념

- 작은 데이터에는 없어도 큰 차이가 없지만, 대량의 데이터에는 인덱스가 있어야만 빠른 검색이 가능하다.

2. 인덱스의 장단점

1) 장점

- 검색 속도가 무척 빨라질 수 있다. (반드시 그런것은 아니지만)

- 그 결과 시스템의 부하가 줄어들어 시스템 전체 성능 향상에 도움이 된다.

2) 단점

- 인덱스가 데이터베이스 공간을 차지해 추가적인 공간이 필요해진다. (DB의 10퍼센트 내외의 공간이 추가로 필요)

- 인덱스를 생성하는데 시간이 많이 소요될 수 있다.

- 데이터 변경 작업이 자주 일어날 경우에 인덱스를 재작성해야 할 필요가 있기에 성능에 영향을 끼칠 수 있다.

3. 인덱스의 종류

1) 클러스터형 인덱스

- 영어사전과 비슷한 개념

- 클러스터형 인덱스는 테이블당 1개만 생성가능

- 클러스터형 인덱스는 행데이터를 인덱스로 지정한 열에 맞춰 자동정렬

- 인덱스 자체가 데이터

2) 비클러스터형 인덱스

- 일반 책의 찾아보기와 비슷한 개념

- 테이블당 여러개 생성 가능하다.

- 인덱스자체가 데이터가 아니라 인덱스가 가리키는 것이 데이터

4. 인덱스의 특징

- 제약조건없이 테이블 생성시에 인덱스를 만들 수 없다.

- 인덱스가 자동생성되기 위한 열의 제약조건은 Primary KEY와 Unique뿐

5. 인덱스의 내부동작

B-Tree (Balanced Tree, 균형트리)

- 범용적으로 사용되는 데이터구조

- 인덱스를 표현할 때 많이 사용된다.

- 데이터 검색시 뛰어난 성능을 보인다.

- 데이터 변경시 성능이 나빠진다.

- 구성 : 루트노드 + 중간노드 + 리프노드

6. 인덱스의 구조

1) 클러스터형 인덱스

데이터를 추가하면 데이터 분할이 필요하다. 리프페이지가 하나 늘어나고 루트페이지에 데이터페이지를 하나 더 등록시켜준다.

2) 비클러스터형 인덱스

정렬을 하지 않으므로 빈 공간이 존재하면 빈 공간에 바로 들어갈 수 있다.

비클러스터형 인덱스에 데이터추가에 있어서 클러스터형 인덱스보다 효율적이다.

7. 인덱스를 생성해야 하는 경우와 그렇지 않은 경우

- 인덱스는 열 단위로 생성된다.

- WHERE절에서 사용되는 컬럼을 인덱스로 만든다.

- WHERE절에서 사용되더라도 자주 사용해야 가치가 있다.

- 데이터의 중복도가 높은 열은 인덱스로 만들어도 효용이 없다. (예 : 성별, 타입이 별로 없는 경우, 적은경우)

- 외래키가 사용되는 열에는 인덱스를 되도록 생성해주는 것이 좋다.

- JOIN에 자주 사용되는 열에는 인덱스를 생성해주는 것이 좋다.

- INSERT / UPDATE / DELETE가 얼마나 자주 일어나는지를 고려한다.

- 클러스터형 인덱스는 하나만 생성할 수 있다. (없을 수도 있다.)

- 클러스터형 인덱스가 테이블에 아예 없는 것이 좋은 경우도 있다.

- 사용하지 않는 인덱스는 제거하자

1. DROP TABLE A; (DDL)

구조와 row를 모두 날린다.

2. DELETE FROM A; (DML)

row를 모두 날린다. 시퀀스 값을 사용하고 있다면 삭제된 이후의 번호부터 차례로 값이 증가한다. (초기화 X)

3. TRUNCATE TABLE A; (DDL)

row를 모두 날린다. 초기화 O

DML은 롤백이 가능하지만 DDL은 불가능하다.

DDL, DML, DCL

1. DDL(Data Definition Language)

데이터와 그 구조를 정의합니다.

1) CREATE : 데이터베이스 객체를 생성합니다.
2) DROP : 대이터베이스 객체를 삭제합니다.
3) ALTER : 기존에 존재하는 데이터베이스 객체를 다시 정의하는 역할을 합니다.
4) RENAME : 데이터베이스의 컬럼명을 변경합니다.
5) TRUNCATE : 테이블을 최초 생성된 초기상태로 만들며, ROLLBACK이 불가능합니다.

2. DML(Data Manipulation Language)

데이터의 검색, 수정, 삭제 등을 처리합니다.

1) INSERT : 데이터베이스 객체에 데이터를 입력합니다.
2) DELETE : 데이터베이스 객체에 데이터를 삭제합니다.
3) UPDATE : 기존에 존재하는 데이터베이스 객체안의 데이터 수정합니다.
4) SELECT : 데이터베이스 객체로부터 데이터를 검색합니다.
5) COMMIT : 변경사항을 저장합니다.
6) ROLLBACK : 변경사항을 취소합니다.

3. DCL(Data Control Language)

데이터베이스 사용자의 권한을 제어합니다.

1) GRANT : 데이터베이스 객체에 권한을 부여합니다.
2) REVOKE : 이미 부여된 데이터베이스 객체의 권한을 취소합니다.

DBMS의 특징과 장단점

1) 계층형 DMBS

(1) 특징
① 데이터간에 1:N 관계를 유지한다.
② 데이터가 트리 형태로 저장되는 모델을 사용한다.
③ 가장 오래 되었다.
④ 각 계층이 물리적 포인터로 연결되어 있으며, 종속적 관계를 지닌다.

(2) 장점
① 부모, 자식 세그먼트(노드) 사이에 항상 연결될 수 있기에 1:N 관계를 갖는 대용량 데이터베이스 처리에 매우 강력하다.
② 데이터베이스 무결성의 조건에 대해 좋은 성능의 관리가 가능하다.

(3) 단점
① 한 번 구축하면 구조를 변경하기 어렵다.
② 트리 구조 내에서는 순환이 허영되지 않는다.
③ 데이터 저장의 물리적 구조에 대한 이해도가 높게 필요하다.
④ 계층형 구조상의 한계로 1:N 기준에 맞지 않는 일반적 관계를 구현하기 매우 어렵다.

2) 네트워크 DMBS

(1) 특징
① 데이터간에 N:N 관계를 유지한다.
② 망 형태로 구성된 모델을 사용하며 계층형 트리를 확장한 형태이다.
③ 레코드간의 관계가 링크로 표현되는 점은 계층적 모델과 유사하나, 구조는 순환을 허용한다.

(2) 장점
① 계층구조에 링크를 추가하여 유연성과 접근성이 우수하다.
② 데이터 추출이 빠르고 효과적이다.

(3) 단점
① 유지보수 비용이 많이 든다.
② 프로그램 작성시 프로그램의 구조를 이해해야만 작성이 가능하다. (계층형 모델과 유사)
③ DataBase 구조 변경시 이를 참조했던 모든 응용프로그램에 대한 수정을 요한다.

3) 객체지향 DMBS

(1) 특징
① 정보은닉, 상속성, 다형성 등을 포함하며, 데이터베이스로서 오브젝트 식별자와 오브젝트간의 관계와 같은 추가적 특징을 지닌다.

(2) 장점
① 강력한 Data 모델링 기능을 제공한다.
② 데이터와 관련연산을 동시에 표현한다.
③ 사용자 데이터 구조 및 연산을 정의할 수 있는 확장성을 지닌다.
④ 재사용성 및 우수한 질의가 가능하다.

(3) 단점
① 기본 DB 기능 제공 미흡
② 수행속도 등의 성능저하
③ 신개념에 대한 경험 및 기술부족
④ 기존 RDB와 호환문제(SQL 지원못함)

4) 관계형 DBMS

(1) 특징
① 데이터간에 1:1 관계를 유지한다.
② 데이터가 2차원 구조의 테이블로 구성된 관계형 모델을 사용한다.
③ 한 테이블은 다수의 열로 구성된다.
④ 각 열은 레코드 단위로 구성된다.
⑤ 데이터간의 연결은 키의 중복으로 생성된다.
⑥ 현재 판매되는 대부분의 DMBS

(2) 장점
① 다른 DataBase로의 변환이 용이하고, 간결하며, 판독이 용이하다.
② 네트워크, 계층형에서 발견되지 않는 구조적 독립성을 가진다.
③ 실제 데이터 저장의 물리적 구조의 특성으로부터 사용자를 자유롭게 하여 DataBase를 설계하고 이를 관리하기가 다른 모델보다 유용하다.
④ 유연한 질의 능력을 가진다.

(3) 단점
① 데이터 종속성, 구조적 종속성 및 강력한 질의 처리의 장점을 해결하기 위해 실제적인 하드웨어와 운영체제 등의 오버헤드가 필요시 된다.
② 결과적으로 다른 모델 DMBS에 비교하여 느린 경향이 있으나 이는 현재 하드웨어와 운영체제의 급속한 성장으로 큰 단점은 되지 못한다.

5) 객체관계형 DMBS

(1) 특징
① 사용자 정의 타입, 참조 타입, 중첩 테이블을 지원한다.
② 대단위 객체(LOB, Large Object)의 저장, 추출이 가능하다.
③ 객체 간의 상속 관계를 지원하는것이 가능하다.
④ 새로운 응용에 대한 지원(복잡한 데이터 모델 등)과 효율적인 질의 처리가 요구된다.

(2) 장점
① 빈번한 동일 객체 접근시 빠른 접근을 제공한다.
② 복잡한 데이터 모델 지원

(3) 단점
① 효율적인 질의 처리 미비

Replication 이란?

 대규모로 운영중인 MySQL 데이터베이스의 문제는 server를 중단시키지 않고 전체 백업(clean backup)을 하는 것이다. 백업은 시스템을 느리게 만들며, 백업을 수행중인 테이블과 관련된 데이터가 변경될 수 있기 때문에 데이터 일관성을 해칠 수도 있다. server를 다운시키면 일관된 데이터를 얻을 수 있지만 이는 사용자에게 서비스 중단을 의미한다. 반드시 필요하고 어쩔 수 없는 경우라면 server를 다운시킬 수 있지만, 데이터를 백업하기 위해 매일 server를 중단하는 것은 받아들이기 어려운 일이다. 날마다 server를 중단하지 않고 안정적인 백업을 받는 방법은 MySQL에 Replication(replication)를 설정하는 것이다.
Replication이란 여러 대의 DBserver가 동일한 데이터를 지속적으로 가지고 있을 수 있는 기능이라 말 할 수 있다. 이 기능을 사용하면 실시간 백업과 DBserver 부하 분산도 가능하다. Replication을 이용하면 Master의 데이터와 동일한 데이터를 가진 여러 개의 Slave를 만들수 있다. 이 기능은 Mysql-3.23.15부터 지원되었다.
Mysql에서는 모든 데이터 변동 시 로그를 남기는 기능이 있다. Slaveserver는 Master의 binary 로그의 내용을 가지고 자기자신에 Update한다. 그러므로 모든 update query는 Master에서만 수행이 되어야만 하며 select와 같은 단순한 query는 slave에서 사용 가능하다.

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

내 의견

1. master에서만 INSERT, UPDATE, DELETE를 하는 이유는 마스터 -> 슬레이브로의 단방향 동기화를 위해서 이다. 역 방향으로 이 CRUD가 이루어지면 동기화는 지켜지기 어렵다. master에서 이뤄지는 SELECT는 실시간을 처리를 요하는 부분에만 사용하도록 하자.

2. INSERT, UPDATE, DELETE는 꼭 해당 DB에 접속해서 작업할 것!

3. Replication DB 사용시 유의사항

- UPDATE JOIN, DELETE JOIN시에 해당 TABLE이 존재하는지 확인

- 슬레이브에서 일부의 테이블만 지니고 있다면 그 DB에서 에러 발생 가능

// tomcat - server.xml파일에 DB Connection생성을 위한 설정(<Host>태그 내부에 추가함)

<Context Path="/myapp" docBase="myapp" debug="5" reloadable="true" crossContext="true">

<Resource name="jdbc/TestDB" auth="Container" type="javax.sql.DataSource"

                maxActive="100" maxIdle="30" maxWait="10000"

                username="sys" password="password"    

                driverClassName="com.microsoft.jdbc.sqlserver.SQLServerDriver"

                url="jdbc:Microsoft:sqlserver://localhost:3306/javatest?autoReconnect=true"/>

</Context>

//내용설명

Context - path : URL 호출시 사용될 이름

            - docBase : 실제 웹 어플리케이션이 위치한 폴더명

            - debug : 로그 작성 레벨

            - reloadable : 톰캣서버의 재시작 없이 수정된 내용을 불러오기 위한 옵션

            - crossContext : myapp이외의 Context에서도 사용 가능하도록 하는 옵션

Resource - name : Resource명칭(JNDI Lookup 시 사용할 명칭)

              - auth : Resource 관리자를 지정. 여기서는 톰캣컨테이너가 관리자임

              - type : Resource 의 형태 지정. 데이타소스 형태를 지정함

              - maxActive : 최대 연결 가능한 Connection 숫자를 지정함

              - maxIdle : Connection pool 유지를 위해 최대 대기 connection 숫자

              - maxWait : Connection 재 사용을 위해 대기해야 하는 최대 시간(단위:ms)

              - username : DB접속 계정

              - password : DB접속 암호

              - driverClassName : DB와 접속하기 위한 driver 클래스를 지정. 예에서는 MySql임

              - url : 접속한 DB가 위치한 서버명, 포트명, 사용할 데이타베이스명을 지정

// tomcat - web.xml파일에 DB Connection생성을 위한 설정

<resource-ref>

              <description> DB Connection </description>

              <res-ref-name>jdbc/TestDB</res-ref-name>

              <res-type>javax.sql.DataSource</res-type>

              <res-auth>Container</res-auth>

</resource-ref>

//내용설명

resource-ref - description : 참조할 resource에 대한 설명

                  - res-ref-name : 참조할 resource의 명칭. Server.xml에 정의된 이름과 일치해야함

                  - res-type : 참조할 resource 형태로 여기서는 DataSource를 지정함

                  - res-auth : 참조할 resource를 관리할 주체로 톰캣컨테이너를 지정함

- jsp 페이지에서 호출방법

   Context ic = new InitialContext();
   DataSource ds = (DataSource) ic.lookup("java:comp/env/jdbc/TestDB"); 
   con = ds.getConnection();

  * mysql 의 경우 context 가 다르면,  각각 설정을 따로 하셔야 합니다.

  * data source 의 접근 방식은 다음과 같이 할 수도 있습니다.

   Context initContext = new InitialContext();
   Context envContext  = (Context)initContext.lookup("java:/comp/env");
   DataSource ds = (DataSource)envContext.lookup("jdbc/TestDB"); 

  * tomcat 에서 JNDI 관련 에러메시지별 대처 방법

    - Cannot load JDBC driver class 'com.mysql.jdbc.Driver', cause: com.mysql.jdbc.Driver 또는

       Null Pointer Exception '', cause: No suitable driver

    ==> 해당 jdbc 드라이버(위의경우 mysql 드라이버) 가 없기 때문입니다.

          해당 드라이버 파일을 $CATALINA_HOME/common/lib 디렉토리로 복사합니다.

    - Name xxxx is not bound in this Context

      ==> server.xml 과 web.xml 에서 해당 JNID가 설정되지 않은 경우입니다.

           server.xml 과 web.xml 에 JNDI resource 를 설정하고 이름을 동일하게 설정하도록 합니다.

        return NO;

}

[webView stringByEvaluatingJavaScriptFromString:[NSString stringWithFormat:@"return_orgFile(\"%@\");", filename]];

나. Web에서는 자바 스크립트 동작.

function return_orgFile(strName) {

alert(strName);

}

참고 : http://mingu.kr/68

 

더보기

접기

 

 UIWebView 와 Application (App) 간의 통신

UIWebView 에 특정 페이지를 Request 하고나면, Application 의 메소드를 실행하고 싶지만 말 그대로 웹뷰이기 때문에 불가능한 경우가 많이 있습니다.

예를 들어, 어플 상에서 UITableView 같은 컨트롤에 리스트를 출력하고, 선택하면 UIWebView 로 상세 페이지를 보여준다고 가정합니다. 이런 경우, 페이지간 이동을 Navigation으로 해서 Back 을 통해 다시 리스트로 돌아가는 방법이 있을 뿐, UIWebView 내에서 <input type=submit ...> 같은 버튼을 통해서 Back 하거나 새로운 UIViewController 로 연결할 수가 없습니다.

이런 경우에 해결책은 다름 아닌, UIWebViewDelegate 에 있습니다.

구현 시나리오는 이렇습니다.

1. Web 과 App 이 통신할 수 있도록 하나의 Protocol 을 정의.

2. Web 상에서 버튼 등 Request가 일어나게 하는 컨트롤을 이용해 Protocol 을 써줍니다. 

3. App 상에서 webView: shouldStartLoadWithRequest: navigationType: 메서드를 구현하여 정의된 Protocol 을 찾아 구현 될 메서드를 실행.

저는 Javascript를 이용해 구현 해 봤습니다. 

1. Protocol 을 정의

"toApp:relationButton:param1"

저는 Protocol 을 이렇게 정의 했습니다. 원하시는 형태로 마음껏 구성하시되 3번 항에서 파싱만 완벽히 맞춰 주시면 되겠죠.

위 프로토콜을 정의하면서 파싱을 고려해야 하는데요, 저는 : 로 문자열을 나눈 후, 첫번째와 두번째 텍스트 각각이 toApp, relationButton 일 경우 세번째 텍스트인 param1 를 App 상에서 받아서 처리하기 위해서 Protocol 을 위와 같이 정의 한 것입니다.

2. Web 상에서 버튼 등 Request가 일어나게 하는 컨트롤을 이용해 Protocol을 써준다.

Web 상에서는 버튼등의 컨트롤을 사용해 Request가 일어나게 할 수 있죠. 이를 이용해 Javascript로 버튼이 onClick 시에 스크립트를 실행하도록 할 것이고, 스크립트에서는 Protocol을 써줄것입니다.

2-1. 스크립트에 Protocol을 써 주는 메서드를 정의

<script type="text/javascript">
     function eventtoApp(param1) {
          document.location = "toApp:relationButton:" + param1;
     }

</script>

2-2. HTML Body 내에서 버튼의 onClick 이벤트에 스크립트 실행 연결

<input type=submit onClick="javascript:eventtoApp('P0001001')";/>

3. App 상에서 webView: shouldStartLoadWithRequest: navigationType: 메서드를 구현하여 정의된 Protocol 을 찾아 구현 될 메서드를 실행.

마지막으로, App상에서 UIWebViewDelegate내 메서드인 webView: shouldStartLoadWithRequest: navigationType: 메서드를 구현 해 줍니다.

이 메서드는 UIWebView 컨트롤에서 Request가 일어날 때마다 들어오게 되는데요. 메서드의 반환형식은 BOOL 타입입니다. YES를 반환할 경우 UIWebView 에서 컨텐츠를 로드하게 됩니다.

그래서, 1번항에서 미리 정의 했던 Protocol 을 파싱하는 로직을 구현하되, 매치되지 않는 경우에는 return YES; 를 해 줘야 합니다. 정확히 매치되는 경우에만 어플에서 처리를 할 수 있도록 하면 되는 것이죠. 바로, 이 부분이 앞서 Protocol 에서 App 상에서 필요한 것은 param1 뿐이지만, toApp:relationButton 와 같은 전제를 붙인 이유입니다. 정확히 toApp:relationButton 가 매치되는 경우에만 파싱을 해서 param1을 가져오기 위함인 것이죠.

파싱은 간단하게 구현 하실 수 있습니다.

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request 

 navigationType:(UIWebViewNavigationType)navigationType {

NSString *requestString = [[request URL] absoluteString];

NSArray *components = [documentLocation componentsSeparatedByString:@":"];

if([components count] <= 1) {

 

return YES;

}

if ([(NSString *)[components objectAtIndex:0] isEqualToString:@"toApp"]) {

// 1번째 문자열이 toApp인 경우

if([(NSString *)[components objectAtIndex:1] isEqualToString:@"relationButton"]) {

// 2번째 문자열이 relationButton인 경우

NSLog(@"%@", [components objectAtIndex:2]); // param1

return NO;

}

}

 

 

}

Request가 일어난 뒤 받아온 문자열을 : 로 구분하여 나눈 뒤, 첫번째 텍스트와 두번째 텍스트가 각각 toApp, relationButton 인 경우에만 3번째 param1 을 받아와서 사용합니다. 그 외의 경우에는 return YES; 를 통해 UIWebView 컨트롤에서 컨텐트를 로드하도록 나두고요. 

여기 예문에서는 NSLog로 어플에서 잘 받아지는가만 출력 해 봤습니다. param1을 어플 내 화면에 출력하거나, 다른 메서드를 실행하기 위한 파라미터로 사용하거나 하는 등.. 결과적으로는, Web에서 App을 호출하는 형태를 구현하실 수 있습니다. :)

 

 

접기