Добавить комментарий

Именно такое обсуждение я и хотел бы видеть.

Мои комментарии (по той же нумерации пунктов).

1. Приложение БД ТОЖЕ пользователь (для ядра, по крайней мере). Да и вообще, граница между СУБД и приложениями условна: популярные приложения могут перетекать в тело универсальной СУБД, и наоборот. Тем более, что конечному пользователю, как правило, по барабану, кто там с ним "разговаривает". Так что просто имеем УРОВЕНЬ приложений (или там слой - терминология не устоялась).

2-3. Не согласен: это вопросы и модели тоже. Например, тезис "элемент БД может быть БД" - какая же это "реализация"? Это ИДЕОЛОГИЯ! А требование "быстрый доступ к данным" есть просто крест на реляции! И никакие "ограничения существующих моделей" меня не интересуют - мы говорим об ИДЕАЛЬНОЙ БД. Точнее, интересуют, но лишь в том плане, чтобы показать, как они обходятся. :)

4. ХРЕНУШКИ! Для многоуровневой БД буквально КАЖДЫЙ слой является сервером (для вышестоящих) и клиентом (для нижестоящих). Технология "клиент-сервер" работает и внутри СУБД! А, ну да - я ж говорил про браузер... Для ЧЕЛОВЕКА (чистый клиент, не сервер) - это браузер. Ядро (физический уровень) - это чистый сервер. Все остальные уровни - и то, и другое, в одном флаконе. Стандартизовать надо не API, а ЯЗЫКИ взаимодействия.

5. ЕСЛИ "по определению, БД - это структурированное хранилище информации", ТО такое определение устарело. Идеальная БД - это хранилище ЛЮБЫХ (оцифрованных) данных.

6. Я не говорю про многомерные БД - тем более, про несчастные кубы. Я говорю про данные ПРОИЗВОЛЬНОЙ сложности - в том числе, и кубы. Нет, мне не кажется, что сложность языка запросов пропорциональна сложности структур. Я не очень понимаю, что Вы имеете в виду под "полнотой языка модели". Пусть там хоть тыщу раз "SQL реляционно полон" - он же убог и немощен!