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

f_evgeny · Post by **f_evgeny** » 18 Apr 2004 19:56

Merle wrote:Ну нет. Я с трудом могу представить себе систему в которой надо одновременно вытягивать из хранилища больше нескольких сотен объектов.

Ну, к примеру, графики метеоданных за несколько суток, или за год, налогоплательщики города.
В моем представлении там, где обработка идет по 10-100 объектов, и база-то не нужна.

tengiz · Post by **tengiz** » 18 Apr 2004 21:12

f_evgeny wrote:Ну, к примеру, графики метеоданных за несколько суток, или за год, налогоплательщики города. В моем представлении там, где обработка идет по 10-100 объектов, и база-то не нужна.

Обработка объекта в базе и вытягивание объекта из базы для обработки другой программой - это разные вещи. Современные СУБД тем и хороши, что отлично научились делать массовые операции внутри. Без накладных расходов на пересылку туда-сюда, когда в крайних случаях собственно пересылка занимала бы львиную долю времени и ресурсов. Умение свести обработку, необходимую приложению, к оптимальной серии высокоурвневых операторов манипуляции данными для которых в любой приличной СУБД есть высокоэффиктивная физическая реализация - важная составная часть искусства программирования приложений баз данных.

f_evgeny · Post by **f_evgeny** » 18 Apr 2004 21:18

tengiz wrote:
f_evgeny wrote:Ну, к примеру, графики метеоданных за несколько суток, или за год, налогоплательщики города. В моем представлении там, где обработка идет по 10-100 объектов, и база-то не нужна.

Обработка объекта в базе и вытягивание объекта из базы для обработки другой программой - это разные вещи. Современные СУБД тем и хороши, что отлично научились делать массовые операции внутри. Без накладных расходов на пересылку туда-сюда, когда в крайних случаях собственно пересылка занимала бы львиную долю времени и ресурсов. Умение свести обработку, необходимую приложению, к оптимальной серии высокоурвневых операторов манипуляции данными для которых в любой приличной СУБД есть высокоэффиктивная физическая реализация - важная составная часть искусства программирования приложений баз данных.

Ясное дело, что в эффективной системе должен быть грамотно выбрано разделение, что делаем в базе, а что - в приложении.
Моя мысль в том, что для больших объемов данных естественная форма работы с ними - таблица.

tengiz · Post by **tengiz** » 18 Apr 2004 21:30

f_evgeny wrote:Моя мысль в том, что для больших объемов данных естественная форма работы с ними - таблица.

Мысль вполне понятна, возразить мне особенно нечего. Хотя с моего уровня внутренностей СУБД реальность видна несколько более абстрактро, чем простая прямоугольная таблица. Я конечно не говорю, что это абсолютно всё равно - о таблицах или иерархиях идёт речь. Но тем и хороша обработка транзакций - что хочешь в такой системе, то и хранишь. Гарантии по целостности и изоляции данных не зависят от того, что в этом мешке с байтами - XML, объект или строка таблицы. Собственно реляционность начинается уровнем выше и совершенно не зависит от того, как устроена подсистема хранения и обработки транзакций. Так уж получилось, что эффективные алгоритмы и выразительный (хоть и не без досадных недостатков) язык манипуляции данными удалось получить именно для прямоугольных таблиц. Но это же не значит, что для объектов и иерархий это невозможно?

vc · Post by vc » 18 Apr 2004 21:46

tengiz wrote:...Так уж получилось, что эффективные алгоритмы и выразительный (хоть и не без досадных недостатков) язык манипуляции данными удалось получить именно для прямоугольных таблиц. Но это же не значит, что для объектов и иерархий это невозможно?

"Many have tried, all have failed" ;)

VC

zVlad · Post by **zVlad** » 19 Apr 2004 01:35

f_evgeny wrote:..........
Моя мысль в том, что для больших объемов данных естественная форма работы с ними - таблица.

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

Когда появилась ДВ2 у ИБМ уже существовала иерархическая база данных IMS. На первых порах ДБ2 не считалась пригодной для построения больших баз данных с высокими требованиями к надежности и производительности в OLTP системах. По началу ДБ2 позиционировалась в DSS приложениях. Лишь к концу 80-х ДБ2 была достаточно улучшена чтобы конкурировать с IMS.

Что интересно приложения на IMS существуют и я думаю не плохо существуют и развиваются. Недавно ИБМ выпустила 9-ую версию IMS, и нет никаких намеков на сворачивание этих работ.

f_evgeny · Post by **f_evgeny** » 19 Apr 2004 05:47

zVlad wrote:
f_evgeny wrote:..........
Моя мысль в том, что для больших объемов данных естественная форма работы с ними - таблица.

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

Когда появилась ДВ2 у ИБМ уже существовала иерархическая база данных IMS. На первых порах ДБ2 не считалась пригодной для построения больших баз данных с высокими требованиями к надежности и производительности в OLTP системах. По началу ДБ2 позиционировалась в DSS приложениях. Лишь к концу 80-х ДБ2 была достаточно улучшена чтобы конкурировать с IMS.

Что интересно приложения на IMS существуют и я думаю не плохо существуют и развиваются. Недавно ИБМ выпустила 9-ую версию IMS, и нет никаких намеков на сворачивание этих работ.

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

Sergey___K · Post by **Sergey___K** » 19 Apr 2004 07:12

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

Это не самый эффективный, это самый доступный и распространенный. И к ней можно все привести. Ну, и на бумаге, если ее не мять, только плоскую таблицу и сделаете.

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

f_evgeny · Post by **f_evgeny** » 19 Apr 2004 07:24

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

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

zVlad · Post by **zVlad** » 19 Apr 2004 12:05

А вот еще есть базы данных IDMS и Adabas. В них поддерживаются множественные атрибуты и периодические группы, что гораздо полее полно соответствует "бумажным" таблицам. В обеих поддерживается 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