информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / web building
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Давайте расставим все точки над 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 серверов и структурированного языка запросов.
<web building> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach