As the strategic role of databases continues to advance within organizations, the task of finding and retaining experienced DBAs has become increasingly difficult. DBAs are seen as the “Go-To” specialist for internal IT teams due to their knowledge across a wide spectrum of information technology and processes. In an increasingly complex environment, database administrators design, support, and safeguard a company’s critical data stores, ultimately allowing organizations to make better business decisions.
In order to compare relational and NoSQL architectures, we must begin with their historical roots. The focus of this article will be on the business drivers that led to each architecture being readily adopted by the IT community, as opposed to an in-depth historical essay on each model’s technical genesis. Describing why the products became popular provides us with the opportunity to perform a high-level analysis of the relational and NoSQL models and architectures.
The intent of this series of articles is to perform a technical comparison of relational and NoSQL database offerings. Unlike many articles that you’ll read, it is not intended to sell readers on a particular vendor offering, nor will it favor one architecture over another.
Oftentimes, I am presented with queries from a client with a myriad of joins that have no table aliases. In order to improve performance, I often will have to create temporary tables from pieces of the query, and sometimes they need to be created manually as opposed to performing a SELECT INTO. Having to search through all of the tables through the GUI manually to determine the proper information on the columns can be quite a pain and a waste of time. In an effort to better utilize my time, I created a simple query that will return where the column resides as well as everything you need to know about the column and more.
After years of having their own internal processes, technology, and best practices, it’s understandable some organizations have trepidation when it comes to DBA outsourcing. Especially for companies with internal teams, concerns arise regarding how external support will fit in with their current DBAs and the methods in which they operate. At RDX, our customer on-boarding process is focused on easing these concerns and building a solid foundation to provide a high level of remote database services based around the needs and challenges of your infrastructure.