Michael,

<< If you like to allow several catalog files within a folder, then treat
them as schemas, as Ole suggested. >>

Having a catalog file that contained the definitions of the schemas
contained in the catalog, would be more in line with how these things are
defined in the SQL framework.

Ole Willy Tuv

Ole,

> << If you like to allow several catalog files within a folder, then treat
> them as schemas, as Ole suggested. >>
> Having a catalog file that contained the definitions of the schemas
> contained in the catalog, would be more in line with how these things are
> defined in the SQL framework.
Yeah, that makes sense. Having several catalog files was really a
weird suggestion on my part, I take it back


Michael

Michael,

<< 1. Binding database to a catalog file *not stored inside the database*.
Yes all information ideally should be protected, but the actual data should
not depend on configuration for its integrity unless they are stored
together and in this case configuration should actually be regarded as data.
The whole idea of having to categories: config and data signifies exactly
that - one is more important then the other. I don't want to go into details
on how painful it could be to support this thing. Rather then arguing I
think we should ask users. I see that a few have already experienced that
first hand here. >>

The configuration information *is* data.  It's basically a system-wide
catalog file for objects that are not database-specific, i.e.
users/roles/jobs.

<< 2. Binding catalog file name to the database name. People tend to use
multiple databases, so one must be able to refer to the same database by
different names. Also people tend to name databases the same ('Data' being
used in 90% cases). Imagine two independent applications sharing EDB server
with both databases designed and shipped to use catalog file named 'data'.
>>

Forget about this.  You're getting hung up on the database catalog naming
scheme when the problem is simply that EDB allowed you to do something that
it shouldn't allow you to do.  Also, two independent applications won't use
the same configuration file or server.  They will need independent instances
of both, just like with DBISAM today.

<< If you like to allow several catalog files within a folder, then treat
them as schemas, as Ole suggested. Although, I must agree, that this feature
won't be appreciated or understood by most users It's important to be
able to escape to having single default schema. >>

Again, the design is not to allow several catalog files within a given
folder.  It's just a bug that you're allowed to do so.

<< Regarding roles\users\jobs - they should be defined on server, no doubt
about it. However, I'd store their relationship to objects in the database.
You don't need to clone any information for that purpose. When you create a
new database, you grant permissions to users and only this information is
stored in the database. IOW,
Catalog stores
  Users
    Mike
  Roles
    User
I.e. it stores the results of grant <role> to <user> >>

This is the way it is done.  What you're missing, however, is that EDB uses
internal IDs (integers) for objects to avoid constantly having to use names
and to allow for situations where objects don't actually have proper names.
These IDs for roles and users must match those in the configuration file
(and the database catalog ID must match that in the configuration file).
Mixing database catalogs with configuration files that they don't belong to
can cause all sorts of problems with users being authenticated with
permissions that they don't actually have, etc.

<< You can store user names a literals in the database and you don't need to
store passwords.  This way you don't have to bind the database so tight to
the config and it will solve the first issue. >>

I'll have to look into this further because there is most likely a lot more
here than meets the eye.  If it's just a matter of using user/role names
instead of IDs, then it might be possible.  Might.

<< Also, there was criticism of storing users and roles on server level: if
you deploy two applications and they both define role power_user the name
will collide and the user will gain access to another database. >>

Again, two applications would not use the same configuration file and/or
server instance.

<< The fact that someone has 1000 identical databases (possibly requires
refactoring?) doesn't really justify intentionally wrong design.>>

These are processing services.  They maintain multiple databases to reduce
exposure to downtime for multiple customers.  If one customer's database is
having trouble, for whatever reason, then other customers are not affected.
It is a legitimate design, despite the fact that you don't agree with it.

<< I'd give it more thought. Maybe it's possible to define shared roles so
that all databases could use them or store them on server and then instruct
developers to prefix roles they use in database with uri
(contextsoft_com_poweruser). >>

No, definitely not going to happen.

<< I've never had to deal with such cases, so it's hard to tell how
important they are. These are mostly handled by DBAs for large databases,
but if EDB is aiming at the market of zero config databases, then it could
become a problem (or the security will not be used - which is more likely if
we read poll results on your web site . >>

Michael, that's really not particularly funny.  I spent a lot of time
(months) on the user security aspect of EDB to make it both easy for
existing DBISAM users to migrate to and to make it something that is usable
for all users.  Just because you don't agree with the design does not
warrant a comment to the effect that "no one is going to use it".

<< Server-side session authenticate users when user logs in - both work in
the same way as with dbisam. The local session does not authenticate users,
it takes whatever user name you provide. For local access, application must
implement its own authentication scheme, whatever it could be. It actually
could be regarded as a great feature: I for once would appreciate such
opportunity immensely - I know that many database
apps don't really use database level security because it's hard to
coordinate with application-level security, which basically doubles it
anyway. >>

I'm sorry, but I'm not going to toss out the local user security.  It simply
isn't going to happen, period.  It's as intertwined into the product as the
C/S security.  In fact, the two are exactly the same thing.

<<  Are you saying that EDB supports file sharing mode? >>

Yes, just like DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Thanks, you did clarify it for me. See, I'm easy, once it's explained
I will no longer argue The most important thing affecting design
decision I guess was that EDB is not designed as a shared server.
This is an important assumption and it does affect the design and
I didn't realize that. The other thing I didn't realize is that you
still have file sharing mode. These are two things that change the
perspective - I was just under wrong impression regarding design
goals, sorry.

Personally, I still don't agree with the issue of catalog to database
binding, but that's your choice - I just predict that if you keep it
this way, it is going to be the most popular topic in this NG.

> Again, the design is not to allow several catalog files within a given
> folder.  It's just a bug that you're allowed to do so.
Yeah, that was silly for me to suggest that

> Mixing database catalogs with configuration files that they don't belong to
> can cause all sorts of problems with users being authenticated with
> permissions that they don't actually have, etc.
Only if their names match. This is exactly how it's done in most databases.

> exposure to downtime for multiple customers.  If one customer's database is
> having trouble, for whatever reason, then other customers are not affected.
> It is a legitimate design, despite the fact that you don't agree with it.
I didn't say I don't agree, I said they might consider refactoring. They
just basically treat the database as a document - which is a legitimate use,
no doubt about it - but not most efficient from the database perspective.

> important they are. These are mostly handled by DBAs for large databases,
> but if EDB is aiming at the market of zero config databases, then it could
> become a problem (or the security will not be used - which is more likely if
> we read poll results on your web site . >>
>
> Michael, that's really not particularly funny.  I spent a lot of time
> (months) on the user security aspect of EDB to make it both easy for
> existing DBISAM users to migrate to and to make it something that is usable
> for all users.  Just because you don't agree with the design does not
> warrant a comment to the effect that "no one is going to use it".
Sorry about that, I do hope people are going to use it, what I was smiling
at is it is quite ironic, and actually is a bit funny that one of the
least requested features becomes a driving force for many design decisions.
I've done it too many times myself, actually

Personally, I didn't use the security in DBISAM and probably the only reason
for me to begin using it would be if I'm able to provide my own authentication
scheme - otherwise, it's too much trouble for me to synchronize database level
security with app. level security. Since, as you said, it will be one server
per application, then each application can potentially bind database to
itself (with signature or whatever), so no other server can access it. Then
the database security is no longer needed.

> I'm sorry, but I'm not going to toss out the local user security.  It simply
> isn't going to happen, period.  It's as intertwined into the product as the
> C/S security.  In fact, the two are exactly the same thing.
That I understand I just think you should consider that authentication
and security are two different things. While security should be implemented
everywhere, authentication really only makes sense for servers - when done
local it can be easily compromised anyway (not my argument, I read it in
firebird embedded readme.txt file .

> <<  Are you saying that EDB supports file sharing mode? >>
> Yes, just like DBISAM.
Cool. Unexpected. I guess that explains local security also...


Regards,
Michael