일반적으로 여러 DBMS 벤더 별로 플랫폼 또는 언어에 따라 접근할 수 있는 서로 다른 API들을 제공한다. 이들을 한꺼풀 덮어씌워 공통적인 방법으로 접근하도록 해주는 API를 Database Access Layer 또는 Database Abstraction Layer라고 부른다.
JDBC, ODBC, ADO.NET, Perl의 DBI, PHP의 PDO, Pear::MDB2 (Pear::DB, Pear::MDB) 등은 모두 Database Access Layer에 해당하는 것들이다. 각자 특정 플랫폼 또는 프로그래밍 언어에서 표준적인 위치를 가지고 있다. 물론 이외에도 이들과 경쟁하는 API들이 있으며, 이 외의 플랫폼 또는 언어들도 이러한 API를 가지고 있다.
Jeremy Zawodny는 LtU에서도 이슈가 된 모양인 Database Abstraction Layers Must Die!라는 글에서,
- 성능을 떨어뜨리고 복잡도를 증가시킨다.
- 데이터베이스를 쉽게 바꿀 수 있다는 이점은 별로 중요하지 않으며, 실제로는 쉽게 바꿀 수 없다.
- 데이터베이스 기능을 완전하게 활용할 수 없고, 튜닝도 제대로 할 수 없다.
는 점에서 Database Abstraction Layer를 사용하기 보다는, 데이터베이스에 접근하는 부분을 ‘라이브러리’를 사용해서 모듈화하고, 만일에 하나라도 데이터베이스를 변경할 일이 생긴다면, 이를 수정하면 된다고 설명하고 있다. 그의 주장은 일견 옳다.
이 외에도
하지만, 여러 사람이 지적한대로, 그가 얘기하는 ‘라이브러리’가 바로 Database Abstraction Layer다. 그리고,
- 성능은 떨어질 수 있지만, scalability도 떨어지는 것은 아니다.
- 여러 데이터베이스를 지원해야하는 소프트웨어도 존재한다.
- 하나의 소프트웨어에서 데이터베이스를 바꾸지 않더라도, 프로그래머는 여러 소프트웨어에서 서로 다른 데이터베이스를 접근해야한다.
- Database Abstraction Layer 라기보다는 Database Access Layer다. 즉, 데이터베이스의 공통적인 기능에는 공통적인 방법으로 접근할 수 있도록 하지만, 특정한 데이터베이스가 지원하는 기능을 접근하도록 만들 수도 있다.
는 면에서 Database Access Layer는 유용하다.
JDBC를 예로 들어보면,
- 많은 Java 프로그래머들은 특정 데이터베이스 API를 익힐 필요없이 JDBC만을 알아도 데이터베이스에 접근하는 기본적인 프로그램을 짤 수 있다.
- 특정한 데이터베이스가 지원하는 대부분의 기능은 SQL이라는 불투명한 데이터를 전달하는 API를 통하거나, 설정을 통해 동작방식을 제어하는 방식으로 접근할 수 있다.
‘왜 PHP 개발자들은 Pear::MDB2 또는 PDO를 아직 사용하지 않는가’라고 물어보면 분명 위와 같은 이유로 반대하는 사람들이 많을 것이라고 생각한다. 이 글이 그에 대한 대답이다. 그리고 한가지 더, JDBC, ODBC, ADO.NET, Perl DBI 등의 성공은 결정적으로 Database Access Layer의 유용함을 반영하고 있다. JDBC를 한번이라도 사용해본 사람들이 PHP의 mysql이나 mysqli 모듈로 돌아갈 것이라고 절대 상상할 수 없다.