Grouping query results into buckets of equal size is a common requirement for database developers and database administrators (DBAs) alike. Examples include:
- customers whose last names begin with A - L and M-Z
- products prices that are between 1 - 10 dollars, 11 - 20 dollars, 21 - 20 dollars, etc...
- quarterly sales, i.e., from Jan - Mar, Apr - Jun, Jul- Sep, Oct - Dec
Standard SQL is well suited to this task. By combining the power of the CASE statement with the GROUP BY clause, data can be broken up into whatever range we deem necessary to best interpret our data. In today's blog, we'll compose a couple of range queries in Navicat Premium's excellent Query Editor.
Output parameters are a feature of stored procedures that is seldom used, which is a shame because they are an excellent option for returning scalar data to the user. In today's blog, we'll learn some uses for Output Parameters and how to use them in your stored procedures.
Theres an adage for user privileges that you should assign a user the least amount of privileges that he or she requires to perform their job function(s) and no more. That is why MySQL offers such a fine-grained access control system. While not the easiest system to grasp, once a DBA does, he or she tends to agree that it really is quite effective. In today's blog, we'll learn how to prevent a user from listing databases in MySQL.
Fetching rows that have a particular value, but not others, is a fairly common task in database development and administration. It sounds like a walk in the park, but limiting the results to those rows that possess one value to the exclusion of others is trickier than it sounds. The reason is, while it's trivial to filter out values using the != not equals or NOT IN comparison operators, these only hide values rather than tell us whether or not an entity possesses these other values. The good news is that there's an easy way to do it. Read on to find out how!
A short time ago we were introduced the incredibly useful and versatile Case Statement. In that blog, we employed the Case Statement as most DBAs and developers do, in the SELECT clause. Another way to use the Case Statement is within the WHERE clause. There, it may be utilized to alter the data fetched by a query based on a condition. Within that context, the Case Statement is ideally suited to both static queries, as well as dynamic ones, such as those that you would find inside a stored procedure. In today's blog, we'll create a SELECT query in Navicat Premium that returns rows based on the values of another field.
- 2025 (1)
- June (1)
- The Rise of Embedded AI/ML Capabilities in Modern Databases
- Immutable Databases: the Evolution of Data Integrity?
- Seamless Information Access Through Data Virtualization and Federation
- Database DevOps Integration: Bridging the Gap Between Development and Operations
- Navicat Sponsors SQLBits 2025 – Supporting the Future of Data Platforms
- May (1)
- Edge Databases: Empowering Distributed Computing Environments
- The Rise of Low-Code/No-Code Database Interfaces: Democratizing Data Management
- Data Vault 2.0: A Modern Approach to Enterprise Data Modeling
- Streaming-First Architectures: Revolutionizing Real-Time Data Processing
- Navicat Proudly Sponsors PGConf.de 2025 as Silver Sponsor (Two Free Tickets Up for Grabs!)
- April (1)
- March (1)
- February (1)
- January (1)
- June (1)
- 2024 (1)
- 2023 (1)
- 2022 (1)
- 2021 (1)
- 2020 (1)
- 2019 (1)
- 2018 (1)
- 2017 (1)