Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Давайте расставим все точки над i ? 09.07.04 18:32 Число просмотров: 1440
Автор: Den <Denis> Статус: The Elderman Отредактировано 09.07.04 18:36 Количество правок: 1
|
1. Если шифровать строки/записи в текстовых файлах, то придеться шифровать запись целиком, чтобы данные одного поля не могли существовать без другого, иначе рискуем схватить фальсификацию.
Если каждая запись будет шифроваться ключом создавшего эту запись пользователя, то можно себе представить скорость работы такой базы и смысл ее существования, когда один пользователь не может даже прочесть данные, записанные другим пользователем. При этом мы все равно не сможем исключить потерю данных из-за возможности удаления.
Можно, конечно, сделать вариант шифрования некоторым общим ключом, зашифрованным паролем пользователя и исключить возможность удаления отдельной записи путем шифрования всей таблицы/файла, но при этом накладные расходы на шифрование/дешифрование всего файла, для получения всего лишь одной записи, будут расти в геометрической прогрессии и подобная реализация теряет всякий смысл на начальном этапе проектирования.
2. Есть возможность реализовать это путем разделения данных по пользователям, размещая эти данные в каталогах пользователей, а затем реплицировать эти данные в недоступных для пользователя файлах (в оригинальной файловой БД) при помощи специально написанного робота и синхронизировать файлы пользователей с этой БД. Но при этом мы теряем актуальность и on-line'овость данных.
3. Самый лучший вариант самостоятельной организации БД на текстовых файлах - написание COM серверов, которые будут работать на отдельной машине-сервере, предоставлять данные пользователям и разграничивать доступ к данным.
IMHO, этот вариант - изобретение велосипеда и убивание кучи времени на разработку, когда это время можно с намного большей пользой потратить на изучение реляционных БД, SQL серверов и структурированного языка запросов.
|
|
|