아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다.
즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다.
애플리케이션 내부 데이터의 구조는 시스템 아키텍처에서 대단히 중요하다.
데이터베이스는 일개 소프트웨어일 뿐이다.
관계형 데이터베이스가 인기를 끈 데는 타당한 이유가 있었다. 이 모델은 우아했고, 절제되었으며, 강건했다.
관계형 데이터베이스는 데이터를 저장하고 접근하는 데 탁월한 기술이었다.
데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요하지 않다.
데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계다. 이렇게 하면 유스케이스, 업무 규칙, 심지어는 UI조차도 관계형 데이터 구조에 결합되어 버린다.
디스크 때문이었다.
디스크에서 데이터는 원형 트랙에 저장된다. 트랙은 섹터로 분할되고, 각 섹터는 사용하기 편한 크기의 바이트를 저장했는데, 대체로 4k였다.
이처럼 디스크 때문에 피해갈 수 없는 시간 지연이라는 짐을 완하하기 위해 색인, 캐시, 쿼리 계획 최적화가 필요해졌다. 그리고 데이터를 표현하는 일종의 표준적인 방식도 필요했는데, 이러한 색인, 캐시, 쿼리 계획에서 작업중인 대상이 어떤 데이터인지 알 수 있어야 했기 때문이다.
간단히 말해서 데이터 접근 및 관리 시스템이 필요했다.
시간이 지나면서 이러한 시스템은 뚜렷이 구분되는 두 가지 유형으로 분리되었다.
하나는 파일 시스템이었고, 다른 하나는 관계형 데이터베이스 관리 시스템이었다.
파일 시스템은 문서 기반이다.
데이터 시스템은 내용 기반이다.
디스크는 소멸중인 부품이다.
디스크는 RAM으로 대체되고 있다.
데이터가 데이터베이스나 파일 시스템에 있더라도, RAM으로 읽은 후에는 다루기 편리한 형태로 그 구조를 변경한다. 리스트, 집합, 스택, 큐, 트리 등 입맛에 맞는 임의의 구조로 말이다.
데이터를 파일이나 테이블 형태로 그대로 두는 경우는 거의 없다.
데이터베이스가 세부사항이라고 말하는 이유는 바로 이러한 현실 때문이다.
데이터베이스는 메커니즘에 불과하다.
아키텍처 관점에서 본다면 회전식 자기 디스크에 데이터가 있기만 한다면, 데이터가 어떤 형태인지는 절대로 신경 써서는 안 된다. 정말로 우리는 디스크 자체가 존재한다는 사실조차도 인식해서는 안 된다.
성응은 아키텍처와 관련된 관심사가 아닌가? 당연히 아키텍처적인 관심사다. 하지만 데이터 저장소의 측면에서 성능은 완전히 캡슐화하여 업무 규칙과는 분리할 수 있는 관심사다.
데이터 저장소에서 데이터를 빠르게 넣고 뺄 수 있어야 하는 것은 맞지만, 이는 저수준의 관심사다.
체계화된 데이터 구조와 데이터 모델은 아키텍처적으로 중요하다. 반면, 그저 데이터를 회전식 자기 디스크 표면에서 이리저리 옮길 뿐인 기술과 시스템은 아키텍처적으로 중요치 않다.
데이터를 테이블 구조로 만들고 SQL로만 접근하도록 하는 관계형 데이터베이스 시스템은 전자보다는 후자와 훨씬 관련이 깊다. 데이터는 중요하다. 데이터베이스는 세부사항이다.