CTE, subquery, and view are all database programming constructs that allow you to create reusable and flexible queries.
SUBQUERY
A subquery is an embedded query within another query, typically in the WHERE clause of the main query. A subquery can be used to filter, sort or aggregate data, and nested to create complex queries.
A view is a virtual table where you can program logic. They are simple to write, and they keep the processing at the server, but the results are generated at run time and can be slow if you’re handling a lot of data.
CTE
A Common Table Expression (CTE) is a temporary name assigned to a query that can be referenced multiple times in a larger query. CTEs are useful for creating recursive queries or queries that require complex logic. If you have a query that runs very inefficiently, converting it to use a CTE will often bring processing time way down.
Over the next few weeks we will look at some basic approaches to writing queries with some simple examples.
Email today for help with your data optimization questions.
Writing subqueries is an important skill to develop if you want to work effectively with your database resources.
EXAMPLES
One of the first subqueries you will probably write will be within the where statement to limit results.
If you need to display the value used to filter you can use a subquery within your select statement. Here we calculate the field ‘avgamt’ using a scalar subquery, i.e. it will return the same value on every line.
A correlated subquery is one of your more complex query structures. Here we have a subquery within our select statement that uses a value returned by the main query to the customer master table to count the number of invoices. The field ‘total_trx’
Understanding how to write effective subqueries is the first step in automating custom processes in your database. Managing transaction lists in your system, automated archiving and monthly sales reporting become much easier when writing subqueries in SQL become second nature.
If you’re interested in learning more about scalar subqueries, multiple row subqueries, and correlated subqueries check out this page.
To speak to an expert about your reporting headaches email [email protected].
I’m a big believer in the power of reporting to help guide change management in large organizations. One of the biggest changes any organization can take on is the implementation of a new MRP or ERP solution. Sadly project teams usually don’t remain involved past a few support days once a new system is live. Reporting is usually lumped into these days with limited success. This leaves the organization at a disadvantage, and leads to lower ROI on what is usually a large investment. The project team don’t stay to ensure the data, people and processes have evolved to work with the new system. Management considers a project successful when there are no major disruptions and costs remained low, a low bar indeed.
MAXIMIZING ROI
Installing a system, setting up master data, and turning on the lights are only the first steps in any implementation. How are people adjusting? What does the team find frustrating and limiting? Do they have the training they need? Do they understand what the new data is telling them? These conversations are critical for maximizing your return on investment.
This becomes an iterative process to help the team understand what is possible outside the confines of your old system. This requires patience to limit business disruptions and errors, and allow a team to grow.
An implementation that maximizes ROI empowers employees to take ownership of the quality of the data they work with. Business intelligence customized to your environment should help employees see how their actions can improve the customer experience and the bottom line every day.
There’s been a lot of talk about star schemas and snowflake schemas at SQLbits this week. If you’re not familiar with the terms they relate to two divergent approaches to data that are important to consider when moving to a cloud based reporting solution.
WHAT IS IT?
A star schema is a simple and denormalized structure where the fact table is at the center and surrounded by dimension tables. It looks like a star because of its shape.
On the other hand, a snowflake schema is a more normalized structure that breaks down dimension tables into sub-dimension tables. This makes the schema look like a snowflake, hence the name. This allows for better scalability and more complex relationships between tables. However, it can also make querying data more complicated and slower due to the increased number of joins required.
STAR vs SNOWFLAKE
The star schema is simpler and faster for querying data, but less flexible, while the snowflake schema is more flexible and scalable, but can be more complex and slower for querying data. Both of these approaches have a purposes and a strength and in my experience a combination of both approaches is often best.
Snowflake is the standard in older systems, or in highly controlled transactional systems. It used to be taboo to list a value redundantly in two places. Star schemas are more likely to become out of sync, because you have to update values in multiple locations. Over time; however, it’s clear that multiple joins in ad hoc querying is inefficient, especially when we’re reporting on a large amount of data, and particularly in tables that are actively processing transactions.
MODERN REPORTING FOR LEGACY SYSTEMS
Preparing your data for consumption by converting legacy snowflake schema tables to a simplified star schema set of tables that users can query without locking or blocking transactional tables makes the most of both design approaches. Talk to one of our data experts to discuss how your data factory or warehouse resources can be simplified and turned into useful, meaningful business intelligence using modern storage solutions along with an intelligent and efficient approach to design that will optimize scanning and extraction.
You can’t make the most of the modern tools available by simply importing your legacy data into a data lake without some tweaks with the help of a reporting expert, and not just a . Get the advice of someone who understands the pitfalls. Keep your queries efficient to keep your costs low, and watch your data turn into meaningful action.
Email today for help with your data optimization questions.
Azure Synapse Analytics or Synapse is a cloud-based analytics service that combines big data and data warehouse technologies into a single unified service. It allows you to pull data from wide range of data sources, not just Microsoft stack, but Google Cloud too.
Synapse is designed to be flexible and scalable enough to handle data of any size and complexity. Its distributed databases, big data processing engines, and data workflows can handle complex data scenarios to derive insights quickly.
DATA MANAGEMENT
When you import and analyze data from external sources you can use Synapse as a source for your PowerBI reports. But if your reporting data is large or complex you might use a SQL managed instance database or a datalake to store the results of your import and analysis.
Synapse can be used with SQL Server or other data warehouse solutions to create an optimized hybrid approach.
SCHEDULED TRIGGERS
Many organizations prefer that users don’t touch and can’t modify data when moved from one system to another. To improve governance, security and reliability, a hands-off approach is often best.
Use pipeline triggers to schedule your imports in Synapse to extract, transform, and load your data, and give your team up-to-date business insights.
