Commented by: Ivan (patuljak)

this must be priority.

why?

because if I must have for each year data in single database then my application is complicated and can't using the same time data for more more year.can but then must special database for all data.

with more scemas, for each year keep data in special scema and one for all.

all schema have the same structure.

then with application can be easy the use of data.

Commented by: fabianobonin (fabianobonin)

I think schemas are a must-have for enterprise applications which deal with large number of tables.

You can use schemas to organize tables in groups, to improve security, to deal with different sets of data (years, for example) in different shemas and keep the same table names, to simplify objects naming, etc, etc, etc...

I really don´t understand why Firebird still don´t have it, as almost all serious competitors already have it, and specially with JDBC adding schemas to the standard specification (i presume schemas are also part of SQL standards), it makes Firebird less portable to replace other databases in applications developed from beginning to use schemas.

Commented by: fabianobonin (fabianobonin)

No words about schemas/namespaces in Firebird 3.0?
I would like to see it at least as a reminder in 3.0 release notes.

Commented by: @dyemanov

They are not planned for FB 3.0.

It's been close to two decades and this feature has not been addressed.
Is there a technical reason not to implement this?
Recursive name spaces/schema as found in oracle would not only make management of firebird code easier, it allows for more complex projects that currently are difficult to implement without.

Is this simply a matter of no one wanting to do the code or not knowing the specification?

The benefits of schema are as follows
(1) easy separation of objects within a separate namespace
(2) ability to have default namespaces so that objects can be referenced and used, based upon the current user/connection/transaction - ie like a path statement in windows/linux
(3) use of synonyms - effectively a type of view but without some of the issues.
(4) ability to add the feature to create links to other servers/databases/schemas without the need to go through stored procedures via the newly created tree structure
(5) ease of use of porting from other databases thanks to supporting a feature that many other databases have.

The reason is simple: it is a very big task with many questions to be decided.

While schemas are defined in the SQL specification, items (3) and (4) from your list are non-standard, AFAIU. I would think twice before considering them for implementation.

Item (3) is an ineffective workaround for problems created by item (2) so if you implement (2) you must somehow solve unpredictable and hard to diagnose problems with queries returning wrong data or "table not found" errors.

Item (4) has no relation to schemas at all except multilevel object name syntax.