(коррекция ссылки) Приведение СУБД в соответствие современным коммуникационным требованиям - SQL:2009 - Mailing list pgsql-ru-general

[2] http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00004.php
заменено на привильную ссылку
[2] http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php

---

В эпоху, когда компьютер стоит на каждом рабочем месте, любой средний человек
находится на передовой - он должен самостоятельно принять, отправить, обработать
данные. Удобно накопить их в базе данных, но ни один обычный человек не может:
  *) выводить 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'.


[1] http://sql50.euro.ru/sql5.16.4.pdf
[2] http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php
[3] Если обе таблицы ссылаются друг на друга, или одна ссылается на другую
несколькими внешними ключами, то эта неоднозначность разрешается в имени
открывающего xml-тега: после собственно имени таблицы, содержащей нужный внешний
ключ, ставится знак '#' и имя нужного ссылающегося поля (не имя constraint-а,
т.е. внешнего ключа). Выглядит как новое имя открывающего тега с символом '#' в
середине имени (с. 22-23). Такое указание имени ссылающегося поля будем называть
это термином 'детерминация'
[4] Если таблица ссылается на саму себя несколькими внешними ключами, то эта
неоднозначность также разрешается в имени открывающего xml-тега: после
собственно имени таблицы ставится знак '$' и имя нужного ссылающегося поля (не
имя constraint-а, т.е. внешнего ключа). Это также выглядит как новое имя
открывающего тега с символом '$' в середине имени (с. 24). Такое указание имени
ссылающегося поля также будем называть это термином 'детерминация'. Детерминация
должна быть указана в каждом из последовательно расположенных одноименных
xml-элементов - в т.ч. и в первом (чтобы пользователю меньше думать). В двух
разных видах детерминации использованы разные знаки - '#' и '$' - чтобы оба вида
детерминации можно было использовать одновременно: 'tag#field1$field2'
[5] Кроме того, превращение всех реляционных полей не в xml-аттрибуты, а в
xml-элементы подходит для браузера, но не подходит для mash-up сервисов и
всевозможных языков, основанных на XML
[6] Но ничего не стоит указать и реально не существующий, виртуальный внешний
ключ (vFK), как это показано на с. 118
[7] Если обе таблицы ссылаются друг на друга, или одна ссылается на другую
несколькими внешними ключами, то эта неоднозначность разрешается в запросе
дерева: после собственно имени таблицы, содержащей нужный внешний ключ, ставится
знак '#' и имя нужного ссылающегося поля (не имя constraint-а, т.е. внешнего
ключа). Выглядит как новое имя таблицы с символом '#' в середине имени (с.
36-37). Такое указание имени ссылающегося поля будем называть термином
'рафинирование'. Аналогично, если таблица содержит список и ссылается на саму
себя несколькими внешними ключами, то эта неоднозначность также разрешается в
запросе дерева: после собственно имени таблицы ставится знак '$' и имя нужного
ссылающегося поля (не имя constraint-а, т.е. внешнего ключа). Это также выглядит
как новое имя таблицы с символом '$' в середине имени (с. 38). Такое указание
имени ссылающегося поля также будем называть это термином 'рафинирование'. В
двух разных видах рафинирования использованы разные знаки - '#' и '$' - чтобы
оба вида рафинирования можно было использовать одновременно:
'table#field1$field2'
[8] Таким образом одно sql-выражение с обществом означает множество
sql-выражений с прозвищами. Кроме того, чтобы прозвища (с. 49), несколько
обществ или несколько упоминаний одного общества (с. 50) никогда не указали на
одну и ту же базу данных одновременно, поместим перед ними символ '%'; а чтобы
несколько упоминаний одного общества наоборот всегда синхронно указыли на одну и
ту же базу данных, поместим любое слово (одинаковое) и символ '%' перед этими
упоминаниями (с. 53-54)
[9] Предлагаю оформлять эти специальные команды в xml-виде как <?command/?>,
чтобы различать их и от sql-команд, и от xml-данных (традиционно оформляемых как
<element/>). Кроме того, предлагаю оператор 'POSTPONE' для заморозки на второй
стадии 2- и 3-стадийных 'COMMIT' (2PC и 3PC), и оператор 'ADJOURN' заморозки на
третей стадии 3-стадийных 'COMMIT' (3PC) (с. 60)


Тюрин Дмитрий