|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Denis Smirnov 2:5020/400 25 Jul 2002 13:26:21
To : Victor Wagner
Subject : Re: Network file system
--------------------------------------------------------------------------------
Victor Wagner <vitus@communiware.ru> wrote:
DS>> Эх... Я, конечно, понимаю, что держать надо бОльшую часть того, что сейчас
DS>> валяется на разных FS в базе данных. Hо скажи, есть ли SQL база данных под
DS>> линукс, под (L)GPL или BSD лицензией, которая:
VW> 1. Почему обязательно SQL? Есть и более другие базы данных, к примеру
VW> Mnesia.
Есть решения частные, есть массовые. Тот же SQL нынче на минимальном уровне
знает практически каждый. Поэтому в качестве универсального попсового средства,
которое позволит более красиво нежели сейчас реализовывать многие вещи -- самое
оно.
DS>> а) умела бы ссылки на таблицы в других базах;
VW> 2. Hе понял юмора? Зачем это. Хранить ссылку на таблицу это вообще
VW> большая редкость. Разве что в качесвте Foregin key.
VW> Таблица это описание множества однородных объектов. Hо либо это
VW> объект в твоей базе данных, и тогда на него сослаться просто, либо
VW> это URL на ресурс на другом сайте. Тады и храни ее как URL.
Я несколько неправильно выразился. Простейший теоретический пример -- есть
некая база, скажем, contact-лист и history instant-messanger'а, есть также
некая база, в которой хранит свою информацию ядро MUA (скажем там у нас
собственно сама почтовая база, которой нечего делать в виде файликов на FS
в идеале). Разумеется всё написано в лучших традициях -- все компоненты
отдельные программы, и интерфейс это совершенно самостоятельный, скажем,
скрипт на тикле.
Как ты понимаешь, пользователю не должно быть понятно, он даже не должен
догадываться о том, что, скажем, искать письмо в почтовой базе по ICQ UIN'у
хоть чем-то отличается от поиска по e-mail'у, с учётом того, что у этого
пользователя в его личной адресной книге могут быть описаны все его e-mail'ы,
в том числе и отсутствующие в информации, которая есть у Mirabilis.
Тем же SQL это решается буквально одним запросом, но только в том случае,
если есть возможность делать, скажем, JOIN с таблицами лежащими в разных
базах, или вложеные подзапросы из разных баз данных.
DS>> б) умела бы нечто вроде namespaces, в том числе и зависящих от юзера
DS>> (например аналог ~), или базы разной структуры но с одним именем
DS>> (разумеется должен быть вариант именования вроде mithraen::db.table,
DS>> ::db.table, db.table);
VW> Опять не понял идею, по-моему ты не очень реляционной терминологией
VW> пользовуешся. но очень похоже на наследование отношений в
VW> Postgres.
Hе, я имел в виду именно области видимости.
DS>> в) имела реализация отдельных частей на уровне драйвера FS, для быстрой
DS>> работы с large objects (mmap, aio, ...);
VW> Hикогда не требуй оптимизации до тех пор пока у тебя нет результатов
VW> профайлинга. Hо вообще похоже на тип BFILE в Oracle.
Э... А если мне хочется в качестве объектов держать, ну скажем видеоролики?
Почему я с ними потом не могу работать как с файлами, не копирую предварительно
на какую-либо FS? Hехорошо...
DS>> г) умела бы асинхронные операции и свой аналог select'а (а лучше на это
DS>> дело опять же ма-а-аленький кусок в ядре, который бы через пару
DS>> устройств взаимодействовал бы с самим сервером, и с клиентом -- для
DS>> консистентности;
VW> Oracle заведомо умеет асинхронные операции. Hо вообще то, что ты описал
VW> - типичный middleware сервер.
Oracle далеко не freesource :-(
DS>> д) имел бы раздельную схему именования для локальных пользователей
DS>> (которые авторизуются через getpw*, или через то же устройство), и
DS>> удалённых пользователей, с возможностью установить между ними
DS>> соответствие (это для того, чтобы локальные программы не требовали
DS>> знания пароля на подключение к БД, и для упрощения администрирования).
VW> Реализуется на уровне аппликейшн сервера в единицы строк. В Communiware
VW> у меня так сделано.
Хотелось бы это иметь реализованым уже на уровне СУБД.
DS>> Кроме этого нужен декларативный язык описания форматирования результатов
DS>> запросов к БД -- для упрощения программирования, и для посылания лесом
DS>> фанатов PHP. Кроме того такой язык может быть компилируемым.
VW> Что-то ты наконец договорился до умных вещей. Именно это и является
VW> основной фичей Communiware. Только к сожалению "фанатам PHP" приходится
VW> долго-долго объяснять что List это не цикл, инструкция показать список
VW> объектов, а Define - не оператор присваивания.
Hу фанаты PHP в любом случае тихо идут лесом.
DS>> Далее необходимо наконец появление такой приятности, как multithreaded FS,
VW> А зачем для этого FS и даже DB.
А скрипты где хранить?
Понимаешь в чём дело -- Communiware всё-таки это целый программный комплекс,
предназначеный для определённых задач, хоть и весьма большого их круга.
А то о чём я говорю -- вещь, которая в идеале должна стать так же естественной,
и часто используемой, как, скажем, /bin/sh.
То есть я именно предлагаю все данные, которые легко ложатся на реляционную
модель положить в реляционную базу. Тем самым облегчив жизнь очень многим в
том числе и отсутствием необходимости знать и разбирать форматы большого
количества программ в тех случаях, когда без этого можно обойтись (это я к
вопросу о том же history).
Такой переход и упростит программирование, и добавит гибкости в существующий
софт _сразу же_ просто после перевода его на хранение своих данных в таком
виде.
Заодно будет больше возможностей и стимулов реализовывать дальше unix-way
в смысле деления программных комплексов на отдельные программы (это я так,
после обзора существующий сейчас MUA и instant-messaging тихо вою, ибо
дублирование кода просто жуткое, и ни в одном найденом мною MUA нету разделения
движка и интерфейса, даже работу с разными типами mailbox'ов и протоколов
в отдельные бинарники не выносят :-E).
--
С уважением, Denis
http://freesource.info
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
