ODBC 的用途：完整實用指南

如果你每天都要處理數據，那麼遲早會遇到令人頭痛的縮寫詞 ODBC，而且不只一個人會想知道它到底是做什麼用的。 ODBC 是那種默默無聞的標準之一，它使得截然不同的應用程式和資料庫能夠相互理解。這樣，每次更換服務提供者時，就無需重寫所有程式碼。

儘管如今已有更新的技術，但 ODBC 在許多環境中仍然至關重要：從 辦公室工具，例如 Excel 或 Access從 Tableau 或 Qlik Sense 等 BI 解決方案到仍然處理關鍵數據的傳統企業應用程序，我們將仔細研究它是什麼、它的用途、它的內部工作原理以及如何在實踐中配置它。

什麼是ODBC？它究竟有什麼用途？

ODBC 代表 開放資料庫連接這是一個接口，用於 程序設計 開放標準應用程式（API）旨在統一存取資料庫，而無需考慮底層資料庫管理系統（DBMS）。

這個想法很簡單，但卻非常有效： 你只需編寫一次應用程序，使用 ODBC 呼叫和標準 SQL 語句，然後讓驅動程式處理與每個資料庫的「原生語言」進行互動。這樣，您就可以從 Access 切換到 SQL Server，從 MySQL 切換到 O​​racle，甚至切換到簡單的文字文件，而無需重寫所有資料存取邏輯。

ODBC 充當客戶端應用程式和資料庫管理系統之間的橋樑。 該應用程式使用 ODBC API 發送 SQL 請求，驅動程式將這些請求轉換為特定 DBMS 可以理解的格式。 並將結果傳回給應用程式。因此，該程式無需了解每個資料庫的專有特性。

該標準由 SQL Access Group 在 20 世紀 90 年代初制定， 微軟是世界的主要驅動力。 Windows第一個驅動程式是 SIMBA.DLL（1992 年與 Simba 共同開發）。如今，Windows 系統中已有相應的實作。 UNIX的, LinuxOS/2 和 macOS 都支援 ODBC，使其成為廣泛使用的跨平台解決方案。

ODBC 的歷史與演變

ODBC 的發展歷程與微軟環境下的資料存取演進以及開放標準密切相關。 ODBC 依賴 The Open Group 和 ISO/IEC 制定的 SQL 呼叫級介面 (CLI) 規格。它定義了呼叫級資料庫存取 API 應該如何實作。

ODBC 的第一個版本於 1999 年發布。 1992年9月（ODBC 1.0）此後，ODBC 陸續推出了具有新功能和性能改進的版本：ODBC 2.0（約 1994 年）、2.5、ODBC 3.0（約 1995 年，IBM 和 Intersolv 做出了重要貢獻）、ODBC 3.5（1997 年）以及約 2009 年發布的重要貢獻）、ODBC 3.5（1997 年）以及約 2009 年。 窗戶7.

同時，微軟試圖超越 ODBC，創建其他資料存取模型： OLE DB、ADO、DAO、RDS、噴射發動機 後來又出現了 ADO.NET。最初的計劃是讓 OLE DB 和 ADO 等技術取代 ODBC，成為資料存取的主要標準，尤其是在物件導向的場景以及資料來源不一定是 SQL 的情況下。

然而，市場現實卻並非如此： ODBC 仍然是存取 SQL 資料來源的事實標準。Oracle 和 IBM 等供應商的大力支援、其多平台特性以及龐大的現有應用生態系統，確保了它在許多專案中仍然是首選方案。

如今，當我們談到存取 SQL 資料庫時，仍然完全有效的兩大主要標準是： ODBC 和 JDBC其他模型，例如 OLE DB 或某些 ADO 層，已經失去了很大相關性，在許多情況下都被棄用，或者僅僅為了與舊應用程式相容而保留下來。

ODBC架構：其內部運作原理

要充分了解 ODBC 的用途，了解其架構很有幫助。 ODBC 在應用程式和資料庫管理系統之間引入了一個中間層。 這樣一來，應用程式就不會直接與資料庫通信，而是與標準 API 通訊。

一般來說，流程如下： 該應用程式會向 ODBC 驅動程式管理員發送 SQL 請求，ODBC 驅動程式管理員會尋找並載入目標資料庫的相應驅動程式。控制器將請求轉換為資料庫管理系統的原生協議，資料庫處理查詢，並將結果沿原路傳回給應用程式。

這種架構不僅實現了供應商獨立性，還能解決以下問題： 版本相容性、錯誤處理、資料類型轉換和 SQL 語法差異等主題 引擎之間的互動。一切都盡可能地對應用程式的程式設計師透明。

在 Windows 系統中，ODBC 是下列元件的一部分： Windows 開放服務架構 (WOSA)一種開放的服務架構，其中桌面應用程式可以連接到不同的運算環境，而無需為每個平台重新編寫程式碼。

ODBC的主要組成部分

ODBC 在 Microsoft 系統和許多平台上的典型實作遵循一種通用結構。 我們可以區分出幾個關鍵組成部分，它們協同工作以實現這種開放連接。.

一方面是 ODBC APISQL API 是一組呼叫函數、錯誤代碼和標準 SQL 約定，應用程式使用它來處理資料。此 API 定義瞭如何開啟連線、傳送查詢、檢索結果以及管理事務，而無需依賴特定的資料庫管理系統 (DBMS)。

另一個基本要素是 ODBC 驅動程式管理員 （在 Windows 系統中，是 Odbc32.dll 函式庫）。這個動態連結庫位於應用程式和特定驅動程式之間，以透明的方式加載，負責查找、加載和下載相應的驅動程序，以及管理版本和相容性。

然後我們發現了 ODBC 資料庫驅動程式每個資料庫管理系統（SQL Server、Oracle、MySQL、DB2 等）都有自己的驅動程序，通常以一個或多個 DLL 檔案的形式存在。這些驅動程式負責將 ODBC API 呼叫轉換為原生資料庫管理系統調用，處理特定的 SQL 語法、內部資料類型以及各個引擎的特性。

在某些環境下， ODBC 遊標庫 （例如 Windows 上的 Odbccr32.dll），它位於驅動程式管理員和驅動程式本身之間，用於管理結果集的捲動、進階遊標和其他資料導覽操作。

最後，我們有 ODBC 資料來源管理員一個圖形化或配置工具，可讓您定義和修改系統的資料來源（DSN）。您可以在此處決定使用哪個驅動程式、連接到哪個伺服器或檔案以及使用哪些身份驗證參數。

支援 ODBC 的應用程式和資料來源類型

任何能夠使用標準 API 開啟連線的軟體都可以被視為 支援 ODBC 的應用程式在現實世界中，這包括從辦公室軟體到分析工具和客製化業務應用程式的一切。

一些典型的例子有： Microsoft Excel中, Microsoft AccessPower BI、Tableau、Crystal Reports、Qlik Sense 以及眾多需要讀取或寫入不同系統中資料的管理應用程式（ERP、CRM、垂直解決方案等）。

為了讓應用程式能夠知道如何存取數據，使用了 ODBC 資料來源，它將資料來源與…結合起來。 所需的連線資訊：伺服器位置、資料庫名稱、使用者名稱、密碼和驅動程式特定選項此配置通常封裝在 DSN（資料來源名稱）或連接字串中。

在 Windows 系統中，ODBC 資料來源透過以下方式進行管理： ODBC 資料來源管理員您可以在那裡配置不同類型的 DSN，每種 DSN 都有自己的範圍和模式。 存儲這為在單一電腦或共享伺服器上部署應用程式提供了相當大的靈活性。

一個重要的細節是 資料存取類別和庫可以與任何具有可用 ODBC 驅動程式的資料來源配合使用。這包括關聯式資料庫、ISAM 引擎、Excel 電子表格、文字文件，甚至是以表格格式公開資料並透過 SQL 存取的即時資料來源。

ODBC 中的 DSN 類型和連接字串

當我們談到設定 ODBC 時，幾乎總是會提到 DSN 的概念。 DSN（資料來源名稱）包含開啟連線所需的所有資料。：使用哪個驅動程序，它指向哪個伺服器，哪個特定資料庫，憑證和其他選項。

在 Windows 系統中，DSN 分為三種類型。 用戶 DSN 它們將設定儲存在註冊表中，且僅針對當前使用者配置文件，因此只有該帳戶才能使用這些設定。當您想要按使用者隔離連接並防止其他使用者查看設定時，它們非常有用。

很多 系統DSN 這些設定也儲存在登錄中，但對電腦的所有使用者（包括系統服務）可見。對於伺服器或共用安裝，建議使用此選項，因為它們允許不同的帳戶使用相同的連線配置，而不會造成重複。

另一方面，還有 文件 DSN這些 DSN 將連接資訊儲存在副檔名為 .dsn 的文字檔案中，而不是儲存在註冊表中。這些 DSN 通常更靈活，因為它們可以複製到安裝了相同驅動程式的其他計算機，或放置在共用伺服器上以集中配置。

除了可共享的DSN之外，還有不可共享的存檔DSN。 它們駐留在同一台電腦上，並充當指向機器 DSN 的指針。這樣一來，您就可以利用現有的資料來源，而無需公開整個配置。

在許多語言（例如 Visual Basic 或 C#）中，您也可以選擇不定義 DSN 並傳遞一個 直接連接到 ODBC 驅動程式管理員的字串該字串包含與 DSN 相同的參數，但嵌入在程式碼中，這簡化了應用程式分發，但代價是失去了一些管理靈活性。

Windows 系統中的實用 ODBC 配置

在 Windows 系統中開始使用 ODBC 的典型流程遵循幾個清晰的步驟。首先， 您需要為目標資料庫管理系統安裝對應的 ODBC 驅動程式。有時它會隨 Windows 系統一起提供（例如，SQL Server 或 Access 的通用驅動程式），有時它由資料庫製造商或專業的第三方提供。

驅動程式安裝完成後，工具即可開啟。 “資料來源（ODBC）” 從控制台 → 管理工具。此實用程式將開啟 ODBC 資料來源管理器，您可以在其中根據安全性和共用需求選擇建立使用者、系統或檔案 DSN。

下一步是點擊“新增”，選擇相應的控制器（例如， “SQL Server”、“Microsoft Access Driver (*.mdb, *.accdb)”等等）並依照精靈操作：通常會要求您輸入來源的描述性名稱、它指向的伺服器或文件，在許多情況下還會要求輸入憑證或驗證模式。

在 64 位元環境下，必須注意架構：64 位元 Windows 安裝包含 ODBC 管理器 (Odbcad32.exe) 有兩個版本64 位元版本位於 %systemdrive%\Windows\System32，32 位元版本位於 %systemdrive%\Windows\SysWOW64。32 位元驅動程式只會出現在 32 位元驅動程式管理員中，64 位元驅動程式也是如此。

諸如 Access、Qlik Sense 或 Tableau 之類的應用程式 連接到外部資料庫有些軟體也提供自己的連接器，封裝了授權的 ODBC 驅動程式（例如 Qlik 的 ODBC 連接器套件），讓使用者甚至不必通過 Windows 資料來源管理器。

將 ODBC 與 Access、Qlik Sense 或 Tableau 等工具搭配使用

在 Microsoft Access 中，ODBC 用於 連結或導入數據 從 Access 沒有內建原生驅動程式的外部來源例如 SQL Server、Oracle 或第三方資料庫。流程與通常情況相同：Access 連線至 ODBC 驅動程式管理器，後者使用特定的驅動程式（例如 SQL Server 驅動程式），然後開啟與資料庫的連線。

使用 Qlik Sense，我們有兩種選擇。一方面， 使用 Qlik ODBC 連接器包中包含的連接器這些方法提供了最佳化的「Qlik-xxx」驅動程序，可以直接從Qlik介面進行配置，無需使用Windows ODBC管理器。或者，您也可以手動為資料庫管理系統（DBMS）安裝ODBC驅動程序，並建立使用者或系統資料序號（DSN），Qlik Sense將在建立資料連線時使用該DSN。

在 Qlik Sense Desktop 中，DSN 清單可以顯示 Windows 中建立的 DSN 和內部軟體包驅動程式（以「Qlik-」為前綴標識）。 這些內部驅動程式不能用於建立通用 ODBC 連線。 它們並非 Qlik 生態系統的一部分；它們專為產品本身附帶的資料庫連接器而設計。

以 Tableau 為例，它提供了一系列針對特定資料庫（Snowflake、SQL Server、Oracle 等）精心調校的原生連接器，但： 此外，也提供通用的ODBC連接器。 當您需要存取沒有特定連接器的資料庫時，此連接器非常有用。它利用 ODBC 標準與幾乎任何實作了 SQL 和 ODBC API 的資料來源進行通訊。

Tableau 透過 ODBC 連線時，會執行一個發現階段，在此階段， 查詢 ODBC 驅動程序，了解它支援哪些功能。標量和聚合函數、日期處理、子查詢功能、可用的 JOIN 類型、臨時表的建立等等。根據驅動程式的聲明，它將連接分類為完全功能、有輕微限制、有重大限製或直接不可用。

ODBC 和 JDBC 之間的關係

在資料存取生態系統中，ODBC 在 Java 世界中有著天然的對應物： JDBC（Java資料庫連線）兩者都追求同一個目標：為應用程式提供一個使用 SQL 連接到不同資料庫的標準，但採用的方法要根據各自的環境進行調整。

雖然 ODBC 的主要用途是 用 C、C++ 或其他支援其 API 的語言編寫的應用程式 JDBC 在 Windows 系統中被廣泛使用（儘管在其他平台上也有應用），它是 Java 生態系統的一部分，由於它在虛擬機器上運行，因此從定義上來說就是跨平台的。

JDBC架構分為以下幾部分： API 層其中包括開發人員使用的 Java 介面和類，以及 驅動層 它實現了這些介面並與實際資料庫通訊。 JDBC 驅動程式有四種類型：類型 1（ODBC 橋接器）、類型 2（原生/部分 API）、類型 3（網路協定）和類型 4（100% Java「精簡」驅動程式）。

舊控制器 JDBC-ODBC橋接器（類型1）允許Java應用程式存取可透過ODBC存取的資料庫。它作為一種過渡方案很有用，但是… El Temppo 由於效能和複雜性問題，這種方法不被提倡，最終在現代 Java 版本中消失了。

在 JDBC 中，資料庫連線是透過 URL 建構的，格式類似： jdbc::/// 更多可選屬性。例如：jdbc:mysql://localhost:3306/mydatabase。 Java DriverManager 會根據此 URL 找到合適的驅動程式並開啟連接，這與 ODBC 管理器在 ODBC 環境中選擇驅動程式的方式類似。

就實際差異而言， ODBC 和 JDBC 的主要差異在於它們所針對的語言和生態系統。ODBC 與 Windows 和原生應用程式深度集成，而 JDBC 則與 Java 環境無縫集成，支援 Java 特有的資料類型，並提供諸如 ResultSet 之類的實用工具來處理結果。在某些情況下，Type 4 JDBC 驅動程式可以透過消除中間層來提供極具競爭力的效能。

最終，選擇哪一個取決於應用程式的技術： Java 應用程式通常使用 JDBC；原生應用程式則使用 ODBC。總之，兩者都體現了相同的理念，即對資料庫提供者進行標準化和與供應商無關的存取。

ODBC 仍然是 關鍵件 在資料存取的難題中：它允許各種程式透過通用 API 連接到截然不同的資料庫，透過其驅動程式隱藏了每個引擎的差異，與 Access、Qlik Sense 或 Tableau 等各種工具相容，並與 Java 世界中的 JDBC 等其他標準共存，因此，如果您了解 ODBC 的工作原理，您就成功了一半，可以順利使用幾乎任何現代資料庫環境。