'데이터베이스'에 해당되는 글 5건

보통 외래키는 관계형 데이터베이스에서 무결성을 유지하기 위해서 사용합니다. 저는 테이블 간의 관계를 명시하기 위해서 사용하기도 하였습니다.

아직까지는 진행하는 프로젝트들이 규모가 작고 개인으로 하는 것들이 위주라서 주로 MySQL을 사용해왔습니다. mysql은 관계형 데이터베이스다보니 테이블의 개수가 많아지면 외래키를 사용하는 경우가 가끔 있었는데 외래키와 관련된 무결성 제약조건 때문에 애를 먹었던 적이 많았습니다. 

얼마 전에 친구가 mysql 외래키에 대해서 물어봤을 때 다 까먹어서 제대로 대답하지 못했습니다. 그래서 자료를 찾다가 왜 외래키를 사용하는지 궁금해졌습니다. 그리고 흥미로운 사실을 알 수 있었습니다. 

현업에서는 외래키를 잘 사용하지 않는다는 것이었습니다. 대부분 로직이 수시로 바뀌어서 프로그램이 바뀌면 무결성 때문에 DB의 구조도 바꿔야 되서 업무량이 엄청 늘어나기 때문이었습니다. 저도 웹 프로젝트를 진행하면서 미숙한 설계로 프로그램에 변동이 자주 있었는데 그 때마다 FK로 걸었던 참조 무결성이 가끔씩 오류를 터뜨려줘서 꽤나 고생했어서 공감이 되었습니다.

당연히 현업에서 DB를 논리적 설계 단계에서는 FK가 존재합니다만 그것을 실제로 DB에서 구현할 때에는 명시하지 않고 프로그램의 로직을 무결성을 유지하도록 짠다고 합니다. 그리고 JOIN 등을 이용하여 FK를 사용한 것과 같은 기능을 구현할 수 있다고 합니다.

이렇게 하는 이유는 현실적인 번거로움 뿐만 아니라 성능 개선의 측면도 있습니다. SELECT, DELETE를 할 때에는 상관 없지만 INSERT, UPDATE를 할 때 FK를 사용하면 약간 느려진다고 합니다.

하지만 결제 시스템과 같이 굉장히 중요한 데이터를 다룰 때에는 무결성을 유지하기 위해서 FK를 사용한다고 합니다. 즉, 상황에 따라 융통성있게 사용한다는 것이죠. 그리고 DB에서 무결성을 보장해주지 않는 대신 어플리케이션 단에서 확실히 처리를 해야할 것입니다.

사실 제가 진행하는 프로젝트는 규모가 그렇게 크지도 않고 성능 차이가 확 와닿을 정도로 데이터가 많은 것도 아니라서 FK를 사용할 생각이기는 합니다만... 왠만하면 중요한 테이블에만 달고 다른 것들에는 편의를 위해서 생략하지 않을까 생각합니다.

Ubuntu 16.04에 mysql을 설치하는 것은 별로 어렵지 않았습니다.

my.cnf 파일을 수정해서 utf-8을 기본 설정으로 하는데 역시 한 번에 안 되더군요. 그렇게 mysql 을 삭제하고 설치하고 삭제하고...

그냥 짜증나서 예전에 사용하던 방법을 사용하기로 하였습니다.

설치

sudo apt-cache search mysql-server
sudo apt-get install mysql-server

제거

apt-get purge mysql-server
apt-get purge mysql-common
rm -rf /var/log/mysql
rm -rf /var/log/mysql.*
rm -rf /var/lib/mysql
rm -rf /etc/mysql


apt-get install mysql-server --fix-missing --fix-broken 

utf-8 설정

테이블을 생성할 때마다 DEFAULT SET=UTF8을 붙여줍니다.

create table customer( 
num int not null,
 name varchar(50), 
primary key (num)
)default charset=utf8;

오래된 글이지만 join을 이해할 때 많은 도움이 되어서 링크를 올립니다.

http://blog.naver.com/tyboss/70008713640

(아래 정리한 내용은 아직 완성되지 않은 글입니다. 자료 보충도 필요합니다. 정확하게 공부하고 싶으시다면 위의 링크에서 보시거나 다른 글을 보는 것이 좋을 듯 합니다.)

JOIN이란 2개의 테이블의 데이터들을 하나의 테이블에 나타내는 것입니다.

1. FULL JOIN

각 테이블의 튜플들을 모두 매치시키는 JOIN입니다.

2. INNER JOIN

THETA JOIN에서 WHERE 문을 이용하여 조건을 제시했다면 INNER JOIN에서는 on test1.a = test2.b와 같이 조건을 지정할 수 있습니다.

3. LEFT OUTER JOIN

가장 많이 사용하는 JOIN 중 하나입니다. 

JOIN할 때의 조건이 ON test1.a = test2.b 일 때, INNER JOIN 같은 경우에는 test1과 test2 테이블에서 서로 조건에 맞는 데이터들만 조인됩니다.

하지만 LEFT OUTER JOIN을 사용하면 기본적으로 모든 test1의 데이터들이 조인 테이블에 들어가고 거기에 조건에 매치되는 test2의 데이터들이 들어갑니다.

이 때 test2가 매치되는 데이터가 없다면 NULL로 표시됩니다.

JOIN문을 사용할 때 OUTER는 옵션이므로 명시하지 않아도 된다고 합니다.

4. RIGHT OUTER JOIN

LEFT OUTER JOIN의 반대라고 생각하시면 됩니다.

test2의 모든 데이터가 JOIN됩니다.

5. SELF JOIN

참고

http://rapapa.net/?p=311

이전에 트랜잭션과 회복 기법에 대해 조사해봤었는데 이제와서 다시보니 헷갈려서 회복에 대해 다시 정리하기로 하였습니다.

1. 즉시 갱신 회복 기법

  이 기법을 사용하면 트랜잭션 도중 데이터가 변경되면 그 내용을 DB에 즉시 반영하고 로그에 기록합니다. 트랜잭션 완료(Commit) 이전에 수행한 갱신 연산을 미완료 갱신(Uncommitted Update)라고 합니다.

  만약 트랜잭션 수행 도중 에러가 발생하면 로그에 있는 내용을 기반으로 UNDO 합니다. 

  따라서 회복을 진행하고 나면 DB는 해당 트랜잭션이 실행되기 이전으로 돌아갑니다. 이 때 로그를 참조하여 이전 상태로 돌아가는 것을 UNDO라고 합니다.

  만약 트랜잭션에서 오류가 발생하기 이전에 이미 COMMIT 된 다른 트랜잭션이 있다면 그 트랜잭션을 REDO 합니다. (이유는?) 

  그리고 트랜잭션을 다시 실행하여 DB를 변경하는데 이를 REDO 라고 합니다.

2. 지연 갱신 회복 기법

  트랜잭션이 부분 완료 상태가 되기 전까지 모든 변경 내용을 로그에만 저장합니다. 데이터베이스에는 COMMIT 할 때 반영을 합니다. 

  이 때 부분 완료란 데이터베이스가 COMMIT 되기 직전의 상태 즉, 트랜잭션에서 모든 데이터의 변경이 끝난 이후를 말합니다.

  트랜잭션 도중 에러가 발생했을 때 로그 파일을 무시한다.  COMMIT 이전이므로 DB는 트랜잭션을 실행하기 이전 상태와 같습니다.

  즉시 갱신 회복 기법에서는 UNDO를 통해 데이터베이스를 복구했어야 했던 반면에 지연 갱신 회복 기법은 UNDO가 필요없습니다.

  그리고 트랜잭션을 다시 실행하는 REDO를 합니다.

라고 알고 있었는데 아무래도 부정확한 부분들이 몇몇 있는 것 같습니다. 먼저, 지연 갱신 회복 기법과 즉시 갱신 회복 기법의 COMMIT 시점은 상황에 따라 달라집니다.

기법은 말 그대로 기법입니다. 즉, 이것들은 코드로 구현되어야 비로소 의미가 있는 것입니다. 때문에 정책 또는 개발자에 따라 COMMIT 시점이 변경되는 것입니다.

Checkcpoint는 redo를 할 때 모든 트랜잭션을 하면 효율이 떨어지기 때문에 사용합니다. 그리고 트랜잭션이 진행 중이더라도 그 시점까지 변경된 데이터를 강제로 DB에 반영합니다. 

그리고 Check Point 회복기법을 지연 갱신 회복 기법과 함께 사용합니다. 

===================================

선생님께서 즉시 갱신, 지연 갱신에 대해 다음에 다시 가르쳐주신다고 한다.

즉시 갱신, 지연 갱신 기법은 말 그대로 기법이다. 즉, 코드로 구현하는 것.

즉시 갱신은 checkpoint처럼 DB에 즉시 반영됨(확실 X)

일단 코드를 직접 봐야할 듯

지연 갱신은 보통 백그라운드에서 트리거를 통해 commit

checkpoint란, 사용하는 이유(redo할 때 효율 때문에)

checkpoint는 트랜잭션이 진행 중이더라도 그 때까지의 변경된 데이터를 바로 DB에 반영(강제출력과 비슷)

===================================

http://altibase.com/product/in-memory-database/

http://www.mcobject.com/in_memory_database

https://en.wikibooks.org/wiki/Design_of_Main_Memory_Database_System/Overview_of_DBMS

데이터베이스 트랜잭션(Database Transaction)

1. 정의

  데이터베이스 관리 시스템 또는 유사한 시스템에서 상호작용의 단위이다. 여기서 유사한 시스템이란 트랜잭션이 성공과 실패가 분명하고 상호 독립적이며, 일관되고 믿을 수 있는 시스템을 의미한다.

2. COMMIT과 ROLLBACK

1) COMMIT

- 한 트랜잭션이 성공적으로 끝났고, 데이터베이스가 일관성을 유지하며, 이 작업 단위가 수행한 연산이 완료된 것을 알려주는 연산

- 작업결과는 데이터베이스에 반영

2) ROLLBACK

- 한 트랜잭션의 수행 중 어떤 부분에서든지 한 번이라도 문제(오류)가 발생하면 해당 트랜잭션을 모두 취소하는 연산

- 작업결과는 모두 취소되게 되어 데이터베이스에 영향을 미치지 않게 됨

3. 특성

  이론적으로 데이터베이스 시스템은 각각의 트랜잭션에 대해 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 영구성(Durability)을 보장한다. 이 성질을 첫 글자를 따 ACID라 부른다.

1) Atomicity (원자성)

- 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력

ex) 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안됨

- 트랜잭션은 분리할 수 없는 하나의 단위

- 작업이 모두 수행되거나 하나도 수행되지 않아야 함

2) Consistency (일관성)

- 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미

ex) 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단

- 이 일관성은 '잠금'과 관련이 있음

3) Isolation (격리성, 고립성)

- 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미

ex) 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없음

- 트랜잭션이 발생하기 이전 상태나 완료된 이후 상태를 볼 수는 있지만, 트랜잭션이 진행 중인 중간 데이터를 볼 수 없음 (이를 피해가는 방법도 있음)

4) Durability (영속성)

- 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미

- 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있음

- 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있음

4. 목적

- 데이터베이스 기능 중, 트랜잭션을 조작하는 기능은 사용자가 데이터베이스 완전성(integrity) 유지를 확신하게 한다.

- 단일 트랜잭션은 데이터베이스 내에 읽거나 쓰는 여러 개 쿼리를 요구한다. 이 때 중요한 것은 데이터베이스가 수행된 일부 쿼리가 남지 않는 것이다. 예를 들면, 송금을 할 때 한 계좌에서 인출되면 다른 계좌에서 입금이 확인되는 것이 중요하다.

- 트랜잭션은 서로 간섭하지 않아야 한다.

5. 종류

1) 자동 커밋 트랜잭션 (Autocommit transactions)

- 각 쿼리마다 자동적으로 BEGIN TRAN ... COMMIT TRAN이 붙여지는 것을 의미

- SQLServer는 '자동 커밋 트랜잭션'을 디폴트로 사용

update v_userTbl set addr='부산' where userid = 'JKW';
update v_userTbl set addr='대전' where userid = 'KMS';
update v_userTbl set addr='서울' where userid = 'PJH';

delimiter $$
begin
update v_userTbl set addr='부산' where userid = 'JKW';
update v_userTbl set addr='대전' where userid = 'KMS';
update v_userTbl set addr='서울' where userid = 'PJH';
end$$
delimiter ;