|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 25 Jul 2002 19:00:30
To : Denis Smirnov
Subject : Re: Network file system
--------------------------------------------------------------------------------
Hi, Denis!
>>>>> "DS" == Denis Smirnov <mithraen@freesource.info> writes:
VB>> давайте не будет обсуждать еще и здесь модели данных. Hаличие
VB>> множества файловых систем, их повсеместное распространение, и даже
VB>> сам вопрос, который в топике, показывает что данные гораздо проще
VB>> ложатся в иерархическую модель. Так ведь? ;)
DS> Дык в том-то и дело, что нужно скрестить ужа и ежа, получив при этом
DS> что-то полезное.
если "ёжеуж" или "ужеёж" это и есть искомое полезное - то да,
скрещивайте.
DS> У СУБД для хранения многих видов данных масса своих преимуществ.
нет. Hо я спорить на эту тему не буду.
VB>> задачи, которые формулируются с фиксированием модели данных. Согласен.
VB>> Hо кто сказал что нужно именно реляционную модель? Изначальный-то
VB>> вопрос, был про иерархическую модель! (файловые системы,
VB>> web-пространство) почему-бы не поискать решение в этой модели данных?
VB>> Отмазки типа "любой программист сможет" за отмазки не катят. Любой
VB>> программист умеет сделать file-tree-walker? В чем проблема с
VB>> иерархическими моделями данных?
DS> Hу начнём с того, что иерархическая модель в чистом виде не пригодна
DS> вообще к употреблению (и активное использование линков тому пример).
о! еще один борец за чистоту идеи ;)))
Я не предлагаю "чисто идейные решения". Я предлагаю другую основу. Даже
не основу, а просто посмотреть чуть в сторону, попробовать. Я же не знаю
всех тонкостей вашей задачи...
VB>> нет смысла. Если запрос пишется в виде XML, если результат его в виде
VB>> XML, достаточно логично и саму бузу иметь в виде XML. зачем нам двойные
VB>> преобразования, и все грабли с ними связаные?
DS> Потому что запрос может быть достаточно сложным.
разумеется. И если даныне у нас в виде документов, то запрашиваьт нужно
так, чтоб получать документы.
DS> И базу как раз надо хранить в том виде, который сие позволит.
вот-вот. Идем, и читаем про RDF, и например про язык запросов Versa..
;-)
VB>>>> любой кто имеет право записи, может запортить то, куда он имеет право
VB>>>> записи. Хоть репозиторий, хоть fs, хоть еще что-то. От РАЗДОЛБАЙСТВА
VB>>>> спасает только бекап, и административные меры.
DS>>> Если юзверь, имеющий право записи в какой-то файл на FS может её
DS>>> запороть -- в задницу такую FS.
VB>> её - не может. Файл - легко.
DS> Вот в том-то и дело, что человек должен иметь возможно запороть
DS> исключительно свою работу, но никак не работу своих коллег.
я считаю что любое современное средство этому критерию удовлетворяет. А
если у этого средсва еще есть и поддержка версионности, то ваще классно.
Мы вот например сейчас прикалываетмся от TWiki. Пытаемся весь раздел
сапорта в него запихать. Вроде получается.
DS>>> Соответственно с cvs'ом -- я подразумеваю то, что пользователь не
DS>>> должен иметь права записи в репозиторий.
VB>> он и не имеет. Он в общем случае, имеет право записи в свой модуль.
VB>> Какие проблемы?
DS> Те, что есть модули, над которыми надо работать не одному человеку.
ну? Эти "не один человек" команда. Они делят между собой отвевенность за
работу. Если есть конкуренция и вредительство в одной команде - то это не
команда. И их нужно разделить. применительно к CVS - в том числе и в
разные модули.
VB>>>> Остальное разделение прав в репозитории целиком в рамках unix-like
VB>>>> permissions. Плюс, можно пробовать поверзх еще че-то навернуть
VB>>>> скриптами.
DS>>> Всё равно всё это ненадёжно.
VB>> ой не знаю. Давайте критерии надежности, что-ли...
DS> Критерий в этом контексте -- невозможность одного человека повредить
DS> данные другого.
в CVS есть бранчи, и есть версии. даже если сегодня сделаю коммит
"чужого" файла, пустым файлом, "хозяин" этого файла всегде сможет взять
предыдующую версию. Hо такой мой поступок - это вредительство. И ко мне
нужно применить административные меры. Как минимум.
Уповать на технику я бы не стал. Слишком дорого. защищиться от своего
напарника по работе, я тоже смысла не вижу. Потому что он, с большей
вероятностью сможет мне помочь, чем навредить.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
