ODBC is the abbreviation of “Open Database Connectivity”. It is a standard that specifies how an application using data from database will interact with a database. ODBC is a standard adopted by the IT industry. The standard specifies the commands that can be issued irrespective of the actual database product. How database products (both RDBMS and non relational ones) respond to requests for finding data, modifying or editing them as also how the requests are to be made vary from product to product. Open Database Connectivity strives to make the requests from applications the same irrespective of which database product serves the data. Databases, on their part, interpret these requests and process data according to their own internal processes (requests and command syntax) to respond the same way irrespective of its make.
With this kind of standardization, it is possible for any application to write front end that issues the standard requests to databases. This is the front end part of the ODBC standardization/ specification. This makes it possible for any application to issue data requests that will be recognized any ODBC compliant database. In fact, the application with this kind of Open Database Connectivity compliant front end would be transparent to what database is going to supply the data requested by it. The database could be any ODBC compliant product, working on any computer on the network and on any operating environment. Like the application front end needs special code to transform the requests from the application to standardized requests, the database needs a driver that will recognize the Open Database Connectivity requests and transform them to commands in specific syntax and sequence required by the given database. These drivers are, obviously, specific to a database product of a particular company. This driver is installed with the client application, the database could be anywhere on the network. The chain of modules for getting ODBC compliant work done is as follows:
Database serves up data requested and changed made by application up the same chain. After this ODBC standards have been complied with creating an application with a database, removing the parts and replacing them with another is a simple affair. As long as the standard connections through the front end and the Open Database Connectivity driver are maintained, substituting the database with another or an application with another is as simple as changing the tire in a car. It does not matter if the tire is from Bridgestone, Michelin or something else as long as the dimensions (specs of database) of the tire are similar. One could write monolithic application that has the database as a part of it. The application communicates with the database in its native protocol. This will be alright if there was no need for any change during the lifetime of the application. If there is a change needed, you will need to re-write the application all over again. The flexibility arising from ODBC standardization will be lost entirely.