본문 바로가기

CS 과목(CS科目）/데이터 베이스（データベース）

Inner Join과 Cross Join(세타 Join)의 차이 Inner Join : FK와 PK를 이용하여 Table들을 Join Cross Join(세타 Join) : FK,PK이용하는 것 없이, 모~~든 Tuple들에 대해서 막 Join한다. 더보기
페이징(Paging) 페이징 : [한 화면]에서 보여 줄 수 있는 데이터의 범위를 결정하는 것 우리가 흔히 접하는 일반적인 웹 게시판이나 조회 화면을 생각하면 된다. 조회 대상 데이터가 10만 건이라면 한 화면에서 모두 보여 줄 수는 없다. 더보기
DB 설계 시, 多 관계에 있는 Table에 FK가 있어야 하는 이유 사전 지식 : FK는 단 1개의 TABLE만을 가리킬 수가 있다.( 위 그림은 여러 Member들(Member Table)이 하나의 Team(1개의 Team Table)에 소속되어 있음을 뜻함) Member : Team == 多 : 1의 관계이다. 즉, 여러 Member들이 하나의 Team(하나의 Team Table에 소속)에 소속될 수 있다는 것이다. 만약 Member Table에 TEAM_ID가 FK로 있어야 2명 이상의 Member들이 Table에 들어 왔을 때, 그 2명 이상의 Member들이 하나의 Team 소속(하나의 Team Table을 가리키고 있다는 것을)이라는 것을, TEAM_ID(FK)로 나타낼 수가 있다. 반대로 만약, FK가 Team Table의 MEMBER_ID였다면, 해당 팀 .. 더보기
Associational Relation의 주인(Owner)에 대해 확실히 이해하자! Player, Team(多：１)라는 2개의 Table이 있다고 하자. DB는 Foreign Key(FK) 하나로만 Table들의 연관 관계를 만든다.(FK로 JOIN연산을 통해서) 그러나 클라이언트 코드에서는 2개의 객체 사이의 연관 관계를 맺기 위해서는 Player 객체에 Team객체를 가리키는 참조 변수와 Team 객체에 Player 객체를 가리키는 참조 변수(List players), 즉 2개의 참조변수가 선언돼서, 서로가 서로를 가리키도록 해줘야 한다. ========================================================== DB의 Table : Foreign Key(FK) 하나로만 Table들의 연관 관계를 만든다 객체 : 2개의 참조변수가 선언돼서, 서로가 서로.. 더보기
ORM 프레임워크를 사용하는 이유(ex. JPA..) ORM(Object - realtional mapping) -> 객체는 객체대로 설계를 하고, DB는 Relational하게 설계를 하면서, 이 2개의 패러다임의 차이로 생기는 [SQL 중심적인 개발]이라는 문제를 [JPA와 같은 ORM 프레임워크]가 중간에서 매핑함으로써 해결해 준다. Object와 RDB의 차이 [1. 상속 관계의 유무] -> RDB에도 [Super Type], [Sub Type]이 존재하지만, OPP에서의 그것들과는 다른 의미이다. Album 저장 1. 객체 분해 : RDB는 Album이라는 상속 관계에 의한 Table을 만들 수가 없으므로, 아래와 같이 SQL을 크게 2개로 나누어 서 작성을 해 줘야 한다. ( 만약 Album 객체의 부모 클래스가 100개 있다면??? -> 100.. 더보기
28. NoSQL( MongoDB, Redis, etc ) RDBMS의 단점 1. Column을 추가할 때마다, 스키마를 변경해야 한다( 경직된 스키마 ) 2. 너무 많은 JOIN 연산을 하게 된다.( DB 서버의 CPU,메모리 과부하 ) 데이터가 중복으로 저장되는 것을 막기 위하여 3NF, BCNF를 통해 아래와 같이 원본 테이블을 분할을 하였다. 그런데 만약 원본 테이블의 tuple을 조회하고 싶을 때, 위 4개의 table들에 대해 JOIN 연산을 해야 한다. 이렇게 되면, DB 서버는 JOIN 연산을 실행하기 위하여, CPU와 메모리를 상당 부분 사용하게 될 것이다. 3번째 단점을 살펴보기에 앞서 , scale - up과 scale out에 대한 알고 가자. scale - up : 컴퓨터의 cpu, 메모리 등을 더 좋은 성능의 것으로 바꾸어서 퍼포먼스를 .. 더보기
27.DBCP(DB Connection Pool) 보통의 경우, Logic 서버와 DB 서버의 통신은 TCP 기반으로 이루어 진다. 이 2 개의 서버 사이에서 쿼리를 던지고 전, 그리고 쿼리에 대해 응답을 한 후에는 각각 Connection(3-way)을 미리 맺고 쿼리 수행이 다 끝나게 되면, 그 Connection을 닫아 준다(4-way). 이러한 과정은 높은 데이터 신뢰성을 보장하는 반면에, 시간 비용이 많이 든다는 단점이 존재한다. ( Logic 서버는 계속해서 쿼리를 요청하게 될 것이고, API 마다 한 번의 쿼리가 아니라, 여러 번의 쿼리를 날리게 되는 경우 가 있다. 이러한 경우 시간 비용은 매우 매우 큰 단점이다.) 위와 같은 단점을 해결하기 위해 나온 것이 DBCP이다. DBCP의 동작 방식 Logic 서버에서 API 요청을 하기 이전에.. 더보기
Holder 기법!!!! 동기화(Synchronization)을 위하여, 우리는 데이터를 매개변수로 일일이 넘겨 주곤 하였다. 그러나 이와 같은 방식은 코드를 번잡하게 만들며, 개발자들의 실수를 유도한다. 그래서, Holder 기법을 이용하는 것이 현명하다. 예를 들어, TraceId를 일일이 메서드에 매개변수로 전달시키는 것이 아니라 하나의 클래스에 TraceId traceHolder라는 필드를 선언을 해 주고, 이 필드에 TraceId 객체를 저장하여, 필요할 때마다 꺼내서 쓰게 하면 된다. ( advanced 파일의 FiledLog.java 코드 참고!! ) 더보기

티스토리툴바