Приведение СУБД в соответствие современным коммуникационным требованиям - SQL:2009

В эпоху, когда компьютер стоит на каждом рабочем месте, любой средний человекнаходится на передовой - он должен самостоятельно принять, отправить, обработать данные. Удобно накопить их в базе данных, но ни один обычный человек не может: *) выводить 3-мерные конструкции из базы данных на экран (конвертировать в формат и протокол X11) *) предоставлять ввод из браузера (настроить проприетарный веб-сервер конкретной СУБД) *) копировать информацию из удаленной базы данных (использовать другие источники информации для создания собственного mash-up сервиса) *) несколько раз включить и выключить ноутбук в течение одной длинной транзакции, длящейся дни или даже недели

Автор предлагает решения этих проблем, и заинтересован в мнении, комментариях и возможной реализации этих предложений. Детали изложены в pdf-документе [1] (далеебудем ссылаться на страницы этого документа). Все проблемы, кроме 2-й, могут быть решены с использованием проприетарных форматов передачи данных, и сформулированы как передача XML только для унификации с 2-й проблемой.

Решение 1-й проблемы - интерфейс 'модель - оконная система' - описан в предыдущей публикации [2]. Чтобы приказать СУБД сменить формат данных с XML на Х11 иубрать невидимые поверхности, в операторе 'SELECT' используется постфикс 'PROJECTING'. В частном случае 2-мерных данных, объекты должны быть записаны с помощью схемы данных (что понятно пользователям), а не в вычурных (и излишних) типах данных, которые пользователь не осваивает. Единственное отличие от предыдущей публикации состоит в том, что в целях унификации с XML автор предлагает отправить Х11 данные до клиента в XML-обертке.

Для решения 2-й проблемы, необходимо предоставить возможность инсталлировать СУБД и немедленно использовать ее так, как пользователь инсталлирует и использует программы "Teleport", "FlashGet", браузер и т.д. СУБД сама должна принимать XML и размещать данные, в нем содержащиеся, в таблицах в соответствии с некоторыми соглашениями. Мои предложения относительно этих соглашений: *) xml-элемент записывается в таблицу с тем же именем (т.е. имя тега совпадает с именем таблицы), xml-атрибут записывается в поле с тем же именем (т.е. имя атрибута совпадает с именем поля). Первичный ключ новой записи заполняется триггером *) во время создания двух записей, соответствующих обрамляющему xml-элементу и непосредственно вложенному в него, первичный ключ одной записи копируется во внешний ключ другой (предполагается, что одна таблица ссылается на другую только одним внешним ключом, и что две таблицы не ссылаются друг на друга одновременно [3]) *) во время создания двух записей, соответствующих двум одноименным последовательно расположенным xml-элементам, также первичный ключ одной записи копируется во внешний ключ другой (предполагается, что таблица ссылается на саму себя только одним внешним ключом [4])

Нельзя обойти вниманием и обратную проблему - проблему вывода записей в виде xml-элементов. Использование как SQL/XML-функций, так и синтаксиса проприетарного веб-сервера [5] дают очень громоздкий код, в котором пользовательзапутывается. В то же время обычно извлекаются записи, уже связанные внешним ключом. Таким образом мы имеем дерево, уже сформированное в схеме базы данных. Предлагаю лаконичное 'select a.b.c' для выбора данных из таблиц 'a', 'b', 'c', уже связанных внешними ключами [6]. Будем называть это термином 'XTree' - поаналогии с 'XPath' (предполагается, что таблицы ссылаются друг на друга только одним внешним ключом, и что две таблицы не ссылаются друг на друга одновременно [7]).

Что касается 3-й проблемы, то необходимо отметить, что SQL был бы более гибок и удобен для распределенных запросов (сбор данных из нескольких баз данных и рассовывание их в несколько баз данных), чем фирменные программы; в т.ч. более удобен для репликации, чем фирменные программы. Но нет необходимого синтаксиса: *) пусть каждая база данных получит 'прозвище'. Прозвище указывается в запросе перед именем таблицы через двоеточие *) группу баз данных назовем 'обществом'. Общество также указывается перед именем таблицы через двоеточие, и означает прозвища всех баз данных, входящих в группу [8] *) база данных по умолчанию - это та, в которой хранятся все прозвища и все общества

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

Таким образом одна база данных не может породить и ввести sql-команду в другую базу данных ни прямо, ни косвенно (прося клиента перенаправить команду). А клиент не может сконструировать новую sql-команду на основе разбора (parse) введенной.

Первая база данных отправляет клиенту специальную команду, которая заставляют клиента сделать подстановку в последней отправленной первой базе данных sql-команде, запомненной в стеке клиента, и выслать результат преобразования второй базе данных. Специальные команды должны быть настолько ограниченными, чтобы не допускать порождения sql-команды, вредной для второй базы данных [9].

Для решения 4-й проблемы, достаточно ввести оператор 'FREEZE' (подобный 'DISCONNECT'), который сохраняет транзакцию в текущем состоянии; и оператор 'UNFREEZE' (подобный 'CONNECT'), который продолжает транзакцию с замороженного состояния (а не начинает новую, как 'CONNECT'). 'FREEZE' возвращает идентификатор замороженной транзакции, который должен быть указан в 'UNFREEZE'.