In this next article of the series, we’ll analyze the different strategies that the Relational and NoSQL database vendors follow for schema design. This will be a two-part article with the first using MongoDB as our subject for comparison followed by a second discussion using Cassandra as the NoSQL product representative.
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.
I recently was tasked with a project to consolidate several SQL 2005 database servers down to one existing SQL 2012 database cluster. While working on this project, I found that one of the database servers needing to be consolidated was utilizing SQL Server Reporting Services (SSRS), but the existing cluster was not configured for Reporting Services. SSRS is not cluster aware, so adding this feature to an existing clustered instance is not straightforward and will likely lead to a rule check failure on the “Existing clustered or cluster-prepared instance” rule. Well today is your lucky day, as I’m going to show you exactly how to get beyond this error and on your way to making your SSRS cluster aware!
IT professionals can attest – the world in which we operate changes rapidly. For database administrators, it can be a blessing and a curse all at once. With technology continually advancing, database vendors are forced to implement new features and functionalities in order to stay competitive. Each release contains dozens of advancements and new additions that can potentially be leveraged to improve the database environments they manage. Part of what makes being a DBA so rewarding is the ability to evaluate and understand these inherent features, choosing to implement those that pose the greatest benefit to each application.
I use the title "Data Administrator" loosely to describe the functions these IT specialists provide. I use it for clarity only in this article because I think it oversimplifies the important role they play. Data Administrators are more aptly titled "Protectors of the Organization's Critical Data Assets." From establishing proper naming conventions to implementing corporate-wide data management policies, the services they provide range the spectrum.
In the world of big data, we are always trying to lighten our storage footprint. Luckily for us, Microsoft has introduced data compression as an enterprise-level feature to aid in conserving storage. Not only are you able to save on storage, you will also dramatically reduce the number of I/O requests. Knowing that the disk subsystem is the slowest part of our environments, these fewer I/O requests needed for retrieving data will lead to an increase in performance.
Recently, I’ve been asked by a couple of prospective clients how RDX’s service delivery model is the correct choice for their company and their specific environment. It hasn’t been a question that I’ve honestly pondered before until lately; all I really thought about prior to getting asked this question is that we aim to strive to do the best for all of the clients that we work for and with, and that we do a great job at it.
As technology advances and organizations grow, cloud computing and hosting are becoming a part of our organizations more and more. One of the new offerings by Microsoft is their Azure platform with one of the services being the Azure SQL database. While working with the Microsoft Azure platform during a recent project, I discovered the ability to name your own Azure SQL server in the Azure Preview Portal, a feature that isn’t available in the Azure Management Portal. I'd like to share this feature with you.
As RDX gears up for an exciting 2016 full of user groups, trade shows, and regional events, there are a handful of upcoming SQL Saturdays at which you can find experts from RDX. SQL Saturdays are free, one-day training events and are held in cities worldwide throughout the year. SQL Server professionals of all levels are encouraged to attend as speaking sessions range from beginner to advanced. There are also a variety of networking opportunities available such as pre-conference sessions in select cities and after parties.
As business intelligence continues to make a big splash into businesses, SSAS and cubes are becoming a requirement. One of the limitations that DBAs face every day is converting from reading and writing T-SQL statements to being able to read and write MDX with ease. In order help others who may have been thrown into the role, I am going to start a series on MDX code writing. This blog post will be geared towards translating a simple T-SQL SELECT statement into an MDX SELECT statement.