In the history of database technology, the first revolution came about when the electronic computer emerged; the second was a result of the creation of the relational database. This article briefly explores the idea of a possible third revolution.
Considerable developments have occurred in recent years with respect to database technology. Non-relational database systems such as Cassandra, MongoDB, Spark, and Hadoop are all part of an evolving part of the small business data infrastructure of close to all Fortune 500 companies.
Certainly, it is perfectly within reason to argue that implementing these emerging technologies is ill-advised, that the transactional SQL relational database and the relational model offers a superior solution, and that the market will eventually realize this and go back to the long-standing relational model. However, a number of experts believe this to be unlikely.
Downsides to Non-Relational Databases
All the same, those against non-relational systems would not be wrong to assert that the current databases are all prone to the following downsides:
- Inconsistency –A majority of non-relational databases are unable to perform transactions with multiple objects. A number of unfavorable outcomes may result from potential unpredictability and inconsistency even in transactions with a single object. Nondeterministic behaviors, lost updates, and phantom reads may occur.
- Regression to the navigational model –The new stock of databases has brought back issues that relational systems had eliminated, i.e., physical and logical representations of data being coupled in an undesirably tight format.
- Numerous compromises – There are many specialized database solutions in the market, some of which sufficiently fit the requirements of an organization’s application. However, it is often the case that the application is forced to choose from a set of database architectures that are not quite right.
- Lack of suitability for business intelligence – Database systems such as MongoDB, Cassandra, and HBase among others offer more functions to a database programmer than to you, the small business owner. They may therefore be isolated from the wider business because of the lack of a suitable layer of SQL.
Convergence of Databases
According to remote DBA experts such as remotedba.com, it is not outside the realm of possibility to find a database offering that “has it all”. For instance, there is no architectural basis for a database system being unable to provide a tunable consistency model that offers a consistency model on one end and reliable multi-record transactions on another end.
In the same way, it is possible to bring together the features of a document store and a relational model initially by using the current trend toward including JSON data types in your company’s relational tables.
Conclusion
Ideally, the architecture of your company’s database should support multiple storage formats, processing paradigms, languages, and data models within one system. Your team of remote DBA experts should resolve application requirements that affect particular database features.
These resolutions should be pluggable options or configuration features within your system, rather than choices between fundamentally different architectures for databases. Your database should also support a relational yet extensible schema as well as a tunable consistency model.
Related Posts
