| Subject | RE: Re : [firebird-support] firebird password |
|---|---|
| Author | Leyne, Sean |
| Post date | 2011-04-16T01:36:01Z |
Hoang-Vu,
That said, however, the intent of the reply was to point out that the reality is that if a database is available via ODBC there isn't much to the schema that can be protect. Only trigger and stored procedure logic can be "protected" which in the overall scope of things is not much -- given a schema I know that I can infer the triggers and SP logic.
So, anguishing about a lack of schema encryption/protection is not logical.
Sean
P.S. For ourselves, we think that our application/solution is about more than the database schema -- it about the scope of our solution. So, we don't use any "obfuscation" and allow our clients full access to the database/schema and simply advise client that all non-public SPs/functions are subject to change and any change to the schema will invalidate our support contract (though we expect to still be paid our monthly support).
AKA "Walk softly but carry a bid stick"... no client will allow this to happen -- ours is a mainline business system, so without our support, our clients are _dead_ (if not fatally wounded). So, access to the schema has no risk for us.
> > Why do you want to protect the db design ? It is against the spirit of openI agree that the initial response was out-of-context, using an open source software doesn't imply that the DB design/schema needs to be open.
> source software.
>
> if open source is open data, no one will use firebird.
That said, however, the intent of the reply was to point out that the reality is that if a database is available via ODBC there isn't much to the schema that can be protect. Only trigger and stored procedure logic can be "protected" which in the overall scope of things is not much -- given a schema I know that I can infer the triggers and SP logic.
So, anguishing about a lack of schema encryption/protection is not logical.
Sean
P.S. For ourselves, we think that our application/solution is about more than the database schema -- it about the scope of our solution. So, we don't use any "obfuscation" and allow our clients full access to the database/schema and simply advise client that all non-public SPs/functions are subject to change and any change to the schema will invalidate our support contract (though we expect to still be paid our monthly support).
AKA "Walk softly but carry a bid stick"... no client will allow this to happen -- ours is a mainline business system, so without our support, our clients are _dead_ (if not fatally wounded). So, access to the schema has no risk for us.