SQL5 или SQL:2009 - управляемая сцена, иерархические наборы данных, распределенные запросы, полноценный BLOB

Tрудности, связанных с использованием 3D-объектов, возникает из-за низкого качества интерфейса, а не из-за сложности трехмерной задачи. Наилучшим является

• 3D-конструкция, представленная как иерархия точек, треугольников, фигур (групп треугольников), групп фигур, групп групп, и т.д. Записи, содержащие эти объекты, должны быть связаны внешним ключем
• СУБД, возвращающая 3D-объекты в формате X11 как результат оператора 'select' и изменяющая координаты точек оператором 'update'

Пользователю достаточно вызвать одну функцию, например 'printg("select ...")', в которой указать какие 3D-объекты из базы данных должны возникнуть на экране. И достаточно вызвать ее с другим запросом, например 'requst("update ...")', чтобы изменить положение объекта в базе данных и на экране. И эта функция может быть вызвана в любой программе. Предлагаем назвать новый интерфейс Управляемой Сценой.

Поля вывода программ связаны отношениями IDEF1: экран программы имеет схему, и эта схема полностью повторяет схему базы данных. Но в декартовых произведениях клиент не может разделить, какие поля относятся к одной таблице, какие к другой. Получается, что извлекая информацию из базы данных мы теряем часть информации. Вместо того, чтобы вставить теряемую информацию машиной, мы делаем это вручную, извлекая по одной записи для того, чтобы найти связанные с нею. На это уходит до 50% рабочего времени. И эта проблема до сих пор не отрефлексирована индустрией. Предложим сильное решение. Кроме того, поля ввода также связаны отношениями IDEF1 - СУБД сама должна принимать иерархические наборы данных и размещать данные, в нем содержащиеся, в таблицах в соответствии с некоторыми соглашениями.

SQL был бы более гибок и удобен для распределенных запросов (сбор данных из нескольких баз данных и рассовывание их в несколько баз данных), чем фирменные программы; в т.ч. более удобен для репликации, чем фирменные программы. Но нет необходимого синтаксиса. В целях безопасности распределенные запросы должны удовлетворять некоторым требованиям: предложим концепцию полного недоверия одной базы данных другой, концепцию крайней простоты клиента и синтаксис для этого.

Современная тенденция - хранить мультимедийные данные в базе данных, а не в файловой системе.

• При скачивании (с сервера, в т.ч. с СУБД) соединения иногда разрываются, может понадобится перезагрузить компьютер-получатель. Как продолжить скачивание?
• А если кто-нибудь попросит СУБД выдать BLOB в процессе получения (от клиента, который отправляет его по собственной инициативе), что СУБД должна ответить ему? Отвечая NULL, она сообщит, что ничего не знает о BLOB, что является ложью, т.к. получение BLOB - это только вопрос времени. Поле должно хранить новое значение, подобное NULL, но не равное ему!?
• Кроме того, пусть третья база данных копирует BLOB-поле в себя в тот момент, когда наша база данных его еще получает. Может ли третья база данных содержать то же самое новое значение? Очевидно нет, т.к. это выглядело бы так, как будто третья база данных сама получает BLOB. Таким образом третья база данных дезинформировала бы своих пользователей, и внушила бы им ложные надежды. Нам нужно еще одно значение, подобное NULL!?

Рассмотрим, какие наборы значений должно содержать поле, и какие нам нужны операторы.

Тюрин Дмитрий, dmitryturin@yandex.ru