firebird icon indicating copy to clipboard operation
firebird copied to clipboard

Add support for SQL Schemas [CORE738]

Open firebird-automations opened this issue 20 years ago • 13 comments

Submitted by: carniz (carniz)

Is duplicated by CORE2592 Is duplicated by CORE3393

Votes: 21

SFID: 993727#⁠ Submitted By: carniz

I'd like to see support for SQL Schemas (see http://sql-info.de/postgresql/schemas.html)

Oracle has it, PostgreSQL has it, Mimer has it, don't know about others.

firebird-automations avatar Jul 19 '04 03:07 firebird-automations

Modified by: @pcisar

Workflow: jira [ 10762 ] => Firebird [ 15165 ]

firebird-automations avatar Jan 28 '08 15:01 firebird-automations

Modified by: @dyemanov

Link: This issue is duplicated by CORE2592 [ CORE2592 ]

firebird-automations avatar Aug 14 '09 05:08 firebird-automations

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.

firebird-automations avatar Oct 22 '09 16:10 firebird-automations

Modified by: @dyemanov

Link: This issue is duplicated by CORE3393 [ CORE3393 ]

firebird-automations avatar Mar 17 '11 07:03 firebird-automations

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.

firebird-automations avatar Dec 06 '11 21:12 firebird-automations

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.

firebird-automations avatar Jul 28 '12 08:07 firebird-automations

Commented by: @dyemanov

They are not planned for FB 3.0.

firebird-automations avatar Jul 28 '12 08:07 firebird-automations

Modified by: Sean Leyne (seanleyne)

description: SFID: 993727#⁠ Submitted By: carniz

I'd like to see support for SQL Schemas (see eg http://sql-info.de/postgresql/schemas.html)

Oracle has it, PostgreSQL has it, Mimer has it, don't know about others.

=>

SFID: 993727#⁠ Submitted By: carniz

I'd like to see support for SQL Schemas (see http://sql-info.de/postgresql/schemas.html)

Oracle has it, PostgreSQL has it, Mimer has it, don't know about others.

firebird-automations avatar Apr 25 '14 05:04 firebird-automations

Modified by: Sean Leyne (seanleyne)

summary: SQL Schemas => Add support for SQL Schemas

firebird-automations avatar Apr 25 '14 20:04 firebird-automations

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.

DaltonCalford avatar May 13 '23 15:05 DaltonCalford

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

aafemt avatar May 13 '23 15:05 aafemt

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.

dyemanov avatar May 14 '23 05:05 dyemanov

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.

aafemt avatar May 14 '23 10:05 aafemt