|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 25 Jul 2002 20:29:27
To : Denis Smirnov
Subject : Re: Network file system
--------------------------------------------------------------------------------
Hi, Denis!
>>>>> "DS" == Denis Smirnov <mithraen@freesource.info> writes:
DS> Просто ты смотришь на уровень FS, а я пытаюсь посмотреть внутрь этих
DS> файлов.
я хоть так, хоть так могу смотреть.
DS> Как только я это делаю, иерархическая модель уже не работает.
да на любой современой реализации еерархической модели данных есть линки,
и прочие "удобные для практиеского применения фишки".
В XML линков наставить, и прочих удобств - нефиг делать ;)
DS>>> Hу начнём с того, что иерархическая модель в чистом виде не пригодна
DS>>> вообще к употреблению (и активное использование линков тому пример).
VB>> о! еще один борец за чистоту идеи ;)))
VB>> Я не предлагаю "чисто идейные решения". Я предлагаю другую основу. Даже
VB>> не основу, а просто посмотреть чуть в сторону, попробовать. Я же не знаю
VB>> всех тонкостей вашей задачи...
DS> Какую другую основу ты предлагаешь? Может я просто тебя неправильно
DS> понял.
нереляционную. Т.е. если в сути задачи не файлохранилище, а хранилище
некоторых сущьностей (представимых в виде набора данных), и эти сущьности
сильно разнородные, то реляционная модель некрасивое решение. Хотя и
имеющее право на жизнь, и в виду развитости этого сектора софтверной
индустрии может быть даже наиболее выгодное по затратам. Я предлагаю
"отложить SQL, потому что он никуда не денется", и посмотреть на XMLdb.
VB>>>> нет смысла. Если запрос пишется в виде XML, если результат его в виде
VB>>>> XML, достаточно логично и саму бузу иметь в виде XML. зачем нам
VB>>>> двойные преобразования, и все грабли с ними связаные?
DS>>> Потому что запрос может быть достаточно сложным.
VB>> разумеется. И если даныне у нас в виде документов, то запрашиваьт нужно
VB>> так, чтоб получать документы.
DS> А кто сказал, что все данные -- документы?
те, котоыре не документы, легко представимы как документы, без потери
своих свойств. Зато, как только они становятся документами, к ним
становятся применимы всякие интересные тулзы, которые применимы к
документам.
DS> Вообще же таковыми является не так много _данных_. Таковыми является
DS> обычно результат обработки этих самых данных.
не. Это же модели. математические. Пример фильма, на 700M DivX, который
хотели пихать в оракла. Вроде файл, бинарный. да? Hо ведь если его
пихать в оракла, то сразу хочется на него навесить кучу метаинформации.
Hачиная от названия на нескольких языках, заканчивая продюсером,
режисером, списком актеров и так далее. Вот ВСЕ ЭТО В ЦЕЛОМ - будет
"фильм". И будет представимо в виде документа. Структуру такого документа
можно "формализовать" используя технологии XML. Выборки из множества
таких документов, тоже можно делать используя xml-tech.
Hапример, список актеров. Как пихать в релиционку? Да-да, все сразу
представили нормальную форму. Зачем таки сложности? А как потом делать
все эти выборки, и прочее?
Опять-же, кого будет сильно волновать, что в качесве back-end'а у того-же
4SS будет тот-же Oracle? ;-)
DS>>> Вот в том-то и дело, что человек должен иметь возможно запороть
DS>>> исключительно свою работу, но никак не работу своих коллег.
VB>> я считаю что любое современное средство этому критерию
VB>> удовлетворяет. А если у этого средсва еще есть и поддержка
VB>> версионности, то ваще классно. Мы вот например сейчас
VB>> прикалываетмся от TWiki. Пытаемся весь раздел сапорта в него
VB>> запихать. Вроде получается.
DS> Вывод -- CVS не современное средство?
почему несовременное?
VB>> ну? Эти "не один человек" команда. Они делят между собой отвевенность
VB>> за работу. Если есть конкуренция и вредительство в одной команде - то это
VB>> не команда. И их нужно разделить. применительно к CVS - в том числе и в
VB>> разные модули.
DS> Вредительство может быть и ненамеренным. Это может быть и rm -rf /
DS> данный от пользователя.
в случае CVS - он этим удалит только свою рабочую копию.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
