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

Merle · Post by **Merle** » 18 Apr 2004 14:45

f_evgeny wrote: В пределе, мне это видится так, реляционные - это где данные организованны в виде таблиц, объектные - в виде дерьевьев.

Не совсем, все-таки не в виде деревьев, а в виде иерархии объектов. Упрощать это дело до деревьев все-таки нельзя.

f_evgeny wrote: Чем хороши таблицы, и чем плохи деревья?
Предположим, что мы имеем много данных, лежит перед нами такая большая куча объектов. Как мы будем с ними разбираться? Простой, рабоче-крестьянский подход говорит следующее - выделяем набор признаков, совокупность которых определяет объект. Что получилось? Правильно, таблица, в которой строки соответствуют объектам, столбцы - признакам.
Теперь попробуем ту же самую кучу проклассифициоровать при помощи деревьев. Получаем в пределе для каждого объекта свое дерево признаков. И как теперь с этим $*#*: разбираться?

Нет, разбираься-то как раз проще всего с объектами. В идеале вообще не надо будет переводить объект в проскую таблицу и обратно.
Скажем Запрос в объектной системе мог бы выглядеть примерно так:

Code: Select all

    IEmployer CompanyEmployer = new (SELECT IEmployer Emp WHERE Emp.Salary>1000 AND (IManager)Emp.IsCustomer('Microsoft'))

На выходе я получил бы коллекцию объектов типа IEmployer, содержащюю всех менеджеров занимающихся MS, с окладом больше штуки. При этом никокой ORM и прочая низкоуровневая лабуда не тревожила бы вообще никого - у меня есть уже готовый объект или коллекция объектов нужного типа, с которой я могу делать вообще все что угодно.
Но на сколько я себе представляю, на данном этапе развития БД это невозможно реализовать с приемлемой скоростью.
Хотя бы потому, что это сходу упирается в невозможность использовать индексы. Внутренняя реализация метода IsCustomer недоступна ввиду инкапсуляции, а значит невозможно предположить результат вызова этого метода если не вызвать его явно для каждого объекта.
Теоретически, можно придумать хитрые метаданные, описывающие методы и строить индексы на основе этих метаданных, но это не самый простой путь и об удачных реализациях я не слышал.
Далее, то же приведение типов, а-ля (IManager)Emp, радости индексам опять-таки не добавит.
И так далее, вообщем куда не плюнь - всюду проблемы.
Поэтому пока и рулит реляционный движек. С одной стороны он очень универсален, а с другой - обладает на редкость хорошей производительностью.

zVlad · Post by **zVlad** » 18 Apr 2004 15:04

smitin wrote:Не знаю, что там неправильно с SQL, но пока дисковое хранение данных никто не отменял. Если только не придумают чего-то столь же емкого, но гораздо более быстрого, то все тысячи воображаемых процессоров будут стоять с протянутой рукой к одному скази драйверу. И ни о каком соотношении 1 процессор - 1 запись речь идти не может......

Может, имеет место быть и всегда так было на МФ. С сотней каналов ввода-вывода и тысячами диском достигается соотношение 1 процессор - много записей/чтений одновременно.

f_evgeny · Post by **f_evgeny** » 18 Apr 2004 17:01

Merle wrote:
f_evgeny wrote: В пределе, мне это видится так, реляционные - это где данные организованны в виде таблиц, объектные - в виде дерьевьев.

Не совсем, все-таки не в виде деревьев, а в виде иерархии объектов. Упрощать это дело до деревьев все-таки нельзя.

Не совсем понимаю, абстрагируйтесь от ООП, мы же про организацию данных.
Моя мысль примерно такая, когда данных много, их надо систематизировать. Систематизацию больших объемов данных (в самом общем виде) лично я могу себе представить только в виде таблиц.
Есть другие виды организации - древовидные. Иерархия - это тоже древовидная организация, деревья ведь вовсе не обязательно должны быть бинарными.
Примеры табличной организации данных, например бухгалтерские записи, прейскуранты, массивы в программировании и т.д.
Примеры древовидной организации данных - оглавление книги, всевозможные классификации, дерево иерархии объектов программы в ООП.
Можно заметить, что как только объектов данных становиться много, становиться удонее с ними работать, применяя к ним таблицы.
Возьмем теперь Ваш пример с объектами. Все, что Вы получаете, легко получить, если объекты лежат в таблице с колонками "Занимается MS" и "Величина оклада". Таблицу можно легко обработать в цикле, используя одну и ту же процедуру и инструментальные средства, в том числе и индексы.
Но предположим, Вы организовали эти же данные в виде деревьев (обектов), как Вы их собираетесь обрабатывать? Когда их например 10^9. Ну предположим обработали, выбрали то, что надо, получили 10^4 объектов. Как теперь с ними разбираться?
В общем мой взгляд на эти вещи такой. Когда в данных имеется >10-100 объектов, хочешь не хочешь, надо запихивать эти данные в таблицу. Иначе кирдык.

vc · Post by vc » 18 Apr 2004 18:13

tengiz wrote:Самая главная претензия - операции языка SQL не является замкнутыми, т.е. производя манипуляции над множествами строк вы необязательно на выходе получите множество строк когда результатом операции не является скаляр. Самый яркие примеры, на мой взгляд, - необходимость иметь ключевое слово DISTINCT и наличие UNION ALL. Да, имейте в виду - я ничего не имею против SQL как языка практичекого программирования доступа к реляционным базам данных (как впрочем и против Вижуал Бейзика), но не нужно путать практическую полезность и удобство (которым наплевать на индукцию с дедукцией) с формальной чистотой.

The relational calculi are based on the first-order (predicate) logic and SQL itself is based, loosely speaking, on the relational calculus (TRC). Whilst SQL is not "closed" in the same sense as its relational algebra interpretion operations are, it's likely to be "relationally complete". However, one can limit oneself to a carefully chosen SQL subset (avoiding nulls and duplicates) which will be "closed".

The primary motivation for letting SQL operate with bags(multisets) rather than with sets was (and still is) efficiency. The state-of-the-art in the quasi-relational database technology is such (stone age) that the decision appears to have been a reasonable engineering compromise.

All this being said, SQL whilst being a useful practical tool, as a language, has a host of problems:

o lack of support for hierarchical queries;

o syntactical inconsistency (e.g. the expression a join b is allowed but a union b is illegal, a and b being relations);

o redundancy (e.g. the HAVING clause);

o impossibility to split a complex query into manageable named pieces (the WITH clause partially corrects it);

o unnecessary COBOL-like verbosity;

etc, etc...

In brief, as someone said, Structured Query Language is neither language nor structured. There are some weak attempts to offer alternative "truly relational" language(s) (see "The Third Manifesto" by Date et al; www.alphora.com) which most likely will fail due to lack of interest from industry and the universally exhibited ignorance of practitioners of the trade.

VC

Merle · Post by **Merle** » 18 Apr 2004 19:47

f_evgeny wrote:Не совсем понимаю, абстрагируйтесь от ООП, мы же про организацию данных.

Не, про ООП не я первый заговорил.

Либо ООП, либо иерархия, просто объекты до банальной иерархии сводить нельзя, не так удобно получается.

f_evgeny wrote:Моя мысль примерно такая, когда данных много, их надо систематизировать. Систематизацию больших объемов данных (в самом общем виде) лично я могу себе представить только в виде таблиц.

Да в каком угодно виде, систематезировать их будет машина, а она железная, ей все равно...

f_evgeny wrote:Примеры табличной организации данных, например бухгалтерские записи, прейскуранты, массивы в программировании и т.д.

Их тоже можно свести к иерархии, как и наоборот - дело не в этом.

f_evgeny wrote:Можно заметить, что как только объектов данных становиться много, становиться удонее с ними работать, применяя к ним таблицы.

Нет, это не так. Даже сейчас на некоторых задачах иерархические хранилища работают в разы производительнее и в разы проще под них разрабатывать. Только вот задач этих мало..

f_evgeny wrote:Возьмем теперь Ваш пример с объектами. Все, что Вы получаете, легко получить, если объекты лежат в таблице с колонками "Занимается MS" и "Величина оклада". Таблицу можно легко обработать в цикле, используя одну и ту же процедуру и инструментальные средства, в том числе и индексы.

Обработать да, а вот получить - нет. Получить в разы сложнее, надо выбрать это дело из плоской таблицы, разложить по полям объекта выполнив ряд преобразований и проверок, и то же самое, в обратном порядке, надо сделать при сохранении... Головная боль та еще...

f_evgeny wrote:Но предположим, Вы организовали эти же данные в виде деревьев (обектов), как Вы их собираетесь обрабатывать?

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

f_evgeny wrote:Когда их например 10^9. Ну предположим обработали, выбрали то, что надо, получили 10^4 объектов. Как теперь с ними разбираться?

Ээээ стоп, от выборки 10^4 объектов и реляционной системе поплохеет. Должно быть что-то сильно не так в системе, если требуется отбирать такое количество объектов.

f_evgeny wrote:
В общем мой взгляд на эти вещи такой. Когда в данных имеется >10-100 объектов, хочешь не хочешь, надо запихивать эти данные в таблицу. Иначе кирдык.

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

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
Реляционные базы хороши, Евгений, но не тем что хороши для больших объемов, а тем что в них есть теория моделирования (нормализация) и что структура может быть модифицированна легко, и что-нибудь еще, но не способность управлять большими объемами, которой располагают и другие базы.