|Subject||Re: [firebird-support] Advice requested on design pattern|
Once again thank you. I am very sorry it has taken me so long to reply.
On 20/05/15 21:19, Andrea Raimondi andrea.raimondi@... [firebird-support] wrote:
If I understand correctly it will become basically a logging database. That could be fine as I have a data access layer anyway but I would need to make sure that a audit log is only written if a transaction is successfully committed and not rolled back.
1) Re the separate database: nobody said you shouild do it from your own. I'd do it in the client, once the original data has been inserted.
Maximum 1000, typically 50 - 100.3) How many blobs *per user* are you going to have?
Up until now I wasn't really worried about encrypting the data, however the more that I look into this the more it seems like an almost necessity.6) The only real remaining problem is encryptuion - if you want that for some of your data. Provided that I would strongly discouragre that
especially on Firebird because of the eaae of peeking inside the DB which equates roughly to no ecryption, I would go for something
slightly off the ordinary: what you can do is encrypt your data in the app and then apply it to your tables. There are several strategies you
could employ, but I think you first need to determine whether that's what you really want.
If I understand correctly the downside of encrypting data in the app is obviously that Firebird can't index the contents. I have been looking at Firebird 3 in this regard and it seems to be possible, at least to include reasonably obfuscated data using a closed source (my own or third party) plug-in.
Thank you again for your advice!