At the heart of Database Solution Stack is a Database Platform. In this case the Database platform is one of the many RDBMS products, such as Oracle, PostgreSQL, MySQL, SQLServer etc. However, in this stack, the DBMS does not necessarily need to be an RDBMS as long as there is an interface to the database that uses SQL. The Boundaries of the Database Platform are not rigid. For example, Microsoft offers a single ODBC interface for many databases, consequently the ODBC driver may or may not be part of the Database Platform. However, in the big picture what is in the Platform and what is not in the platform is a bit pedantic.
The following is a brief description of each component in the DBMS Stack. Note, these components are normative in nature and each DBMS may be slightly different. On the left side of the diagram there is a key that describes which tier each component is generally found in.
Return to Top Figure 2 represents three different scenarios of interactions of Applications or Users to the Database Solution Stack.
In this scenario, the Application accesses the Database Platform using the Database provided API. This solution is very machine resource efficient since the Application uses code that is optimized to access a specific Database (i.e., Oracle, PostgreSQL, MySQL, SQLServer, etc.). However, all of the error recovery and testing for the code and any changes made to the underlying database schema rests on the application.
Note: This scenario makes it more difficult to migrate from one Database Platform to another (sometimes referred to as vendor lock-in). In order to access the Database, the end user must use the Application.
In this scenarios, an Application or the End User can create SQL Statements as strings and pass them through Open Database Connectivity (ODBC) or Java Database Connectivity(JDBC) to access the database. In this scenario, the application or the End User are accessing the Database to invoke Data Definition Language (DDL) functionality for creating, destroying or modifying the database objects defined in the schema (i.e., views, schemas, tables, indexes, etc.).
Note: This Scenario usually relies on a specific Database Driver to access the Database Platform (i.e., a Driver for Oracle, PostgreSQL, MySQL, SQLServer, etc.).
This scenario is very similar to Scenario #2 except this time the Application or End User are using Data Manipulation Language (DML) for inserting data into database tables, retrieving existing data, deleting data from existing tables and modifying existing data.
Note: This Scenario usually relies on a database Database Driver specific to access the Database Platform (i.e., a Driver for Oracle, PostgreSQL, MySQL, SQLServer, etc.).