|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Denis Smirnov 2:5020/400 25 Jul 2002 15:59:57
To : Vladimir Bormotov
Subject : Re: Network file system
--------------------------------------------------------------------------------
Vladimir Bormotov <bor@vb.dn.ua> wrote:
VB> давайте не будет обсуждать еще и здесь модели данных. Hаличие множества
VB> файловых систем, их повсеместное распространение, и даже сам вопрос,
VB> который в топике, показывает что данные гораздо проще ложатся в
VB> иерархическую модель. Так ведь? ;)
Дык в том-то и дело, что нужно скрестить ужа и ежа, получив при этом что-то
полезное.
У СУБД для хранения многих видов данных масса своих преимуществ.
VB> задачи, которые формулируются с фиксированием модели данных. Согласен.
VB> Hо кто сказал что нужно именно реляционную модель? Изначальный-то вопрос,
VB> был про иерархическую модель! (файловые системы, web-пространство)
VB> почему-бы не поискать решение в этой модели данных?
VB> Отмазки типа "любой программист сможет" за отмазки не катят. Любой
VB> программист умеет сделать file-tree-walker? В чем проблема с
VB> иерархическими моделями данных?
Hу начнём с того, что иерархическая модель в чистом виде не пригодна вообще
к употреблению (и активное использование линков тому пример).
VB>>> Для начала, замените "SQL" в постановке задачи, на, скажем "XMLdb", и
VB>>> перефразируйте требования. Может получиться очень даже интересно.
DS>> Можно подробнее про XMLdb? В смысле где прочитать про работу с ней?
VB> можно. Почитать можно например архивы ru.xml, например на гугле.
Ok.
VB> нет смысла. Если запрос пишется в виде XML, если результат его в виде
VB> XML, достаточно логично и саму бузу иметь в виде XML. зачем нам двойные
VB> преобразования, и все грабли с ними связаные?
Потому что запрос может быть достаточно сложным. И базу как раз надо хранить
в том виде, который сие позволит.
VB>>> любой кто имеет право записи, может запортить то, куда он имеет право
VB>>> записи. Хоть репозиторий, хоть fs, хоть еще что-то. От РАЗДОЛБАЙСТВА
VB>>> спасает только бекап, и административные меры.
DS>> Если юзверь, имеющий право записи в какой-то файл на FS может её
DS>> запороть -- в задницу такую FS.
VB> её - не может. Файл - легко.
Вот в том-то и дело, что человек должен иметь возможно запороть исключительно
свою работу, но никак не работу своих коллег.
DS>> Соответственно с cvs'ом -- я подразумеваю то, что пользователь не
DS>> должен иметь права записи в репозиторий.
VB> он и не имеет. Он в общем случае, имеет право записи в свой модуль.
VB> Какие проблемы?
Те, что есть модули, над которыми надо работать не одному человеку.
VB>>> Остальное разделение прав в репозитории целиком в рамках unix-like
VB>>> permissions. Плюс, можно пробовать поверзх еще че-то навернуть
VB>>> скриптами.
DS>> Всё равно всё это ненадёжно.
VB> ой не знаю. Давайте критерии надежности, что-ли...
Критерий в этом контексте -- невозможность одного человека повредить данные
другого.
--
С уважением, Denis
http://freesource.info
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
