Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Зачем шифровать весь файл? Сами записи можно шифровать... 09.07.04 19:35 Число просмотров: 1481
Автор: Heller <Heller> Статус: Elderman
|
> 1. Если шифровать строки/записи в текстовых файлах, то
> придеться шифровать запись целиком, чтобы данные одного
> поля не могли существовать без другого, иначе рискуем
> схватить фальсификацию.
> Если каждая запись будет шифроваться ключом создавшего эту
> запись пользователя, то можно себе представить скорость
> работы такой базы и смысл ее существования, когда один
> пользователь не может даже прочесть данные, записанные
> другим пользователем. При этом мы все равно не сможем
> исключить потерю данных из-за возможности удаления.
> Можно, конечно, сделать вариант шифрования некоторым общим
> ключом, зашифрованным паролем пользователя и исключить
> возможность удаления отдельной записи путем шифрования всей
> таблицы/файла, но при этом накладные расходы на
> шифрование/дешифрование всего файла, для получения всего
> лишь одной записи, будут расти в геометрической прогрессии
> и подобная реализация теряет всякий смысл на начальном
> этапе проектирования.
Зачем шифровать весь файл? Сами записи можно шифровать достаточно простым и стандартным способом, а для избежания фальсификации дополнительно вычислять хеш-функции соседних записей, а не всего файла. Будет и быстро и просто.
> 2. Есть возможность реализовать это путем разделения данных
> по пользователям, размещая эти данные в каталогах
> пользователей, а затем реплицировать эти данные в
> недоступных для пользователя файлах (в оригинальной
> файловой БД) при помощи специально написанного робота и
> синхронизировать файлы пользователей с этой БД. Но при этом
> мы теряем актуальность и on-line'овость данных.
Скорее тут проблема уже в самой организации файловой системы - индексирование и потери объёма. Хотя и с тем и с другим можно бороться (уже обсуждалось).
> 3. Самый лучший вариант самостоятельной организации БД на
> текстовых файлах - написание COM серверов, которые будут
> работать на отдельной машине-сервере, предоставлять данные
> пользователям и разграничивать доступ к данным.
> IMHO, этот вариант - изобретение велосипеда и
> убивание кучи времени на разработку, когда это время можно
> с намного большей пользой потратить на изучение реляционных
> БД, SQL серверов и структурированного языка
> запросов.
Ну не так уж это и сложно. При условии, что ты пишешь не универсальный механизм на все случаи жизни, а программу, которая фактически по заданному ключу вынимает из файла определённые данные или напротив пишет их в файл (в сложнейшем случае ещё и проверяет несколько условий). Здесь надо учесть, что пишешь прогу ты для конкретного случая и количество/размеры/прочее полей/записей чаще оказывается более-менее чётким, что уже избавляет программиста от доброй половины работы. Можно сделать реализацию с использованием двух файлов - один хранит сами данные, а второй указатели на зиписи в первом. К тому же при написании собственной базы можно внести ряд корректировок, таких как "лёгкую" архивацию, к примеру - которые в общем случае не допустимы, но в отдельных ситуация могу оказаться достаточно полезными.
Я вообще не против баз. Спорить, что текстовики лучше баз - глупо как минимум. Базы лучше. Но преимущества баз перед текстовиками имхо не так уж и велики. Во всякиом случае в этом топике я пока не видел ни одного действительно весомого аргумента в пользу баз. Аргументов-то куча, но сказать что они особо значимые - нельзя имхо.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
