Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for SQL Schemas [CORE738] #1113

Open
firebird-automations opened this issue Jul 19, 2004 · 13 comments
Open

Add support for SQL Schemas [CORE738] #1113

firebird-automations opened this issue Jul 19, 2004 · 13 comments

Comments

@firebird-automations
Copy link
Collaborator

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
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE2592 [ CORE2592 ]

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is duplicated by CORE3393 [ CORE3393 ]

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Commented by: @dyemanov

They are not planned for FB 3.0.

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

summary: SQL Schemas => Add support for SQL Schemas

@DaltonCalford
Copy link

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.

@aafemt
Copy link
Contributor

aafemt commented May 13, 2023

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

@dyemanov
Copy link
Member

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.

@aafemt
Copy link
Contributor

aafemt commented May 14, 2023

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.

@asfernandes asfernandes self-assigned this Feb 4, 2024
@FirebirdSQL FirebirdSQL deleted a comment from balger Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants