Второе дыхание SQL. Техническое ессе.

Dmitry67 · Post by **Dmitry67** » 19 Apr 2004 12:09

Adabas в настоящее время развалился на две ветки, одна поддеоживается SAP и называется SAP DB, другая вроде OpenSource но название я забыл

Обе стали чисто реляционными

Я работал с SAP DB, похож на облегченный Oracle.

potapych · Post by **potapych** » 19 Apr 2004 12:19

Dmitry67 wrote:Adabas в настоящее время развалился на две ветки, одна поддеоживается SAP и называется SAP DB, другая вроде OpenSource но название я забыл

Adabas D

Strannik223 · Post by **Strannik223** » 19 Apr 2004 19:08

f_evgeny wrote:
Sergey___K wrote:
Таблица - это самый эффективный инструмент для обработки большого количества данных, из тех которым располагает человечество.
Это не самый эффективный, это самый доступный и распространенный. И к ней можно все привести. Ну, и на бумаге, если ее не мять, только плоскую таблицу и сделаете. :)
ИМХО, таблица - самый "неестественный" способ хранения данных. Мир - он больше иерархический. Распластывая иерархию по таблицам и имеем, как следствие, канонический табличный JOIN вместо, ну, да пусть даже того же //a/b/c/[@att='val'].

- Я пишу про обработку, а не про хранение, если провести аналогию с предметным миром, то например можно представить себе три склада, на одном вещи свалены в кучу, на втором путь к каждой вещи - дерево, на третьем - полки с номерами, каждая вещь под номером. Где искать легче и быстрее?
На первом складе найти можно только случайно, на втором найти можно, но если надо найти несколько вещей, все время придется ходить по дереву, на третьем -находим нужные карточки в картотеке с дырочками и ходим по кратчайшим путям между полками с номерами нужных вещей.
- Мир бесконечен, разнообразие тоже, ресурсы - конечны. Необходимо упрощение. Талбица - это способ упрощения реальной картины мира, для того, чтобы упростить обработку этой картины.

Евгений, вы не поняли, Сергей приводил пример запроса на XPath, который выглядит намного более естественно для иерархий.

Именно дерево позволит вам на таком складе найти все детали по кратчайшему пути, ибо в плоской таблице будет указаны коордитаны искомой детали но не путь к ней из произвольной точки.

Любое упрощение делается от того что мозг человека ограничен, и не может представить абстракции любого уровня сложность. И любое упрощение страдает в той или иной мере тем что передает оригинал не полностью, и чем больше упрощение тем больше разница с реальным миром

Представление мира при помощи простых таблиц вовсе не упрощает решаемую задачу. А как раз наоборот. Если выбраны атомы конструктора который плохо приспособлен для данной предметной области то для воспроизведения сложной детали потребуется больше элементов и они будут в очень сложных взаимосвязях.

Как пример приведу типовую задачу: Начальник/Подчиненный, Предприятие/Отдел. Если вы что то такое реализовывали в SQL, то знаете что представление и операции над такими объектами в иерархиях логичными прозрачными и естественными никак не назовешь.

Palych · Post by **Palych** » 19 Apr 2004 19:29

Согласен со "Странник223".
Мне кажется что забвение древовидних баз было вызвано недостатком понятного человеку средства манипулировения данными, типа SQL. Теперь появился XPath & Co, и ето должно возвратить древовидные базы в игру.
С точки зрения хранения данных - думаю поначалу оптимизаторы возьмут на себя задачу по преобразованию деревьев в таблицы, пока не будет выдуман более еффективный способ хранения (если он вообще понадобится...)
Ведь если посмотреть на дизайн реальных приложений - даные практически всегда древовидные по природе, а задача дизайнеров - грамотно спроецировать дерево доменных обьектов на таблицы. Затем в дело вступают программисты, задача которых сделать обратное преобразование. Причем, будучи народом ленивым, они пытаются сделать етот процесс как можно более универсальным, навлекая гнев со стороны третьей стороны - админив....
Все ето порождает массу злобы и насилия в отношениях перечисленных сторон...

zVlad · Post by **zVlad** » 19 Apr 2004 20:26

http://www-306.ibm.com/software/data/ims/soap/

".......The IMS SOAP Gateway is an XML based connectivity solution that enables existing or new IMS applications to communicate outside of the IMS environment using SOAP to provide and request services independently of platform, environment, application language, or programming model.

The IMS SOAP Gateway enables the seamless exposure of IMS application assets as Web Services. The IMS SOAP Gateway, providing a relatively simple but extensible option, will provide the ability for non-WebSphere customers to re-use existing and to create new IMS-based business logic. One typical usage scenario of providing Web services with the IMS SOAP Gateway is to enable Microsoft .NET client applications or intermediary servers that submit SOAP requests into IMS to drive business logic transactions. ......"

Palych · Post by **Palych** » 19 Apr 2004 21:05

Молодцы ИБМ! Уважаю!
Кстати, еще одну особенность осознал: При update можно послать запрос на изменение одним куском, не демонстрируя клиенту органы отвечающие за транзакцию.
Если же нужно во время транзакции сделать что-то неривиальное (напр. добавить слова сообщения в поисковую базу) - можно написать триггер на XQuery/XSLT/Java/C#...

Sergey___K · Post by **Sergey___K** » 19 Apr 2004 21:10

The IMS SOAP Gateway enables the seamless exposure of IMS application assets as Web Services

Было бы странно, если бы фича, позволяющая избавиться от клиентских драйверов и "прочей ODBC", процессить все данные однообразно, как в казарме, оставалась незамеченной.
Смущает, однако, возможный майкрософтовский "особый путь" с XQuery. Если этого не произойдет и http://www.w3.org/TR/xquery/ стандарт будет уважен, все равно есть вопросы с расширяемостью, внешними функциями. Но, в общем, это лучший шанс говорить с разными базами на одном языке.
Кстати, кто не читал, не поленитесь, прочитайте линку. Удовольствие гарантировано.

testuser · Post by **testuser** » 19 Apr 2004 21:19

f_evgeny wrote:- Я пишу про обработку, а не про хранение, если провести аналогию с предметным миром, то например можно представить себе три склада, на одном вещи свалены в кучу, на втором путь к каждой вещи - дерево, на третьем - полки с номерами, каждая вещь под номером. Где искать легче и быстрее?

А если ето склад, на котором лежат детали для какого-то прибора. В иерархической базе достатотчно выбрать одну ветку и все детали у нас. В реляционнои нужно ходить по разным таблицам, делать join, etc.

Dmitry67 · Post by **Dmitry67** » 19 Apr 2004 21:47

Sergey__K
Это слишком формально для удовольствия
Похоже на пересмотренное сообщение об Алголе 68
Как сейчас помню фразу

Литерал вида 'вид' крепко содержащий букву алеф в себе и сильно выдающий пустое значение

f_evgeny · Post by **f_evgeny** » 20 Apr 2004 05:51

Strannik223 wrote:
f_evgeny wrote:
Sergey___K wrote:
Таблица - это самый эффективный инструмент для обработки большого количества данных, из тех которым располагает человечество.
Это не самый эффективный, это самый доступный и распространенный. И к ней можно все привести. Ну, и на бумаге, если ее не мять, только плоскую таблицу и сделаете.
ИМХО, таблица - самый "неестественный" способ хранения данных. Мир - он больше иерархический. Распластывая иерархию по таблицам и имеем, как следствие, канонический табличный JOIN вместо, ну, да пусть даже того же //a/b/c/[@att='val'].

- Я пишу про обработку, а не про хранение, если провести аналогию с предметным миром, то например можно представить себе три склада, на одном вещи свалены в кучу, на втором путь к каждой вещи - дерево, на третьем - полки с номерами, каждая вещь под номером. Где искать легче и быстрее?
На первом складе найти можно только случайно, на втором найти можно, но если надо найти несколько вещей, все время придется ходить по дереву, на третьем -находим нужные карточки в картотеке с дырочками и ходим по кратчайшим путям между полками с номерами нужных вещей.
- Мир бесконечен, разнообразие тоже, ресурсы - конечны. Необходимо упрощение. Талбица - это способ упрощения реальной картины мира, для того, чтобы упростить обработку этой картины.

Евгений, вы не поняли, Сергей приводил пример запроса на XPath, который выглядит намного более естественно для иерархий.

Именно дерево позволит вам на таком складе найти все детали по кратчайшему пути, ибо в плоской таблице будет указаны коордитаны искомой детали но не путь к ней из произвольной точки.

Любое упрощение делается от того что мозг человека ограничен, и не может представить абстракции любого уровня сложность. И любое упрощение страдает в той или иной мере тем что передает оригинал не полностью, и чем больше упрощение тем больше разница с реальным миром

Представление мира при помощи простых таблиц вовсе не упрощает решаемую задачу. А как раз наоборот. Если выбраны атомы конструктора который плохо приспособлен для данной предметной области то для воспроизведения сложной детали потребуется больше элементов и они будут в очень сложных взаимосвязях.

Как пример приведу типовую задачу: Начальник/Подчиненный, Предприятие/Отдел. Если вы что то такое реализовывали в SQL, то знаете что представление и операции над такими объектами в иерархиях логичными прозрачными и естественными никак не назовешь.

1. Эффективность, в общем случае, это и есть результат/затраченные ресурсы.
2. С какой стати дерево дает кратчайший путь? Дерево надо обходить по ветвям. А в таблице, спроецированной на плоскость, расстояние = sqr(x^2+y^2), направление - arccos(y/x). Посчитали, и по прямой. которая есть кратчайшее расстояние, от одной детали к другой.
3. Подчиненные и начальники укладываются в таблицу легко (ИМХО). Проблема, как раз в том, что это деревья.

f_evgeny · Post by **f_evgeny** » 20 Apr 2004 06:08

testuser wrote:
f_evgeny wrote:- Я пишу про обработку, а не про хранение, если провести аналогию с предметным миром, то например можно представить себе три склада, на одном вещи свалены в кучу, на втором путь к каждой вещи - дерево, на третьем - полки с номерами, каждая вещь под номером. Где искать легче и быстрее?

А если ето склад, на котором лежат детали для какого-то прибора. В иерархической базе достатотчно выбрать одну ветку и все детали у нас. В реляционнои нужно ходить по разным таблицам, делать join, etc.

Извините, но это не так.
- Разные таблицы нужны для того, чтобы максимально гарантировать целостность данных. Это внутренне дело базы. Мой пойнт в том, что результат реляционной базы, это всегда плоская таблица. И как раз для плоских таблиц есть развитый инструментарий для массовой обработки. Или если детализовать, плоская таблица в компьютере - это массив. Для массива достаточно сделать процедуру обработки и потом повторить ее в цикле N-раз.
А для деревьев такого простого пути нет. Не зря, программ обработки информации в виде таблиц, я бы сказал, на порядки больше, чем в виде деревьев.
И подготовка информации в виде деревьев, как правило требует индивидуального ручного труда, в отличие от.
Вернемся к аналогии со складом. Это сказать легко: "Берем дерево с информацией о приборе". На практике это значит взять документацию на прибор и извлечь оттуда информацию об узлах и деталях, из которых собран прибор. В жизни делают как раз по другому - документация на прибор ОБЯЗАТЕЛЬНО! включает в себя спецификацию - таблицу с перечьнем детале. Теперь раз есть таблица - все легко. Простой join спецификации и таблицы размещения деталей на складе и у нас на руках таблица, с перечнем деталей прибора и их координатами на складе.
Теперь расскажите, как это делать, если у Вас на руках два дерева, дерево узлов и деталей прибора и дерево склада? Задача сразу становится нетривиальной.
Лично я знаю только один подход, реализующий не табличный подход к обработке большого количества информации - нейронные сети. Но и то по-настоящему больших успехов по обработке большого количества данных, там пока не видно.

Sergey___K · Post by **Sergey___K** » 20 Apr 2004 15:41

Теперь расскажите, как это делать, если у Вас на руках два дерева, дерево узлов и деталей прибора и дерево склада? Задача сразу становится нетривиальной.

Вы на линку ходили?

Strannik223 · Post by **Strannik223** » 20 Apr 2004 16:56

f_evgeny wrote:1. Эффективность, в общем случае, это и есть результат/затраченные ресурсы.
2. С какой стати дерево дает кратчайший путь? Дерево надо обходить по ветвям. А в таблице, спроецированной на плоскость, расстояние = sqr(x^2+y^2), направление - arccos(y/x). Посчитали, и по прямой. которая есть кратчайшее расстояние, от одной детали к другой.
3. Подчиненные и начальники укладываются в таблицу легко (ИМХО). Проблема, как раз в том, что это деревья.

1. Результат это константа. Раз надо что то получить, значит это не обсуждается. Ресурсы есть 2-х типов: машинные и трудоресурсы на создание и последующую модификацию алгоритмов. Но это не по теме беседы.
2. Дерево легко сделать так что бы оно отображало физическое расположение и путь к деталям. Ваше уравнение просто смшно. У вас есть коордитаты но нет информации о пути. Вы поговорку о том что кратчайший путь не всегда быстрейший слышали? Если мы говорим о физической модели то что вам даст информация о том что следующая искомая деталь находися 30град. зюйд-вест? Вы сквозь стены ходить будете?

3. Евгений, я замечаю что у вас все очень легко, как два байта переслать. В качестве упражнения попробуйте сделать структуру таблицы и выборку всех подчиненных для Начальник/Подчиненный, только не упрощайте пожалуйста, а помните что у кождого начальника есть начальник над ним, и таким образом каждый сотрудник может быть и начальником и подчиненным.
После этого мы поговорим насколько то что получилось естественно.

8K · Post by 8K » 20 Apr 2004 17:44

Strannik223 wrote:помните что у кождого начальника есть начальник над ним

Все мы под богом ходим.

Dmitry67 · Post by **Dmitry67** » 20 Apr 2004 18:06

8K wrote:
Strannik223 wrote:помните что у кождого начальника есть начальник над ним

Все мы под богом ходим.

Всегда есть root folder