Второе дыхание 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. ......"