30. 데이터베이스는 세부사항이다

아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다.

데이터 모델과는 달리 아키텍처 관점에서는 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다.

데이터베이스는 소프트웨어일 뿐이며, 데이터에 접근할 방법을 제공하는 유틸리티이다.

유틸리티는 저수준 세부사항(메커니즘)일 뿐 아키텍처와는 관계 없으므로, 데이터베이스를 이용한다는 사실이 아키텍처에 영향을 주지 않아야한다.

관계형 데이터베이스

관계형 테이블은 특정한 형식의 데이터에 접근하는 경우에 편리함을 제공하지만, 데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요하지 않다.

따라서 (관계형 데이터베이스에 저장된)데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야한다.

소프트웨어에서 테이블과 행을 허용한다면, 유스케이스, 업무 규칙, UI조차도 관계형 데이터 구조에 결합되어버린다.

데이터 저장 공간의 한계로 디스크를 사용할 수 밖에 없었기 때문이다.

디스크의 단점은 느리다는 점 인데, 이로인해 발생하는 성능 저하 완화를 위한 색인, 캐시, 쿼리 계획 최적화가 필요해졌다.

색인, 캐시, 쿼리 계획을 위해 작업중인 대상이 어떤 데이터인지 알 수 있어야 했으므로 데이터를 표현하는 일종의 표준적인 방식도 필요했고, 시간이 흘러 파일 시스템과 관계형 데이터베이스 관리 시스템(RDBMS) 2가지 유형으로 분리되었다.

파일 시스템

문서(document) 기반 시스템으로, 문서 전체를 자연스럽고 편리하게 저장하는 방법을 제공한다.

문서를 이름을 기준으로 저장하거나 조회할 때는 잘 동작하지만, 내용을 기준으로 검색할 때는 크게 도움되지 않는다.

데이터베이스 시스템

내용 기반 시스템으로 내용을 기반으로 레코드를 자연스럽고 편리하게 찾는 방법을 제공한다.

레코드가 서로 공유하는 일부 내용에 기반해서 다수의 레코드를 연관 짓는 데 매우 탁월하지만, 정형화되지 않은 문서를 저장하고 검색하는 데는 대체로 부적합하다.

각 시스템은 데이터를 디스크에 체계화하고 특화된 방식으로 데이터를 저장하고 검색할 수 있도록 하며, 성능을 높히기 위해 데이터를 색인하고 RAM에 배치하는 고유한 전략을 활용한다.

디스크는 RAM으로 대체되고있다.

모든 데이터가 RAM에 저장된다면 데이터들을 연결 리스트, 트리, 해시 테이블, 스택, 큐 와 같은 데이터 구조로 체계화 될 것이며, 데이터에 접근할 때는 포인터나 참조를 활용할 것이다.

데이터가 데이터베이스나 파일 시스템에 있더라도, RAM으로 읽은 후에는 다루기 편리한 형태로 그 구조로 변경하는데, 이는 프로그래머가 하는 일로 그대로 하면 된다.

데이터가 파일 시스템이나 데이터베이스 시스템을 통해 저장된다고 하더라도 결과적으로 실제 데이터를 처리할 때는 사용하기 편한 방식(자료구조)으로 처리하여 RAM에 올려 사용하게 된다.

이처럼 데이터베이스는 디스크와 RAM 사이에서 데이터를 옮길 때 사용할 뿐인 메커니즘이고, 데이터를 장기적으로 저장하는 공간일 뿐이다.

따라서 아케텍처 관점에서 본다면 데이터베이스는 세부사항이므로, 데이터가 어떤 형태로 어디에 저장되어있는지 인식해서는 안된다.

데이터 저장소 측면에서 성능은 완전히 캡슐화하여 업무 규칙과는 분리할 수 있는 관심사이다.

데이터 저장소에서 데이터를 빠르게 넣고 뺄 수 있어야 하는 것은 맞지만, 이는 저수준 관심사로 저수준의 데이터 매커니즘 단에서 다뤄야한다.

따라서 데이터 저장소의 성능은 시스템의 전반적인 아케텍처와는 관계가 없다.

체계화된 데이터 구조와 데이터 모델은 아키텍처적으로 중요한 반면, 데이터를 디스크에서 이리 저리 옮길 뿐인 기술과 시스템은 아키텍처적으로 중요하지 않다.

데이터를 테이블 구조로 만들고 SQL로만 접근하도록 하는 관계형 데이터베이스 시스템은 후자와 관련이 깊으므로 아키텍처적으로 종요하지 않다.

데이터는 중요하나, 데이터베이스는 세부사항이다.