ODBC를 만든 이유는 무엇인가요?

지금까지 회사는 단일 DBMS를 사용했습니다. 모든 데이터베이스 액세스는 해당 시스템의 프런트 엔드 또는 해당 시스템에서만 작동하도록 작성된 애플리케이션을 통해 수행되었습니다. 그러나 컴퓨터의 사용이 증가하고 컴퓨터 하드웨어 및 소프트웨어를 더 많이 사용할 수 있게 되면서 회사는 다른 DBMS를 획득하기 시작했습니다. 그 이유는 많은 것이었습니다: 사람 가장 저렴한 것, 가장 빠른 것, 이미 알고 있는 것, 시장에서 최신 버전, 단일 애플리케이션에 가장 적합한 것을 구입했습니다. 다른 이유는 이전에 단일 DBMS를 가진 부서가 이제 여러 가지가 있는 재구성 및 합병이었습니다.

이 문제는 개인용 컴퓨터의 출현으로 더욱 복잡해졌습니다. 이러한 컴퓨터는 저렴하고 사용하기 쉬운 여러 데이터베이스와 함께 데이터를 쿼리, 분석 및 표시하기 위한 다양한 도구를 가져왔습니다. 그 때부터 단일 기업은 수많은 데스크톱, 서버 및 미니컴퓨터에 흩어져 있고, 호환되지 않는 다양한 데이터베이스에 저장되고, 방대한 수의 다양한 도구에 의해 액세스되는 경우가 많았으며, 그 중 몇 가지는 모든 데이터를 가져올 수 있었습니다.

마지막 과제는 컴퓨터 리소스를 가장 효율적으로 사용하려는 클라이언트/서버 컴퓨팅의 출현과 함께 이루어졌습니다. 저렴한 개인용 컴퓨터(클라이언트)는 데스크톱에 앉아 데이터에 대한 그래픽 프런트 엔드와 스프레드시트, 차트 프로그램 및 보고서 작성기와 같은 다양한 저렴한 도구를 모두 제공합니다. 미니컴퓨터 및 기본프레임 컴퓨터(서버)는 DBMS를 호스트하며, 여기서 컴퓨팅 능력과 중앙 위치를 사용하여 빠르고 조정된 데이터 액세스를 제공할 수 있습니다. 그렇다면 프런트 엔드 소프트웨어를 백 엔드 데이터베이스에 연결하려면 어떻게 해야 할까요?

비슷한 문제가 ISV(독립 소프트웨어 공급업체)에 직면했습니다. 미니컴퓨터 및 기본프레임용 데이터베이스 소프트웨어를 작성하는 공급업체는 일반적으로 각 DBMS에 대해 하나의 버전의 애플리케이션을 작성하거나 액세스하려는 각 DBMS에 대해 DBMS 관련 코드를 작성해야 했습니다. 개인용 소프트웨어를 작성하는 공급업체는 작업하려는 각 DBMS에 대한 데이터 액세스 루틴을 작성해야 했습니다. 이는 종종 애플리케이션이 아닌 데이터 액세스 루틴을 작성하고 기본 많은 양의 리소스를 사용하고, 애플리케이션은 품질이 아니라 지정된 DBMS의 데이터에 액세스할 수 있는지 여부에 따라 판매되는 경우가 많습니다.

두 개발자 집합 모두 서로 다른 DBMS의 데이터에 액세스하는 방법이었습니다. 기본프레임 및 미니컴퓨터 그룹은 단일 애플리케이션에서 서로 다른 DBMS의 데이터를 병합하는 방법이 필요했고, 개인용 컴퓨터 그룹에는 이 기능과 단일 DBMS와 독립적인 단일 애플리케이션을 작성하는 방법이 필요했습니다. 즉, 두 그룹 모두 데이터에 액세스하는 상호 운용 가능한 방법이 필요했습니다. 열려 있는 데이터베이스 연결이 필요했습니다.