Re[2]: [pgsql-ru-general] Приведение СУБД в соответствие современным коммуникационным требованиям - 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'.

[1] http://sql50.euro.ru/sql5.16.4.pdf
[2] http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00004.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)

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

Hi, Yuriy.

> Такие письма наводят на мысль задать всякие глупые вопросы.
>> *) выводить 3-мерные конструкции из базы данных на экран (конвертировать в формат
>> и протокол X11)
> А почему это должна делать БД, а не клиентский софт ?

"дабы программа,
обратившаяся к этому движку, могла отправлять полученные данные своему
X-серверу без каких-либо собственных вычислений или изменений (без обращения
к OpenGL, DirectX"

http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php

>> *) предоставлять ввод из браузера (настроить проприетарный веб-сервер конкретной
>> СУБД)
> А почему обязательно проприетарный, открытый веб-сервер apache в
> связке с php, python, etc. справляется на ура.

написать свою прокладку:

1) рядовому пользователю сложнее, чем настроить http-сервер
2) для программиста означает дополнительную работу

>> *) копировать информацию из удаленной базы данных (использовать другие источники
>> информации для создания собственного mash-up сервиса)

Здесь вопросов нет ?

>> *) несколько раз включить и выключить ноутбук в течение одной длинной транзакции,
>> длящейся дни или даже недели
> И что за транзакция, которая длится сутками и при этом не имеет точек
> останова-возобновления ?

Процитируйте, где сказано, что не имеет ?

Должно быть, вы имели ввиду другой вопрос: какие транзакции длятся сутками ?
Как сказано в послании :) , например те, в которых отсоединен клиент (ноутбук).

Dmitry (SQL50, HTML60)

Hi, Dmitry !
>> А почему это должна делать БД, а не клиентский софт ?
>
> "дабы программа,
> обратившаяся к этому движку, могла отправлять полученные данные своему
> X-серверу без каких-либо собственных вычислений или изменений (без обращения
> к OpenGL, DirectX"

Я правильно понял, что речь не идет о том, что сама БД должна
отправить данные непосредственно на X-server ? Исходя из предыдущего
поста это не очевидно. И ИМХО не дело это базы, отрисовывать данные на
клиенте.

>
> http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php
>
>>> *) предоставлять ввод из браузера (настроить проприетарный веб-сервер конкретной
>>> СУБД)
>> А почему обязательно проприетарный, открытый веб-сервер apache в
>> связке с php, python, etc. справляется на ура.
>
> написать свою прокладку:
>
> 1) рядовому пользователю сложнее, чем настроить http-сервер
> 2) для программиста означает дополнительную работу
>

На вопрос, почему обязательно проприетарный веб-сервер, почему не
пользовать открытый, ответ не получен, поясню отличие проприетарного
софта от открытого состоит в лицензировании, а не в технической
стороне дела.

>>> *) несколько раз включить и выключить ноутбук в течение одной длинной транзакции,
>>> длящейся дни или даже недели
>> И что за транзакция, которая длится сутками и при этом не имеет точек
>> останова-возобновления ?

ИМХО правильнее заменить слово "ноутбук" на "компьютер".
> Должно быть, вы имели ввиду другой вопрос: какие транзакции длятся сутками ?

ну да.

--
Best regards,
Sincerely yours,
Yuriy Rusinov.

Hi, Yuriy.

>>> А почему это должна делать БД, а не клиентский софт ?
>> "дабы программа,
>> обратившаяся к этому движку, могла отправлять полученные данные своему
>> X-серверу без каких-либо собственных вычислений или изменений (без обращения
>> к OpenGL, DirectX"
> речь не идет о том, что сама БД должна
> отправить данные непосредственно на X-server ?

Нет, СУБД отправляет клиенту (он пересылает своему X-серверу).

> не дело это базы, отрисовывать данные на клиенте

Т.е. ваша позиция:
1) рендерить должна не СУБД, а программист вручную, вызывая функциии OpenGL или DirectX
2) пространственные данные должны храниться в двух БД: в реляционной и в OpenGL (DirectX)

Хотелось бы услышать аргументы в защиту этих двух пунктов.

>> http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php
>>>> *) предоставлять ввод из браузера (настроить проприетарный веб-сервер конкретной
>>>> СУБД)
>>> А почему обязательно проприетарный, открытый веб-сервер apache в
>>> связке с php, python, etc. справляется на ура.
>> написать свою прокладку:
>> 1) рядовому пользователю сложнее, чем настроить http-сервер
>> 2) для программиста означает дополнительную работу
> почему не пользовать открытый

Мое предложение состоит не в отказе от лицензированного http-сервера в пользу фришного,
а в отказе от любого http-сервера.

Dmitry (SQL50, HTML60)

Hi, Dmitry !

> Т.е. ваша позиция:
> 1) рендерить должна не СУБД, а программист вручную, вызывая функциии OpenGL или DirectX
> 2) пространственные данные должны храниться в двух БД: в реляционной и в OpenGL (DirectX)
>
> Хотелось бы услышать аргументы в защиту этих двух пунктов.

1. Как должна действовать БД, если к ней обращаются пользователи с
разными платформами, например один рисует средствами OpenGL, другой
DirectX, третий cairo, ...,
2. Вася хочет отрисовать окружность сплошной красной линией, а Петя ту
же окружность синим пунктиром и таких пользователей очень много.

И ещё вопрос, для каких задач это все делалось, проверялось или речь
идет о сферическом коне в вакууме.

--
Best regards,
Sincerely yours,
Yuriy Rusinov.

Hi, Yuriy.

>> Т.е. ваша позиция:
>> 1) рендерить должна не СУБД, а программист вручную, вызывая функциии OpenGL или DirectX
>> 2) пространственные данные должны храниться в двух БД: в реляционной и в OpenGL (DirectX)
>> Хотелось бы услышать аргументы в защиту этих двух пунктов.
> 1. Как должна действовать БД, если к ней обращаются пользователи с
> разными платформами

Разные платформы - это X11 vs. Microsoft Window System.
СУБД должна отправлять данные в формате платформы-получателя,
т.е. если клиент под Иксами, то в формате иксов,
если клиент под виндой, в формате винды.

> , например один рисует средствами OpenGL, другой
> DirectX, третий cairo, ...,

Эти библиотеки остаются незадействованными.

> 2. Вася хочет отрисовать окружность сплошной красной линией, а Петя ту
> же окружность синим пунктиром и таких пользователей очень много.

1) пользователь не рисует объект - объект хранится в БД
2) значения полей заменяются в SELECT-e

> И ещё вопрос, для каких задач это все делалось

"Все ранее известные 3D-интерфейсы (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) разработаны
с расчетом на некие когнитивные способности, которыми, как показывают эксперименты,
средний человек на самом деле не обладает. Tрудности, связанных с использованием 3D-объектов,
возникает из-за низкого качества интерфейса, а не из-за сложности трехмерной задачи."

http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php

> , проверялось

Укажите процедуру проверки, я скажу, выполнялась она или нет.

Dmitry (SQL50, HTML60)

Hi, Dmitry !

>>> Т.е. ваша позиция:
>>> 1) рендерить должна не СУБД, а программист вручную, вызывая функциии OpenGL или DirectX
>>> 2) пространственные данные должны храниться в двух БД: в реляционной и в OpenGL (DirectX)
>>> Хотелось бы услышать аргументы в защиту этих двух пунктов.
Вот аргументы

1. Отрисовка делается на некотором виджете с заданными размерами,
палитрой, разрешением, etc, известными клиенту, а сервер о них знать
не может и не должен.
2. OpenGL -- это не база данных, это метод отрисовки чего-л.
> Разные платформы - это X11 vs. Microsoft Window System.
> СУБД должна отправлять данные в формате платформы-получателя,
> т.е. если клиент под Иксами, то в формате иксов,
> если клиент под виндой, в формате винды.

СУБД получается должна узнавать, какая платформа у пользователя,
размеры виджета отрисовки, масштабирование, палитру.
>> , например один рисует средствами OpenGL, другой
>> DirectX, третий cairo, ...,
>
> Эти библиотеки остаются незадействованными.
>
> 1) пользователь не рисует объект - объект хранится в БД
> 2) значения полей заменяются в SELECT-e
>
>> И ещё вопрос, для каких задач это все делалось

Вопрос остался не отвеченным.
>
> "Все ранее известные 3D-интерфейсы (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) разработаны
> с расчетом на некие когнитивные способности, которыми, как показывают эксперименты,
> средний человек на самом деле не обладает.

Что за эксперименты и какие способности ?
>> , проверялось
>
> Укажите процедуру проверки, я скажу, выполнялась она или нет.

Сравнить производительность при отрисовке средствами БД и OpenGL.

--
Best regards,
Sincerely yours,
Yuriy Rusinov.

Hi, Yuriy.

>>>> Т.е. ваша позиция:
>>>> 1) рендерить должна не СУБД, а программист вручную, вызывая функциии OpenGL или DirectX
>>>> 2) пространственные данные должны храниться в двух БД: в реляционной и в OpenGL (DirectX)
>>>> Хотелось бы услышать аргументы в защиту этих двух пунктов.
> 1. Отрисовка делается на некотором виджете с заданными размерами,
> палитрой, разрешением, etc, известными клиенту, а сервер о них знать
> не может

Ваше возражение:
"В случае, если рендерить будет СУБД, ей потребуется запросить у клиента размеры, палитру и разрешение экрана".
Ответ:
Не потребуется, т.к. формат X11 векторный, пригодный для масштабирования на клиенте,
а следовательно размеры и разрешение экрана не нужны.
Палитра, как замена цветов, не нужна пользователю.

P.S.
1) Если масштабирование данных из формата X11 невозможно,
каких возможностей формата для этого не хватает?
2) Чем запрос со стороны СУБД о размерах, палитре, и разрешении плох ?
Если такие причины указаны, почему наличие этого запроса от OpenGL, DirectX терпимо, от СУБД - нетерпимо.

> 2. OpenGL -- это не база данных

Ваше возражение: "OpenGL не хранит данные".
Ответ: хранит, и использует их для перерисовки при повороте и сдвиге.

>> Разные платформы - это X11 vs. Microsoft Window System.
>> СУБД должна отправлять данные в формате платформы-получателя,
>> т.е. если клиент под Иксами, то в формате иксов,
>> если клиент под виндой, в формате винды.
> СУБД получается должна узнавать, какая платформа у пользователя

Да.

>>> И ещё вопрос, для каких задач это все делалось
> Вопрос остался не отвеченным.

Цитирую по http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00013.php

"дабы программа,
обратившаяся к этому движку, могла отправлять полученные данные своему
X-серверу без каких-либо собственных вычислений или изменений (без обращения
к OpenGL, DirectX"
http://archives.postgresql.org/pgsql-ru-general/2008-12/msg00010.php

Конец цитаты.

>> "Все ранее известные 3D-интерфейсы (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) разработаны
>> с расчетом на некие когнитивные способности, которыми, как показывают эксперименты,
>> средний человек на самом деле не обладает.
> Что за эксперименты

повседневные наблюдения за рядовыми пользователями

> и какие способности ?

вот у проектировщиков 3DMLW, 3DXML, COLLADA / OpenGL, DirectX и спросите

>>> , проверялось
>> Укажите процедуру проверки, я скажу, выполнялась она или нет.
> Сравнить производительность при отрисовке средствами БД и OpenGL.

Юрий, вы с головой дружите? Фича в СУБД еще не реализована!

Dmitry (SQL50, HTML60)