Hi,

I've been using DBISAM 4 in a clinic management product which is now about
2-3 years old and some customers databases are getting pretty big, the main
'patient' table being about 20,000+ records (with around 50 fields and lots
of data).

Because of the sensitive nature of patient data, I encrypted EVERY table in
the database.

However, some customers have recently started to comment about speed issues
and I'm just wondering :-

(a) Is there any problem in removing the encryption from tables that don't
really need it so that some tables in the database are encrypted and others
aren't?
(b) Will removing encryption help the performance much or is the cost of
encryption negligable?

TIA,

Hedley

Hedley,

> (a) Is there any problem in removing the encryption from tables that don't
> really need it so that some tables in the database are encrypted and others
> aren't?

No.

> (b) Will removing encryption help the performance much or is the cost of
> encryption negligable?

DEcryption is pretty efficient but ENcryption is quite computationally
expensive. This is a characteristic of the blowfish algolrithm rather
than anything particularly related to DBISAM. Losing the encryption will
definitely speed the application up irrespective of that, but the exact
amount will depend upon the profile of reads to writes.

Eryk

Thanks Eryk - your comments are much appreciated.

"Eryk Bottomley" <no@way.com> wrote in message
news:A72EC9AD-325A-411F-998A-AAEC2B9CA905@news.elevatesoft.com...
> Hedley,
>
>> (a) Is there any problem in removing the encryption from tables that
>> don't really need it so that some tables in the database are encrypted
>> and others aren't?
>
> No.
>
>> (b) Will removing encryption help the performance much or is the cost of
>> encryption negligable?
>
> DEcryption is pretty efficient but ENcryption is quite computationally
> expensive. This is a characteristic of the blowfish algolrithm rather than
> anything particularly related to DBISAM. Losing the encryption will
> definitely speed the application up irrespective of that, but the exact
> amount will depend upon the profile of reads to writes.
>
> Eryk