Tрудности, связанных с использованием 3D-объектов, возникает из-за низкого качества интерфейса, а не из-за сложности трехмерной задачи. Наилучшим является
Пользователю достаточно вызвать одну функцию, например 'printg("select ...")', в которой указать какие 3D-объекты из базы данных должны возникнуть на экране. И достаточно вызвать ее с другим запросом, например 'requst("update ...")', чтобы изменить положение объекта в базе данных и на экране. И эта функция может быть вызвана в любой программе. Предлагаем назвать новый интерфейс Управляемой Сценой.
Поля вывода программ связаны отношениями IDEF1: экран программы имеет схему, и эта схема полностью повторяет схему базы данных. Но в декартовых произведениях клиент не может разделить, какие поля относятся к одной таблице, какие к другой. Получается, что извлекая информацию из базы данных мы теряем часть информации. Вместо того, чтобы вставить теряемую информацию машиной, мы делаем это вручную, извлекая по одной записи для того, чтобы найти связанные с нею. На это уходит до 50% рабочего времени. И эта проблема до сих пор не отрефлексирована индустрией. Предложим сильное решение. Кроме того, поля ввода также связаны отношениями IDEF1 - СУБД сама должна принимать иерархические наборы данных и размещать данные, в нем содержащиеся, в таблицах в соответствии с некоторыми соглашениями.
SQL был бы более гибок и удобен для распределенных запросов (сбор данных из нескольких баз данных и рассовывание их в несколько баз данных), чем фирменные программы; в т.ч. более удобен для репликации, чем фирменные программы. Но нет необходимого синтаксиса. В целях безопасности распределенные запросы должны удовлетворять некоторым требованиям: предложим концепцию полного недоверия одной базы данных другой, концепцию крайней простоты клиента и синтаксис для этого.
Современная тенденция - хранить мультимедийные данные в базе данных, а не в файловой системе.
Рассмотрим, какие наборы значений должно содержать поле, и какие нам нужны операторы.
Тюрин Дмитрий, dmitryturin@yandex.ru