There is no standard for interfacing with non-relational systems. Each system presents different designs and capabilities for application development teams. The maturity of the API can have major implications for the time and cost required to develop and maintain the application and database.
There are a number of popular programming languages, and each provides different paradigms for working with data and services. Idiomatic drivers are created by development teams that are experts in the given language and that know how programmers prefer to work within that language. This approach can also beneOt from its ability to leverage speciOc features in a programming language that might provide efficiencies for accessing and processing data.
For programmers, idiomatic drivers are easier to learn and use, and they reduce the onboarding time for teams to begin working with the underlying database. For example, idiomatic drivers provide direct interfaces to set and get documents or fields within documents. With other types of interfaces it may be necessary to retrieve and parse entire documents and navigate to specific values in order to set or get a field.
Thrift or RESTful APIs
Some systems provide RESTful interfaces. This approach has the appeal of simplicity and familiarity, but it relies on the inherent latencies associated with HTTP. It also shifts the burden of building an interface to the developers; and this interface is likely to be inconsistent with the rest of their programming interfaces. Similarly, some systems provide a Thrift interface, a very low level paradigm that shifts the burden to developers to develop more abstract interfaces within their applications.
Some non-relational databases have attempted to add a SQL-like access layer to the database, in the hope this will reduce the learning curve for those developers and DBAs already skilled in SQL. It is important to evaluate these implementations before serious development begins, considering the following:
- Most of these implementations fall a long way short compared to the power and expressivity of SQL, and will demand SQL users learn a feature-limited dialect of the language.
- Most support queries only, with no support for write operations. Therefore developers will still need to learn the database’s native query language.
- SQL-based BI, reporting, and ETL tools will not be compatible with a custom SQL implementation.
- While some of the syntax may be familiar to SQL developers, data modeling will not be. Trying to impose a relational model on any non-relational database will have disastrous consequences for performance and application maintenance.
Visualization and Reporting
Many companies conduct data visualization, analytics, and reporting using SQL-based BI platforms that do not natively integrate with NoSQL technologies. To address this, organizations turn to OBDC drivers that provide industry-standard connectivity between their NoSQL databases and 3rd party analytics tools. For example, the MongoDB Connector for BI allows analysts, data scientists, and business users to seamlessly visualize semi-structured and unstructured data anaged in MongoDB, alongside traditional data from their SQL databases, using the most popular BI tools.
- The maturity and functionality of APIs vary significantly across non-relational products.
- MongoDB’s idiomatic drivers minimize onboarding time for new developers and simplify application development.
- Not all SQL is created equal. Carefully evaluate the SQL-like APIs offered by non-relational databases to they can meet the needs of your application and developers