[Feature]: Add optional namespaces for tables within a database

[sambenne]

Before You Submit

• I searched existing GitHub issues and did not find an existing feature request for this enhancement.
• I have removed or redacted any sensitive information.

Component

Server

Feature Summary

Add support for an optional namespace or logical grouping level for tables within a MySQL database.

This would allow related tables to be grouped without requiring:

• repeated table-name prefixes;
• generic polymorphic tables; or
• separate databases.

---

Problem Statement

Large application databases can contain hundreds of tables covering many distinct areas of functionality.

A common convention is to prefix related tables so that they remain grouped and avoid collisions with similarly named tables elsewhere in the application.

For example:

query_logs
query_log_notes
query_log_messages

customers
customer_notes
customer_addresses

Prefixes such as query_log_ and customer_ often exist primarily to provide context and organisation.

Using a single generic table such as notes is not always an appropriate alternative. Although two entities may both be described as "notes", they can have completely different:

• columns;
• indexes;
• constraints;
• relationships;
• retention policies; and
• lifecycle requirements.

Combining unrelated concepts into a polymorphic table solely to avoid similarly named tables can make the relational model less clear.

As schemas grow, repeated prefixes also make table names increasingly verbose while the database remains a flat list of tables.

MySQL currently provides organisation at the following levels:

database
└── table

There is no optional logical grouping level for related tables within a database.

---

Requested Feature

Add support for an optional namespace, group, or similar logical container for tables within a MySQL database.

A schema such as:

query_logs
query_log_notes
query_log_messages

customers
customer_notes
customer_addresses

could conceptually be represented as:

query_logs
query_logs/
├── notes
└── messages

customers
customers/
├── notes
└── addresses

Or, using identifier-style notation:

query_logs
query_logs.notes
query_logs.messages

customers
customers.notes
customers.addresses

The root-level query_logs and customers objects would remain normal tables.

A namespace could have the same name as a root-level table. The namespace would simply provide an organisational context for related tables.

For example:

query_logs
query_logs.notes
query_logs.messages

These would represent three distinct tables.

No implied relationships

Namespaces should not introduce any relational behaviour.

For example, a table named:

query_logs.notes

would not automatically:

• belong to query_logs;
• inherit from query_logs;
• receive a foreign key to query_logs; or
• otherwise depend on query_logs.

The namespace would simply form part of the table's identity.

Backwards compatibility

Existing tables would effectively have no namespace.

For example:

namespace: NULL
table:     query_logs

This would allow existing databases and existing table references to continue working unchanged.

Identifier syntax

The exact SQL syntax and identifier-resolution rules could be determined separately.

In particular, MySQL's existing:

database.table

notation would need to be considered when deciding how namespace-relative identifiers should be expressed.

Fully qualified identifiers could conceptually include all three levels:

database.namespace.table

The primary request is for the organisational capability, rather than a specific required SQL syntax.

---

Use Cases

Application developers

Large applications frequently organise application code into modules or namespaces while the database remains a flat collection of tables.

For example, application models might naturally be organised as:

QueryLog
QueryLog\Note
QueryLog\Message

Customer
Customer\Note
Customer\Address

A corresponding database structure could be:

query_logs
query_logs.notes
query_logs.messages

customers
customers.notes
customers.addresses

This would make the relationship between application structure and database structure clearer without requiring names such as:

QueryLogNote
query_log_notes

DBAs and database developers

Namespaces could make large schemas easier to browse and understand by grouping related tables together while keeping them within a single database.

Database administration tools could optionally display namespaces as logical groups or folders instead of presenting hundreds of tables in one flat list.

For example:

Tables
├── customers
│   ├── addresses
│   └── notes
├── orders
│   ├── events
│   └── notes
└── query_logs
    ├── messages
    └── notes

Reusable entity names

Names such as the following occur in many unrelated areas of an application:

notes
messages
addresses
settings
history
attachments
events

Namespaces would allow these names to be reused while retaining completely independent schemas and relational designs.

For example:

customers.notes
orders.notes
query_logs.notes

Each notes table could have entirely different columns, indexes, constraints, and relationships.

---

Current Workarounds

1. Encode the namespace into the table name

The most common workaround is:

query_log_notes
query_log_messages
customer_notes
customer_addresses

This works and is widely used, but it:

• produces increasingly verbose table names;
• duplicates contextual information in every identifier; and
• still leaves the database as a flat collection of tables.

2. Generic polymorphic tables

Another workaround is a generic table such as:

notes

with fields similar to:

object_type
object_id

This can be appropriate when the underlying entities genuinely share the same structure and behaviour.

However, it is not appropriate when similarly named entities have different:

• schemas;
• constraints;
• indexing requirements;
• relationships; or
• lifecycle behaviour.

Namespaces would allow independently modelled relational tables without forcing them into a common structure.

3. Separate databases

Related areas can also be split into separate MySQL databases:

customers.notes
orders.notes
query_logs.notes

using MySQL's existing database.table identifier structure.

This provides an additional naming level, but it also introduces additional complexity around:

• deployments;
• permissions;
• migrations;
• tooling;
• administration; and
• database ownership.

For many applications, the data still logically belongs within a single application database.

---

Additional Context

This feature is intended primarily as an organisational and naming feature, rather than a new relational concept.

A possible metadata representation could conceptually be equivalent to each table having an optional namespace:

Namespace	Table
NULL	query_logs
query_logs	notes
query_logs	messages
NULL	customers
customers	notes
customers	addresses

The internal implementation would not need to follow this representation. It is included only to illustrate the intended behaviour.

Desirable properties

• Namespaces are optional.
• Existing tables continue to work unchanged.
• Root-level tables and namespaces may share the same name.
• Namespaces do not imply relationships between tables.
• Tables in different namespaces may use the same local table name.
• Namespaces are limited to one organisational level rather than being recursively nested.
• Namespace information is exposed through metadata such as INFORMATION_SCHEMA.
• Database tooling can enumerate and group tables by namespace.

For example:

query_logs
query_logs.notes
customers.notes

should represent three distinct tables.

This would allow applications to preserve strongly typed, purpose-specific relational tables while providing better organisation and naming for large database schemas.

---

Potential Impact Areas

• SQL syntax or statements
• Performance
• Security
• Replication
• Observability
• Administration
• Compatibility
• Developer APIs
• Documentation
• Other