> My company is evaluating whether to use Derby for a desktop/client-server > application where security and 21-CFR 11 compliance is important.
Although Derby can be used perfectly well as a standalone database, it is also designed to be embedded into a containing application. The Derby libraries are small and stable, the memory footprint is predictable, and many other aspects of Derby favor this embedded usage. If you thus embed Derby into your application, you can arrange for little or none of the Derby APIs to be part of the exposed "surface" of your application, and therefore you can minimize your security exposure. For example, you say you are designing a client-server application; presumably Derby is to be part of the server component. But you do NOT need to make Derby be the *entire* server component. As an alternative design, you could implement your own completely locked-down web service, which provides just the APIs that your application client requires, in a highly-secure fashion, and embed Derby inside your secure web service. Hope these ideas give you some new perspectives to consider. thanks, bryan
