Relational Database Query Optimization

This is a continuation of my posts on relational databases, started here. Previous posts on this theme, “Data Modeling“, “Let’s Talk About Database Schema“, “The Exasperating Topic of Database Indexes“, and “The Keys & Relationships of Relational Databases“.

Query optimization refers to the process of selecting the most efficient way to execute a SQL query. The goal is to retrieve the requested data as quickly and efficiently as possible, making the best use of system resources. Given that there can be multiple strategies to retrieve the same set of data, the optimizer’s role is to choose the best one based on factors like data distribution, statistics, and available resources.

Query Optimizers

Continue reading “Relational Database Query Optimization”

Let’s Talk About Database Schema

Previous post on this theme, “Designing a Relational Database – Data Modeling“.

Seriously, let’s talk about schema in the abstract and the literal implemented schema in some of the most popular databases.

What is a schema?

In general, outside the specific realm of relational databases, a “schema” is a conceptual framework or blueprint that defines the structure, relationships, and constraints of data or information. It provides a way to describe and organize data in a structured manner. This concept of schema is not unique to databases; for instance, in GraphQL, a schema defines the types, queries, mutations, and the relationships between them, outlining the set of possible operations that can be executed against the API and the shape of the data that is returned.

The Oddity of Different Implementations in Databases

From the viewpoint of someone familiar with the general idea of a schema, it can indeed seem unusual that databases like SQL Server, Oracle, MariaDB/MySQL, and PostgreSQL each interpret and implement schemas in slightly (or sometimes, vastly) different ways. While the core idea behind a schema as a structured container or namespace for database objects remains somewhat consistent, the exact nature, utility, and behavior of schemas vary across these systems.

Why Each Database Implements Schema Differently

  1. Historical and Legacy Reasons: Many database systems started their journey decades ago. Over time, as they evolved, they built upon their existing architectures, leading to variations in features like schema. For instance, the idea of a schema in Oracle being closely tied to a user comes from Oracle’s early architectural decisions.
  2. Design Philosophy and Target Audience: Some databases were designed with specific audiences in mind. Oracle, for example, was designed for enterprise-level applications, which might have influenced their user-centric schema design. On the other hand, MySQL, initially envisioned for web applications, treats schemas synonymously with databases, perhaps for simplicity.
  3. Standards Compliance vs. Practicality: While there are ANSI SQL standards that databases might strive to adhere to, there’s also a balance to strike between standards compliance and offering features that are deemed more practical or beneficial for the database’s primary users. For instance, PostgreSQL, which aims to be highly standards-compliant, also introduces advanced features not in the standard when it sees fit.
  4. Competitive Differentiation: Sometimes, databases introduce or tweak features to differentiate themselves in the market. These variations can sometimes lead to differences in core concepts like schemas.
  5. Community and Governance Influence: Open-source databases like PostgreSQL and MariaDB can be influenced by their developer communities. Different communities might prioritize certain features or philosophies, leading to divergent implementations.
  6. Flexibility and Extensibility Concerns: Databases might implement schemas in ways they believe are more flexible or extensible for future changes. This might lead them to adopt non-standard or unique approaches.

In essence, the varying implementation of schemas in different databases is a result of a blend of historical decisions, design philosophies, target audiences, and practical considerations. It’s a testament to the evolving nature of database systems and the diverse needs they aim to address.

Looking @ Relational Database Schema

Continue reading “Let’s Talk About Database Schema”

Designing a Relational Database – Data Modeling

Designing a system against a relational database involves several key elements that ensure data integrity, efficient query performance, and maintainability. Here’s a summarized overview of these design elements: This article I am going to strive to cover the first of numerous key elements of designing a system against a relational database. I will eventually cover the following topics, but this post will specifically be based on the first topic data modeling:

Data Modeling

The general idea with data modeling for a relational database (and for other types of databases) is to build the database in a way that caters to your specific usage needs. This involves multiple layered tasks. Each of the sections below I’ll define simple the task, then elaborate on characteristics of that particular task.

Continue reading “Designing a Relational Database – Data Modeling”


This is a getting started guide for MariaDB SkySQL. Let’s start with two prerequisites definitions:

  1. MariaDB – MariaDB is an open-source relational database management system (RDBMS) that is a fork of MySQL, another popular open-source database system. It was created by the original developers of MySQL after concerns arose about the acquisition of MySQL by Oracle Corporation in 2010. MariaDB is designed to be a drop-in replacement for MySQL, which means that many applications and tools developed for MySQL can also work seamlessly with MariaDB without requiring significant changes. It retains much of the same syntax, APIs, and commands as MySQL, making the transition relatively straightforward for users.
  2. MariaDB SkySQL – MariaDB SkySQL is a cloud-native Database as a Service (DBaaS) offering provided by MariaDB Corporation, the company behind the development of the MariaDB open-source database system. SkySQL is designed to simplify database management, deployment, and scaling by providing a fully managed and highly available MariaDB database solution in the cloud.

Some key features of MariaDB include:

  1. High Performance: MariaDB incorporates optimizations and improvements to enhance query execution speed and overall performance.
  2. Storage Engines: MariaDB supports multiple storage engines, including the popular InnoDB and Aria engines. Each engine has its own characteristics and performance attributes, allowing users to choose the one that best fits their requirements.
  3. Security: MariaDB includes various security enhancements, such as data encryption at rest and in transit, improved authentication methods, and better access control mechanisms.
  4. Open Source: MariaDB is fully open source, which means its source code is available for anyone to inspect, modify, and contribute to.
  5. Community and Development: MariaDB has a vibrant and active community of developers and contributors who work on its continued development and improvement.
  6. Compatibility: As mentioned earlier, MariaDB aims for compatibility with MySQL, allowing applications developed for MySQL to work with minimal changes.
  7. Extensions: MariaDB introduces some features not present in MySQL, such as the Aria storage engine, thread pooling, and more advanced geographic information system (GIS) functionality.
  8. Replication and Clustering: Like MySQL, MariaDB supports various replication methods and clustering solutions for high availability and fault tolerance.
  9. Plugins: MariaDB offers a plugin architecture that allows users to add custom functionality and features to the database system.

To elaborate further on the specifics of MariaDB SkySQL, here are some of the features of the DBAAS (DataBase As A Service):

  1. Managed Service: SkySQL takes care of database administration tasks such as provisioning, backup, monitoring, maintenance, and security updates. This allows users to focus more on their applications and less on managing the underlying database infrastructure.
  2. High Availability: SkySQL offers built-in high availability configurations that ensure database uptime and data durability. This includes automatic failover and replication setups.
  3. Scalability: SkySQL supports both vertical and horizontal scaling. Vertical scaling involves adjusting the resources of a single database instance, while horizontal scaling involves distributing data across multiple nodes for improved performance and capacity.
  4. Security: Security features such as encryption at rest and in transit, role-based access control, and network security protocols are integrated to help protect sensitive data.
  5. Multi-Cloud Support: SkySQL is designed to work across various cloud providers, enabling users to choose the cloud environment that best suits their needs. It supports popular cloud platforms like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
  6. Compatibility: SkySQL maintains compatibility with the MariaDB database, which means applications developed for MariaDB can run seamlessly on SkySQL with minimal modifications.
  7. Global Distributed Architecture: SkySQL offers the capability to deploy databases across multiple geographic regions for improved performance and data availability across different parts of the world.
  8. Managed Upgrades: Regular updates and improvements to the MariaDB database engine are managed by the SkySQL service, ensuring that your databases remain up to date without manual intervention.
  9. Pay-as-You-Go: SkySQL’s pricing model is typically based on usage, allowing users to pay for the resources they consume. This can be cost-effective for businesses as it eliminates the need to invest in and maintain dedicated database infrastructure.
Continue reading “MariaDB & SkySQL DBAAS”