Решение для базы данных для клиент-серверного приложения с зашифрованной базой данных?

Question

У нас есть приложение Windows на .net 2.0, которое использует встроенную зашифрованную базу данных. База данных состоит из секретных данных - около 350 МБ, которые доступны только для чтения и обновляются каждые 4 месяца.

До сих пор мы использовали файл SQLite в качестве базы данных, и он работал хорошо, но нам нужно перейти к версии клиент-сервер, поскольку у некоторых клиентов есть 20-40 клиентов, и они не хотят лицензировать и обновлять каждый клиент отдельно.

Какое решение для базы данных вы можете нам посоветовать для этого:

• База данных должна оставаться зашифрованной, чтобы даже администратор не мог прочитать данные.

• Мы должны продолжать обмениваться базой данных каждые 4 месяца.

• Мы планируем сделать серверное приложение в качестве службы Windows, чтобы служба считывала данные из базы данных и отправляла данные клиентам. Но мы также можем использовать некоторый бесплатный сервер sql, если можем обеспечить приемлемое шифрование.

• Было бы хорошо использовать одну и ту же базу данных для нашей клиент-серверной версии и версии для одного клиента, поэтому при выпуске дополнительных преобразований не требуется.

Поскольку база данных доступна только для чтения, возможно, у нас не возникнет проблем с использованием sqlite здесь снова. Есть идеи?

Answer 1

Очевидный ответ - перейти на MySQL, однако это не так просто.

В частности, вы говорите, что ваша база данных доступна только для чтения.В этом случае SQLite вообще не нужно будет использовать транзакции или напрямую блокировать файл базы данных.

Это огромное преимущество, потому что именно физическая блокировка файла базы данных вызывает большие проблемы с масштабируемостью для многопользовательского доступа к базе данных SQLite

(Но даже при чтении и записиДокументы SQLite говорят, что он отлично работает для сайтов с 100 000 посещений в день.

Похоже, что вы собираетесь использовать единую централизованную службу Windows для обслуживания всех клиентов.В этом случае весь доступ к базе данных будет сериализован этой службой, и поэтому в SQLite никогда не будет двух одновременных соединений, конкурирующих за доступ.В этом случае SQLite не будет узким местом, служба будет.

Если служба, конечно, многопоточная, то да, возможен параллельный доступ к SQLite, но, опять же, только для чтения, поэтому проблема по-прежнему не актуальна.

Кроме того,ваши требования к шифрованию базы данных и 4 ежемесячных обменов гораздо проще удовлетворить с SQLite, чем MySQL.

Вы читали этот предыдущий вопрос в StackOverflow?Кайл Кронин дает интересный комментарий о своем опыте с течением времени и в конечном итоге говорит, что SQLite - это хороший вариант для многопользовательских веб-сайтов меньшего объема.

Надеюсь, я дал пищу для размышлений.