DEV Community: Roxana-Maria Haidiner

This tool rocks in 2026!

Roxana-Maria Haidiner — Tue, 21 Apr 2026 10:11:33 +0000

VisuaLeaf

Apr 16

VisuaLeaf as a MongoDB Compass Alternative

#mongodb #nosql #javascript #database

Comments 1

5 min read

Best Studio 3T Alternative for MongoDB in 2026

Roxana-Maria Haidiner — Mon, 20 Apr 2026 14:26:26 +0000

If you use MongoDB and want a GUI tool to help you work faster, Studio 3T is often one of the first tools you’ll hear about.

It has a strong reputation for a reason. It brings together a lot of features in one place and can handle everything from querying and aggregations to broader data tasks.

But after a while, you may start asking yourself something else:

What if I want a different way to work with MongoDB?

Not every task needs a heavy workflow.

Sometimes you just want to explore the data, build something quickly, and move on.

That’s often when people start looking for an alternative, not necessarily one with more features, but one with a different perspective: more visual, easier to follow, and more comfortable for everyday work.

That’s where VisuaLeaf takes a different approach.

What Makes a MongoDB Tool Truly Useful?

In the early stages, practically any GUI for MongoDB is sufficient.

You connect, explore collections, run some queries, and it all just works.

But as your data becomes larger, other factors begin to become important:

Feature	Why it matters
Querying experience	You should be able to build queries quickly without friction
Aggregation support	Pipelines can become hard to read and maintain
Schema visibility	Understanding structure is not always obvious in MongoDB
Data exploration	Working with nested documents should stay clear
Charts and dashboards	Visual results help you understand and share insights
Environment management	Switching between databases should be safe and clear
Compare and sync	Tracking differences between environments saves time
Performance	Speed affects how fast you can iterate
Automation	Repetitive tasks shouldn’t be manual every time
Database tools	Indexes, validation, and management matter in real projects

These are the same aspects we looked at when comparing VisuaLeaf with other tools, including its role as a MongoDB Compass Alternative.

The Reason VisuaLeaf Feels Like a Simpler Alternative

VisuaLeaf focuses on something slightly different.

Not only by increasing functionality, but also by streamlining common processes.

Querying Without the Friction

Not everyone works the same way.

Sometimes, you'd rather craft queries by hand. Other times, particularly when the criteria become complicated, writing queries visually comes more quickly.

VisuaLeaf lets you build queries visually, combine conditions, group logic with AND/OR, and still see the generated query behind it.

If you feel like writing queries directly in the MongoDB Shell, that's perfectly okay too.

What is important is being flexible enough to find out which one will work best for you.

Build Aggregation Pipelines More Easily

Aggregations are highly useful, but they can easily become hard to comprehend.

When several stages have been added, you tend to spend more time analyzing the pipeline rather than building it.

VisuaLeaf provides a solution to this problem by enabling you to create pipelines through visualization, where each stage has an output displayed for you.

In this way, you do not have to rely on mental effort in understanding the process.

Work With Your Data Through the MongoDB Shell

Another common way to work with MongoDB is through the shell.

It gives you a direct way to query data, run aggregations, and make updates without leaving the workspace.

That speed is part of the reason many people still like working this way.

But in practice, writing the command is only part of the job.

You also need to understand the results, check whether the data looks right, and sometimes fix small issues on the spot.

That’s where it helps when the shell is not isolated, but connected to a clearer and more visual way of working with your data.

Visualize Structure Without Making Assumptions

Structure in MongoDB isn’t enforced in the way that it is for relational databases.

This implies that knowing the structure of the data takes time, particularly in big projects.

With VisuaLeaf, visualizing collections, fields, and connections within a diagram is easy.

Working With Data Without Getting Lost

Nested documents are good, but they can also be confusing at times as well.

You click on a document, open a field here, move to a collection there, and suddenly you are disoriented.

That’s when VisuaLeaf’s approach to exploring data comes in handy.

The performance issue also becomes important at this stage.

According to a post on Reddit, someone ran tests on multiple MongoDB tools using 50 documents weighing about 10 MB each.

With this dataset, VisuaLeaf showed results in 5 seconds, compared to 9 seconds taken by Studio 3T.

Results like these can vary depending on hardware and configuration, but they show how performance differences start to become noticeable with larger datasets.

From Data to Chart, in One Step

Typically, most software is limited to showing the result of a query.

But VisuaLeaf does not limit itself there.

You are able to take that result and create a chart or dashboard using it without exporting data elsewhere.

This simplifies identifying trends and communicating insights based on the database.

Controlling Your Environment

It’s almost impossible not to work with more than one environment in any project.

Between local, staging, and production environments, there is room for error when changing from one to another.

VisuaLeaf makes sure that you manage your environments effectively.

Comparing Without Manual Analysis

As your dataset changes, you usually have to perform comparisons between sets or environments.

Comparing manually is tedious and unreliable.

With VisuaLeaf, you can compare collections and find out what has been modified, allowing you to know what to update.

Reduced Switching of Tools

Sometimes in work processes, there is a need for switching from one view or one tool to another to get things done.

One queries here, another aggregates there, then another exports somewhere else.

With VisuaLeaf, everything is integrated in one place.

VisuaLeaf Is Designed for Users Who

VisuaLeaf is an ideal solution for those who seek a more visual and intuitive interface for using MongoDB.

You will enjoy working with this MongoDB tool if you:

like constructing queries visually or changing between methods
Use aggregation pipelines and struggle with understanding them
wish to grasp the structure of your database quickly
want to build graphs and dashboards without exporting your data elsewhere
operate in various environments and don’t want to make any mistakes

Conclusion

Studio 3T is an incredibly versatile and robust tool for managing MongoDB.

However, sometimes the sheer amount of functionality can feel too heavy for simple routine operations.

On the other hand, VisuaLeaf gives you a smoother way to handle everyday work, from creating queries and browsing data to understanding the structure more clearly.

If you want to try it out yourself, you can experiment with the demo playground, use the free Community Edition, or try the full version for 14 days.

Different pricing options are available depending on what you need.

Originally published on VisuaLeaf Dev.to

Roxana-Maria Haidiner — Mon, 20 Apr 2026 13:41:26 +0000

VisuaLeaf

Apr 16

VisuaLeaf as a MongoDB Compass Alternative

#mongodb #nosql #javascript #database

Comments 1

5 min read

You should give it a try! VisuaLeaf is a very good MongoDB tool!

Roxana-Maria Haidiner — Thu, 16 Apr 2026 14:49:47 +0000

VisuaLeaf

Apr 6

A Faster Way to Build MongoDB Queries Visually

#mongodb #database #nosql #data

Comments 1

6 min read

Highly recommended!

Roxana-Maria Haidiner — Thu, 16 Apr 2026 14:49:00 +0000

VisuaLeaf

Apr 16

VisuaLeaf as a MongoDB Compass Alternative

#mongodb #nosql #javascript #database

Comments 1

5 min read

[Boost]

Roxana-Maria Haidiner — Thu, 19 Mar 2026 13:22:57 +0000

VisuaLeaf

Mar 18

MongoDB Aggregation Pipeline Explained Step by Step

#mongodb #nosql #database #beginners

Comments

5 min read

[Boost]

Roxana-Maria Haidiner — Tue, 30 Sep 2025 11:20:47 +0000

Roxana-Maria Haidiner

Sep 24 '25

SQL GROUP BY Explained with Examples

#sql #database #mysql #postgres

Comments

4 min read

How to Create Custom Data Types in DbSchema

Roxana-Maria Haidiner — Tue, 30 Sep 2025 11:20:10 +0000

Custom data types in DbSchema’s Logical Design help architects enforce consistent column definitions across large models (e.g., all usernames use the same length everywhere).
Important: these types are design-time abstractions. When you deploy to a real database (e.g., MySQL), DbSchema generates the native DBMS type (such as VARCHAR(150)), not the custom name (UserName).

Open Data Type Settings

Open your project in DbSchema.
Go to Model → Settings → DBMS Specific → Data Types.
In the DBMS selector, choose Logical Design.

Define a Custom Data Type

Click + Add New.
Give the type a clear, descriptive name and set its length:

Examples:

MoneyAmount → DOUBLE, then mapped in Conversion Dictionary to DECIMAL(19,4).
CustomerCode → CHAR(10)
CreatedAt → TIMESTAMP
Click OK to save.

Map the Type for Deployment

Your Logical Design type needs a mapping so that, on deployment, DbSchema generates the correct native DBMS type and precision.

Open Model → Conversion Dictionary.
Click +Data Type, and choose the data type created earlier. (MoneyAmount)
Choose the target DBMS (e.g., MySQL).
Map it to the native type and set the exact precision (e.g., DECIMAL(19,4)).
Save.

Use the Custom Type in Your Model

In the column editor, select your custom type (e.g., MoneyAmount).
When you generate SQL or deploy, DbSchema applies the mapping and emits the native DBMS type.

Example:

The Logical Design types are now mapped, so deployment emits native DBMS types.

What Happens at Deployment?

In the model: you work with logical names like MoneyAmount, CustomerCode, CreatedAt.
On deployment: DbSchema automatically converts each logical type to the mapped native DBMS type (e.g., MoneyAmount → DECIMAL(19,4), CustomerCode → CHAR(10), CreatedAt → TIMESTAMP in MySQL).
No extra steps: the SQL generator uses your Conversion Dictionary; you can preview the exact DDL in Schema Compare / Generate SQL before applying.
In the database: developers will see only the native types (e.g., DECIMAL(19,4), CHAR(10), TIMESTAMP) produced by these mappings.

Troubleshooting

“Length required” prompts in MySQL UI: expected only if you use a DBMS-specific type. For Logical Design types, set the length in the type definition and the exact DBMS length in the Conversion Dictionary.
Custom name not visible in DB: by design. Logical Design names are model-level abstractions. The DB stores native types.

Summary

Create custom types in Logical Design to standardize columns.
Use the Conversion Dictionary to map each type to the exact native DBMS type (MoneyAmount → to DECIMAL(19,4) in MySQL).
On deployment, DbSchema converts Logical Design names to native types, ensuring consistency without leaking modeling abstractions into the database.

Next Step

Want to try this out yourself?
Download DbSchema Free Trial and start designing with custom data types today.

You may also find these guides helpful:

SQL GROUP BY Explained with Examples

Roxana-Maria Haidiner — Wed, 24 Sep 2025 10:43:14 +0000

When you work with databases, you often want summaries instead of just raw rows.

How many orders did each customer make?
What are the total sales per department?
What is the average grade per student?

This is where SQL GROUP BY is useful.
It allows you to group rows that share the same value and then apply functions like COUNT(), SUM(), or AVG().

What You’ll Learn

In this guide, we’ll cover the main GROUP BY functions step by step:

COUNT() - Count number of rows
SUM() - Add up values
AVG() - Calculate averages
HAVING - Filter grouped results
JOIN - Use names instead of IDs
MIN() - Find the smallest value
MAX() - Find the largest value

Example Tables

Let’s use a simple shop database with customers and their orders.

GROUP BY with COUNT

Count how many orders each customer has placed.

SELECT customer_id, COUNT(*) AS order_count
FROM Orders
GROUP BY customer_id;

The Result:

Each customer_id is grouped, and the number of orders is counted.

GROUP BY with SUM

Now, let’s find the total spending of each customer.

SELECT customer_id, SUM(total_amount) AS total_spent
FROM Orders
GROUP BY customer_id;

The Result:

Each customer_id is grouped, and the SUM(total_amount) gives the total money they spent.

Customers Table

To make our reports more readable, let’s also create a Customers table with names for each customer:

customer_id	name
1	Sarah James
2	Mark White
3	Olivia Reed

This table can be joined with Orders using customer_id.
From now on, we’ll use JOINs so results will display names instead of IDs.

GROUP BY with AVG

You can also compute the average order value per customer (showing names via JOIN).

SELECT c.name, AVG(o.total_amount) AS avg_order
FROM Customers c
JOIN Orders o ON c.customer_id = o.customer_id
GROUP BY c.name;

The Result:

Sarah placed two orders worth 50 and 70 → the average is 60.

GROUP BY with HAVING

Sometimes, you want to filter after grouping.
This is where HAVING comes in (not WHERE).

SELECT c.name, SUM(o.total_amount) AS total_spent
FROM Customers c
JOIN Orders o ON c.customer_id = o.customer_id
GROUP BY c.name
HAVING SUM(o.total_amount) > 50;

The Result:

Only customers with spending over 50 are included.

GROUP BY with JOIN

JOIN helps you show labels instead of IDs in grouped results.

SELECT c.name, SUM(o.total_amount) AS total_spent
FROM Customers c
JOIN Orders o ON c.customer_id = o.customer_id
GROUP BY c.name;

The Result:

Use JOIN whenever you want readable names in your reports.

GROUP BY with MIN

Find the smallest order amount per customer (names via JOIN).

SELECT c.name, MIN(o.total_amount) AS min_order
FROM Customers c
JOIN Orders o ON c.customer_id = o.customer_id
GROUP BY c.name;

The Result:

This returns the lowest order amount for each customer.

GROUP BY with MAX

Find the largest order amount per customer (names via JOIN).

SELECT c.name, MAX(o.total_amount) AS max_order
FROM Customers c
JOIN Orders o ON c.customer_id = o.customer_id
GROUP BY c.name;

The Result:

This returns the highest order amount for each customer.

How to Do This Visually in DbSchema

With DbSchema, you don’t need to type SQL from scratch - you can build GROUP BY queries visually in the Query Builder:

Drag your tables (Customers and Orders) into the canvas.
Connect them by their foreign key.
Select the columns you want to display (e.g., name).
Right-click on a numeric column (like total_amount).
Choose Aggregate → SUM, COUNT, AVG, MIN, MAX.

DbSchema automatically adds the GROUP BY for you and shows the generated SQL alongside the diagram.
This makes it much easier to learn SQL because you see both the visual structure and the query code at the same time.

Summary

GROUP BY groups rows with the same value.
Combine with COUNT, SUM, AVG, MIN, MAX to summarize data.
Use HAVING to filter groups after aggregation.
Perfect for totals, averages, and category-based reports.

Learn More

Check out more SQL tutorials here:

Handle Large PostgreSQL Schemas with a GUI Tool

Roxana-Maria Haidiner — Thu, 18 Sep 2025 13:24:51 +0000

When a database is small, everything looks simple.
You open the diagram, see a few tables, and it all makes sense.

At first, a database looks simple.
But as projects grow, so do the tables.
Soon, the schema feels heavy, and even small changes become hard to track.

This is where DbSchema makes the work easier.

1. Organize With Multiple Diagrams

DbSchema lets you split a big schema into smaller diagrams.
For example:

one diagram for Orders & Transactions,
another for Customers & Billing,
one more for HR.

The database is the same, but you look only at the part you need.
This keeps things clear even if the schema has more than 10,000 tables.

2. Connect to Multiple Databases

Most projects don’t have only one database.
You usually work with Dev, Stage, and Prod.

In DbSchema, you can save all connections in the same project and switch between them easily.

Example:

company_dev
company_stage
company_prod

One click, and you are connected to the right place.
No need to remember passwords or JDBC URLs each time.

3. Make Safe Changes

Changing a big schema is stressful.
Instead of running ALTER TABLE directly in production, do it step by step:

Change the table visually in the diagram.
Use Schema Compare to see what changed between the model and the database.
Let DbSchema generate a migration script.

Example migration:

ALTER TABLE company.orders
ADD COLUMN discount NUMERIC(5,2);

Review it, test in Dev, then apply in Prod.
This makes changes predictable and safe.

4. Documentation Everyone Can Read

Large schemas confuse not only developers but also analysts and new colleagues.
DbSchema can generate HTML5 documentation that is:

Complete - includes tables, columns, indexes, and foreign keys
Visual - shows diagrams for better understanding
Interactive - you can click and navigate between tables
Searchable - quickly find a column or table by name
Shareable - publish it on an internal site for the whole team

This way, everyone can explore the schema without asking you each time.

5. Automation Scripts

Large databases often need repetitive tasks:

creating new partitions every month,
checking if important indexes exist,
exporting schema snapshots for backups,
or cleaning up old data.

In DbSchema you can write Automation Scripts in Groovy.
They run directly from the project, so you don’t have to manage external tools.

Example: create next month’s partition automatically


def nextMonth = java.time.LocalDate.now().plusMonths(1)
def start = nextMonth.withDayOfMonth(1)
def end   = start.plusMonths(1)

def sql = """
CREATE TABLE company.transactions_${start.getYear()}_${String.format("%02d", start.getMonthValue())}
PARTITION OF company.transactions
FOR VALUES FROM ('${start}') TO ('${end}');
"""

db.execute(sql)
println "Partition for ${start.getMonth()} ${start.getYear()} created."

With scripts like this, you can:

keep partitions up to date,
schedule routine checks,
or generate data exports with a single click.

Wrap-Up

Large PostgreSQL databases are not easy to handle.
But with DbSchema you can:

split diagrams into smaller views,
work with multiple environments,
apply changes safely,
generate documentation,
and automate routine tasks.

This workflow keeps the database clear and manageable, even when it grows beyond 10,000 tables.

Try it yourself for free with DbSchema. Download here.

Create MySQL ER Diagrams with a Free Design Tool

Roxana-Maria Haidiner — Wed, 27 Aug 2025 14:06:51 +0000

When learning or working with a database, the first step is to see how the tables connect. For MySQL users, the easiest way to do that is with an Entity-Relationship Diagram (ERD).
Instead of reading long SQL scripts, an ER diagram gives you a clear picture of tables, keys, and relationships.

In this guide, I’ll use DbSchema - a free design tool for creating ER diagrams.
It also includes extra features such as HTML5 documentation (for up to 12 tables in the free edition) and Git integration if you try the PRO version.

We’ll look at two main cases:

Reverse engineer an existing MySQL database
Build a new schema visually

What Is an ER Diagram?

An ER diagram is a drawing of your database.
It shows tables (entities), their columns, and how they are connected with primary and foreign keys.

It usually includes:

Table names and their columns
Keys (primary and foreign)
Relationships between tables
Notes, data types, and indexes

Why is this useful?

You can understand the database structure at a glance
It’s easier to explain it to others
Missing or wrong relationships become obvious
New colleagues can get onboarded faster
It helps when documenting or keeping track of changes

If You Already Have a Database

With DbSchema, you don’t need to draw everything by hand.
You can reverse engineer your MySQL database: the tool connects to your schema, reads the tables and foreign keys, and builds a diagram automatically.

Here’s an example of a MySQL schema as an ER diagram:

Want step-by-step instructions?
Check the documentation here

Designing a Schema Visually

Sometimes you don’t have a database yet, you just have an idea.
Instead of starting with CREATE TABLE statements, you can draw it out:

Add new tables with a click
Define columns, data types, and keys using simple forms
Drag lines between tables to create relationships
Rearrange the diagram for clarity

When ready, you can generate the SQL code automatically.

Learn more about designing schemas visually

1. Organize with Multiple Layouts

If your database only has a few tables, one diagram might be enough.
But once you start adding more, things can get messy.

In DbSchema, you can create multiple layouts of the same schema.
For example:

A diagram showing user and authentication tables
A separate one for products and orders
Another one for reporting or logs

All layouts still point to the same schema, but splitting them up keeps them clear and readable.
This is especially useful in large MySQL databases where hundreds of tables exist.

2. Keep It Synchronized

Databases are never static - columns get added, constraints change, and indexes are tuned.

With DbSchema’s Schema Compare feature, you can:

Compare the diagram with the live MySQL database
See exactly what changed (new tables, dropped columns, altered constraints)
Choose whether to update the diagram or apply changes back to the database

This prevents surprises and ensures the diagram and the real database stay in sync.
It’s like a two-way mirror - you can decide which side becomes the source of truth.

3. Use Git for Version Control

Your diagram is saved in a project file (.dbs).
This file can be committed to Git just like code, which means:

You can track every change (e.g., when a column is renamed or a new table is added)
Work in a team without overwriting each other’s changes
Roll back to earlier versions if a design decision didn’t work out
Keep schema design history alongside your application code

This makes database design a collaborative process, not just a one-person job.

4. Share with HTML5 Documentation

Not everyone on your team knows SQL, but they might still need to understand the database.

With DbSchema, you can export your ER diagram as interactive HTML5 documentation:

Opens in any browser (no installation required)
Tables are clickable - you can see all the details from the columns and constraints
Notes and comments are included
Great for sending to managers, analysts, or clients

It’s like publishing your schema online in a clickable, explorable form.

5. Notes and Comments

Sometimes a diagram isn’t enough. People want to know why something is designed in a certain way.

In DbSchema, you can add:

Notes on tables (e.g., "This table stores archived orders older than 2 years")
Notes on relationships (e.g., "One customer can have multiple addresses")
Comments on columns (e.g., "This column is auto-incremented for IDs")

These annotations are not just helpful for your teammates. They also show up in the exported HTML docs, making your schema easier to understand for anyone who reads it.

6. Export Options

Once you’re done, you can export your design in different ways:

Images (PNG, PDF) for reports or presentations
SQL scripts to deploy your schema
Interactive HTML5 for easy sharing with teammates

Benefits of Using DbSchema for MySQL ER Diagrams

Feature	Description
Free Version Available	Create diagrams without a license
Visual Interface	Build schemas without typing SQL
Offline Mode	Work even without a live MySQL connection
Schema Compare	Spot differences between model and database
HTML5 Documentation	Generate clickable docs
Git Integration	Keep track of schema changes in teams
Multi-Database Support	Works with PostgreSQL, Oracle, SQL Server, and more

Conclusion

For MySQL users, ER diagrams are the easiest way to understand and manage a schema.
They make relationships clear, reduce mistakes, and improve teamwork.

Whether you’re documenting an old database or planning a new one, drawing it visually makes the job simpler.

You can try all of this with the free version of DbSchema – a straightforward tool to design, organize, and share MySQL databases.

Download DbSchema here

SQL Joins Explained - INNER, LEFT, RIGHT, FULL

Roxana-Maria Haidiner — Fri, 22 Aug 2025 19:31:45 +0000

When working with databases, your data is often stored in more than one table.
But how can you bring the data together?

This is what SQL JOINs are for.
A JOIN helps you combine rows from two tables based on a related column, usually a column that appears in both.

Types of SQL JOINs

Here are the most common types of JOINs and what they do:

JOIN Type	What it returns
INNER JOIN	Only rows that exist in both tables
LEFT JOIN	All rows from the left table and matching rows from the right table
RIGHT JOIN	All rows from the right table and matching rows from the left table
FULL JOIN	All rows from both tables

What Is a SQL JOIN?

Let’s say you have:

One table with a list of employees
Another table with a list of departments

Each employee works in a department. If we want to know who works where, we need to connect the tables using a JOIN.

The JOIN compares values in both tables and brings the matching rows together.

Example Tables

Table: Employees

employee_id	name	department_id
1	Sarah James	10
2	Mark White	20
3	Olivia Reed	NULL

Table: Departments

department_id	department_name
10	Engineering
20	Sales
30	HR

INNER JOIN

Returns only employees who are assigned to a department.

SELECT name, department_name
FROM Employees
INNER JOIN Departments
ON Employees.department_id = Departments.department_id;

➝

name	department_name
Sarah James	Engineering
Mark White	Sales

Employees without a department, and departments with no employees, are not shown.

LEFT JOIN

Returns all employees, even if they don’t belong to any department.

SELECT name, department_name
FROM Employees
LEFT JOIN Departments
ON Employees.department_id = Departments.department_id;

➝

name	department_name
Sarah James	Engineering
Mark White	Sales
Olivia Reed	NULL

You get all employees.
If they have no department, the result will show NULL.

RIGHT JOIN

Returns all departments, even if no employee is assigned to them.

SELECT name, department_name
FROM Employees
RIGHT JOIN Departments
ON Employees.department_id = Departments.department_id;

➝

name	department_name
Sarah James	Engineering
Mark White	Sales
NULL	HR

You get all departments.
If no one works there, the result shows NULL for the name.

FULL JOIN

Returns all employees and all departments.
If they match, they are shown together.
If not, one side will be NULL.

SELECT name, department_name
FROM Employees
FULL JOIN Departments
ON Employees.department_id = Departments.department_id;

➝

name	department_name
Sarah James	Engineering
Mark White	Sales
Olivia Reed	NULL
NULL	HR

This gives you the full picture.

Summary

Use INNER JOIN when you want only matching data
Use LEFT JOIN when you want all rows from the first table
Use RIGHT JOIN when you want all rows from the second table
Use FULL JOIN when you want everything, matched or not

How to Do This Visually in DbSchema

You can use DbSchema to build JOINs without writing any SQL.

Drag the two tables into the canvas
Connect them by dragging from one column to the other, to create a foreign key

Open the Query Builder and cascade related tables

Right-click the line to select the JOIN type
Choose the columns you want to display

Run the query and see the results

This is a great way to learn how JOINs work, because DbSchema auto-generates SQL code for you!

Note: The JOIN types shown in the menu depend on the database you are connected to.
Some databases (like SQLite) do not support RIGHT JOIN or FULL JOIN.
In these cases, DbSchema will only show the join types supported by your database.

Learn More

If you're learning SQL and want more examples, visit our full SQL Tutorial here:
[https://dbschema.com/blog/tutorials/]