Database/데이터베이스
데이터베이스의 충돌 상황 우리는 데이터베이스에 일련의 연산을 통해 데이터를 변경한다. 그 때, 동시에 데이터베이스에 접근하여 수정을 요청하면 충돌이 일어날 수 있다. 이런 충돌에 대비하기 위해서 낙관적 락과 비관적 락에 대해서 알아보도록 하자. 낙관적 락 낙관적 락은 충돌을 난 것을 감지할 때 처리하자는 방법이다. 일반적으로 테이블의 Version 컬럼이나 Timetable 등 데이터의 상태 구분 컬럼을 이용한다. 트랜잭션이 시작할 때 구분 컬럼을 읽은 후, 트랜잭션이 끝난 시점에서 변경 여부를 확인한다. 만약 구분 컬럼이 도중에 변경되었을 시 충돌을 감지하고, 변경 내용을 롤백하게 된다. 장점 충돌이 거의 나지 않는 환경에서 처리 성능이 비관적 락에 비해서 좋다. 다른 트랜잭션이 데이터에 접근하는 것을..
트랜잭션 (Transaction) 하나의 로직을 처리하는 SQL 질의들을 집합으로 묶어, 도중에 예외가 발생할 경우 Rollback 처리를, 모두 성공할 경우 Commit 처리하는 실행 단위이다. 쇼핑몰에서 주문할 때의 과정을 생각해보자. (주문 요청 -> 결제 처리 -> 성공 시 주문 완료 데이터 저장) 만약에 다음 과정에서 결제는 완료되었는데 주문이 들어가지 않았다면 사용자 입장에서는 어이가 없을 것이다. 또 결제 처리는 실패되었는데 주문 완료 데이터는 저장되어있다면 해당 데이터베이스는 더이상 믿을 수 없게 된다. 즉, 성공하려면 모두 성공하고, 실패하려면 모두 실패해야 한다. 트랜잭션 작성 예시 (MySQL) BEGIN START TRANSACTION;-- 트랜잭션 시작. rollback이나 com..
토이 프로젝트를 하다가 데이터베이스 정규화에 대한 토픽이 나와 이참에 나름대로 정리를 한번 해보려고 한다. 데이터베이스 구조를 잘 짜는 것은 참 중요하긴 하다. 전에 다녔던 회사에서 엄청 오래된 프로젝트의 데이터베이스 구조 변경을 하는데에 엄청 애먹었던 것이 생각난다. 한 테이블에 모든것을 때려박아서 명칭 하나 변경되어야 할 뿐이었는데 밤새서 리팩토링했던 기억이..ㅎㅎ 통용적으로 사용되는 데이터베이스 정규화 과정을 한번 정리해보면 나중에 프로젝트를 진행할 때에 정규화에서 얻을 수 있는 장점을 적용시키는 능력과, 필요시에 오히려 비정규화를 적용시킬 판단기준을 기르는 데에 도움이 될 것 같아서 한번 정리해보자! 하고 맘먹었다. 데이터베이스 정규화 정규화는 테이블의 중복 데이터를 최소화하여 데이터베이스를 설계..
앞에서 데이터베이스 링크와 스키마를 이용하여 DB 객체 참조하는 것을 다루었었다. 그런데 다음을 보자 select * from "BOB"."ALICE.TEST_TABLE"@"OTHER_DATABASE" 다음 쿼리는 다른 데이터베이스에서 BOB 스키마 이름에 있는 ALICE 스키마 이름로 접근하여 테이블을 조회한다. 무언가.. 길어 보인다. 이를 위해서 데이터베이스 동의어라는 기능을 만들어 두었다. 동의어(Synonym) : 여러 소유자나 링크 등으로 인해 객체를 참조할 때 번거로울 경우 긴 이름 대신 간단한 이름으로 대체할 수 있도록 하는 기능. CREATE OR REPLACE SYNONYM "MY_SCHEMA"."MY_TABLE" FOR "BOB"."ALICE.TEST_TABLE"@"OTHER_DATA..
프로젝트 개발을 하다보면 다른 협력사들의 데이터베이스를 참조해야 할 일이 있다. 일반적으로 모든 데이터베이스를 열어두지 않고 제한된 스키마 이름의 View, Function, Stored Procedure 등으로 일부 데이터를 제공하는 경우가 많은데, 다른 데이터베이스의 일부 스키마를 참조하여 쿼리를 만들려고 한다면, 링크를 만들어 편하게 만들 수 있다. 스키마와 스키마 이름 스키마란 데이터베이스 구조와 제약 조건에 대한 명세이다. 즉 데이터베이스 구조를 칭하는 말이다. 스키마 이름이란 스키마, 즉 해당 데이터베이스 객체들의 사용자라고 생각하면 된다. MYSQL 등 다른 데이터베이스에서의 User에 해당한다. 하나의 테이블, 뷰 등 객체들을 생성하고 운영하는 Onwer 스키마 이름이 있으며, CRUD 권..
