top of page
worker_2_software.png

Database Table Connector

worker_2_software.png

In many applications, there is a need to connect to a database to read/write data, and developers have 2 options:

 

Option 1 - Native Libraries: All databases support their own native libraries for communication, e.g., Oracle supports OCI library, and developers can directly load an appropriate API to communicate with a database. The drawback however, is that each company designs and implements the API per their own requirements, architecture, supported data types, etc. As a result, the API interfaces are very different, it takes a lot of efforts to study them, their application is not straightforward and intuitive, and it becomes an unattractive option when there is a need to support multiple databases. 

Option 2 - Generic Libraries: Several companies developed a common interface to communicate with different databases, e.g., ODBC from Microsoft, and switching between databases is reduced to just setting an appropriate communication parameters. However, complexity of the interface and usability still remains an issue. Besides, typically such systems are less efficient than the native libraries when it comes to the response time and memory allocation. 

In our library, we overcame all the difficulties developers typically face while communicating with data sources. 
- Connecting and running SELECT, INSERT, DELETE, UPDATE and all types of complex nested queries require just few lines of code. 
- Provides an environment for dynamic binding of values before executing the queries, which is a much faster option.
- The same interface for all databases and effortless switching between them.

- Communication through native libraries as well as through ODBC.

- It is practically as fast and memory efficient as the underlying API, e.g., OCI in case of Oracle, ODBC, etc.

- The library can employ multiple threads that is very useful when reading/writing huge data sets or dealing with different sets simultaneously

In our library, the database communication is simply reduced to the following steps:

Step 1 - Specifying Logging Configuration File (Optional): If the configuration file or sections in the file are different from defaults, they have to be specified in the very beginning of the program.

Step 2 - Setting Data Source Credentials: Initialize the tool and set up connection credentials, e.g., URL, user ID, password, SQL, etc.

Step 3 - Executing: Running appropriate functions to read/write data or execute SQL statements.

bottom of page