[
https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166424#comment-13166424
]
Mike Matrigali commented on DERBY-866:
--------------------------------------
In the past I worked on a system that had a 2 database system where one
database had info about the other databases. This caused some
support nightmares, especially when a single database problem could prevent
access to all databases.
With derby it is nice that all databases are a unit unto themselves and that is
what the current architecture is built around. A number of issues
jump to mind if you start assume multiple access on one connection:
o now backup of a database becomes more complicated as it can be out of sync
with the master db
o are databases now not portable across systems, or only if combined with
master db?
o how does this affect replication?
o can the master db be encrypted, and if so how do you get multiple keys from
single connection?
o does collation of the 2 dbs have an effect, now do all dbs in the system need
same collation?
Having a separate db to me seems like even more administration for derby.
Also for derby a database is a pretty heavy weight object in the system. A
good Derby application is one that is embedded and uses a single
database. This is the best case usage of Derby. Of course multiple databases
are allowed and work but often lead to unexpected problems.
Adding a 2nd db in a normal case may double the memory requirements of derby
given the 1 cache per database model currently implemented,
n background threads per active db, ...
> Derby User Management Enhancements
> ----------------------------------
>
> Key: DERBY-866
> URL: https://issues.apache.org/jira/browse/DERBY-866
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.2.1.6
> Reporter: Francois Orsini
> Assignee: Rick Hillegas
> Attachments: Derby_User_Enhancement.html,
> Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java,
> UserManagement.html, UserManagement.html, UserManagement.html,
> derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff,
> dummyCredentials.properties
>
>
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec
> attached to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by
> providing a more intuitive and familiar DDL interface. Currently (in
> 10.1.2.1), Built-In users can be defined at the system and/or database level.
> Users created at the system level can be defined via JVM or/and Derby system
> properties in the derby.properties file. Built-in users created at the
> database level are defined via a call to a Derby system procedure
> (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
> Defining a user at the system level is very convenient and practical during
> the development phase (EOD) of an application - However, the user's password
> is not encrypted and consequently appears in clear in the derby.properties
> file. Hence, for an application going into production, whether it is embedded
> or not, it is preferable to create users at the database level where the
> password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing
> a more intuitive and known interface, it will ease Built-In User management
> at the database level as well as Derby's adoption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
