SQL Saturdays are free, one-day training events and are held in cities worldwide throughout the year. Hundreds of SQL Server professionals attend to hear presentations by those highly regarded in the field and to learn best practices associated with their trade. Since speaking sessions range from beginner to advanced levels, professionals of all levels are encouraged to attend. There are also a variety of networking opportunities available such as pre-conference sessions in select cities and after parties.
As the modern database continues to grow, its inherent feature set expands alongside it. More solutions allow remote DBAs and internal teams alike to solve business problems tied to cutting costs and improving efficiencies. However, with these solutions comes increased complexity surrounding database administration, and it falls on the shoulders of DBAs to understand and leverage the industry’s evolving technologies.
RDX is pleased to announce the launch of our MongoDB NoSQL database service offering. NoSQL architectures have been gaining an increasing amount of attention from the IT community. Many organizations now consider NoSQL offerings to be standard infrastructure choices for new database-driven application implementations.
When we compare relational and NoSQL Systems, one of the critical analyses we have to perform is data access mechanisms. As we’ll learn over the next few articles of this series on data access, the SQL language used by relational database management systems is much more feature rich and powerful than its NoSQL counterpart. This statement isn’t intended to sway readers to relational systems, it is just the author’s evaluation of both systems’ access languages.
Designing, building and maintaining highly available (HA) architectures is the key to providing end users with 24x7 access to mission-critical applications. From the financial services sector to higher education, organizations require their databases be online and readily accessible. When these critical applications become unresponsive or performance is hindered, the resulting downtime can have extreme consequences. With the potential for legal penalties, bad press, loss of customer goodwill and other repercussions looming, DBAs must constantly focus on ensuring their systems are highly available, quickly recoverable and protected from natural or human-induced disasters.
As the modern database continues to evolve and take on a more strategic role in business, the complexities associated with managing these environments grows as well. For database administrators, this changing landscape forces them to continuously adapt and grow alongside the database engine to properly design, support, and secure an enterprise’s critical data stores. Their in-depth knowledge of the infrastructures so crucial to operations make DBAs an integral part of not only day-to-day functions, but business decisions aimed at reducing operation costs, improving margins, and more.
Welcome back to part 2 of MDX Code Development for Beginners. In part 1, we looked directly at the basic SELECT FROM clause in T-SQL and converted it to the SELECT ON COLUMNS ON ROWS FROM which is the equivalent in MDX. In part 2 we will be looking into the different BASIC filters that can be introduce into the SELECT statement in comparison to T-SQL “WHERE” clauses.
One of the main benefits of an AlwaysOn Availability Group is being able to read off of the secondary replicas. However, Read-Only Routing is not automatically configured when you first build your AlwaysOn Availability Group. To fully utilize an AlwaysOn Availability Group and take full advantage of having read-only connections connect to your secondary database, you will have to configure Read-Only Routing.
In this next article of the series, we’ll continue our comparison of relational and NoSQL schemas. Part one of the article used MongoDB as our subject for comparison. This second article uses Cassandra as the representative for NoSQL architectures.
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.