Implementing ER Tables in DBLE Without child_table Configuration
This article explains a second method for implementing ER tables in DBLE that avoids configuring child_table, demonstrates how tables with identical split columns, distribution nodes, and algorithms can act as ER tables, and shows practical JOIN and EXPLAIN query examples.
In the previous episode we introduced the first way to implement ER tables; the second method can be realized without configuring child_table .
As shown in the figure, there are six tables (tableA‑F) that have split columns, distribution nodes, and split algorithms set.
Dividing them into three groups, we see that the tables whose last column’s group number is 1 share exactly the same distribution nodes and split algorithms; these three tables can be mutually treated as ER tables because the split column will be used as the ON condition in future JOIN operations. As long as the distribution rules are identical, they can serve as ER tables for each other.
Other tables either have the same algorithm but opposite distribution nodes, or have different algorithms; such tables cannot be used as ER tables, making the configuration more flexible without needing child_table , though it introduces some limitations.
Now let’s look at a specific configuration.
These two tables are identical except for their names, so they have an ER relationship.
Next, we demonstrate the operation.
First we view the table data, then the JOIN result, which is correct.
We also examine the EXPLAIN query plan, which also returns four rows. The first two rows represent the overall JOIN dispatched to MySQL, the third row shows the merge, and the fourth row performs shuffle_field , which is the forwarding step we are now familiar with.
If we modify the association, the process returns to the ordinary flow: data collection, middleware processing, and cross‑database query.
When you are unsure how DBLE internally handles SQL, you can use EXPLAIN. For example, if you expect to use ER tables or Global tables, you can check by enabling MySQL’s general log or by inspecting DBLE’s query plan, which displays how SQL is dispatched and where.
This is another way to implement ER tables.
Besides ER tables and Global tables, DBLE also offers other features such as correlated sub‑queries. Some logic can be pushed down to MySQL nodes, but DBLE syntax does not support it; we will cover that next time.
That concludes today’s introduction.
The article has been optimized for readability without affecting learning; the text and video aim to stay consistent.
DBLE and related project code addresses:
https://github.com/actiontech/dble
https://github.com/actiontech/dble-docs-cn
https://github.com/actiontech/dble-test-suite
Course inquiries:
WeChat public account "ActiontechOSS" of the "Ai Ke Sheng Open Source Community"
Official technical group (669663113)
Click “Read Original” to get the latest courses in the "DBLE Quick Start" series!
Aikesheng Open Source Community
The Aikesheng Open Source Community provides stable, enterprise‑grade MySQL open‑source tools and services, releases a premium open‑source component each year (1024), and continuously operates and maintains them.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.