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

JustMax · Post by **JustMax** » 20 Apr 2004 19:38

Strannik223 wrote:После этого мы поговорим насколько то что получилось естественно.

CONNECT BY PRIOR START WITH ? :pain1:

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

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

Разместить-то легко, а вот достать не очень, поскольку информация "деревянная". Но этого-то как раз я и не обещал. Точнее, методов реляционной алгебры не хватает, придется обходить деревья в циклах.
А разместить - пожалуйста.
CREATE TABLE all_the_people (id int4,boss int4,name varchar 32)
Получить информацию обо всех подчиненных данного босса:
<pre>
$boss_id = <boss_id>;
@bosses = array($boss_id);
@all_subordinates = array();
@level_subordinates = array();
$all_done = 0;
while(!all_done) {
foreach $boss (@bosses) {
@subordinates=(SELECT id WHERE boss_id=$boss);
if(is_emty(@subordinates)) {
$all_done = 1;
}
@level_subordinates = join_arrays(@level_subordinates,@subordinate);
}
@all_subordinates = join_array(@all_subordinates,@level_subordinates);
@bosses = @level_subordinates;
@level_subordinates = array();
}
Получается сложно как раз потому, что информация "деревянная". Для таблиц как правило хватает реляционной алгебры.

f_evgeny · Post by **f_evgeny** » 20 Apr 2004 20:50

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

Вариант 2, реляционный. Предположим, что количество уровней подчинения конечно. Тогда:
CREATE TABLE all_the_people (id int4,level0 int4,level1 int4,level2 int4,....,levelN int4,name varchar 32) ,
где для каждой записи в поле levelN указан начальник уровня levelN, тогда получить всех подчиненных для данного человека можно простым селектом:
SELECT name WHERE id=person_id AND levelN = boss_id;

oMoses · Post by **oMoses** » 20 Apr 2004 22:02

Кажется, я немного запоздал и подоспел лишь к шапочному разбору. А интересная дискуссия получилась, однако! Не взирая на многочисленные попытки сведения её в сугубо техническую плоскость, без более широкого взгляда на вещи здесь не обойтись. Речь идет о философии, как инструменте познания пока еще неведомого нам.

Позволю вернуться к оригинальному эссе от Димы67, где в финале зримо проглядывает этакий прообраз Матрицы, появление которой автором предсказывается уже к 2010 году. А вообще, как далеко мы пытаемся заглянуть в будущее? 10 лет? 50?? Сто???

Смею предположить, что наша дискуссия еще будет иметь какой-то смысл в рамках ближайшего полувека. Что будет после 2100 года (и будет-ли жив старикашка SQL, главный предмет авторского анализа) - сиё нам не ведомо. Но очень подозреваю, что сами по себе способы переработки информации изменятся настолько кардинально, что не оставят и камня на камне от всем нам привычного SQL.

Более того, к тому моменту и сама информация (т.е. данные), за ради перелопачивания и усвоения которых, собственно и были придуманы базы данных с языками запросов к ним, станет чудовищно более многообразней. А это поставит перед базами данных совсем иные рубежи.

Неизбежное влияние на предмет нашего обсуждения окажет и прогресс в области интерфейсов, поскольку он (язык SQL) есть неотделимая часть механизма нашего общения с базами данных.

Клавиатура, мышка, командная строка неизбежно вымрут, вытесненные системами распознавания речи и непосредственного ввода информации в компьютер из человеческого мозга. Но если больше не нужно будет в SQL*Plus набирать s e l e c t и т.д. пальцами и побуквенно, неужели вы думаете, что и сам SQL будет все еще состоять из набора синтаксических конструкций?

Быть может эти мои последующие строки, будучи запущенными в Сеть и ставшими её неотъемлемой частью, изменят будущее - нам с вами узнать это не уже прийдется, и тем не менее IMHO, вот то что можно предсказать уже сейчас:

future-DB и future-SQL после 2100 года:
1. Базы данных, как механизм организации, хранения и обработки информации всегда были есть и будут.
2. Раз всегда будут future-DB, то всегда будет и средства общения с ними - future-SQL.
3. Объемы данных future-DB будут колоссальными (однако это мало скажется на их физических размерах, поскольку человечество всегда будет стремиться к предельно возможному).
4. Существенно меняться будет лишь форма, организация и интерфейсы общения с данными. На смену реляционной модели прийдет что-то качественно иное, возможно связанное с выходом за рамки ныне известных нам измерений.
5. Принципиально новые виды информации и прогресс в области интерфейсов повлекут и самые серьезные изменения в методах работы с данными. От ныне живущей (2004 г.) редакции SQL не останется и следа, но сам по себе язык общения с future-DB останется востребованным.

Из вышеперечисленного напрашивается вывод, что и future-DBA будут всегда при деле, вот только методы работы их ждут сильнейшие изменения - помните Навигаторов из "Дюны"?

:roll:

Ну и как Вам?

Sergey___K · Post by **Sergey___K** » 20 Apr 2004 22:06

CREATE TABLE all_the_people (id int4,level0 int4,level1 int4,level2 int4,....,levelN int4,name varchar 32) ,

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

Strannik223 · Post by **Strannik223** » 20 Apr 2004 22:50

Sergey___K wrote:
CREATE TABLE all_the_people (id int4,level0 int4,level1 int4,level2 int4,....,levelN int4,name varchar 32) ,

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

Хи хи.
А сколько индексов мы создавать собираемся, столько же сколько и уровней? Эх и будет INSERT тормозить!!!

Strannik223 · Post by **Strannik223** » 20 Apr 2004 23:08

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

Скажу которотко, вы ошибаетесь, есть как минимум 2 метода которые позволяют делать на стандартном SQL выборки по поддереву. Не буду углубляться.
Я не большой знаток теоретической основы реляционной алгебры, но мне кажется что она намного шире чем понятие "таблица" и связи между таблицами.

f_evgeny wrote:
while(!all_done) {
foreach $boss (@bosses) {
@subordinates=(SELECT id WHERE boss_id=$boss);
if(is_emty(@subordinates)) {
$all_done = 1;
}
@level_subordinates =
}

Получается сложно как раз потому, что информация "деревянная". Для таблиц как правило хватает реляционной алгебры.

Вот так умирают сервера...

Усложним задачку что бы вам совсем жарко стало.
Выбрать только тех сотрудников у которых есть подчиненный (на любом уровне) у которого имя "Вася", и начальника (не обязательно непосредственного) зовут "Петя"
И это не надуманый пример, задача реальная.
И это должно работать бысторо, очень бысторо, и даже еще быстрее!

Seryi · Post by **Seryi** » 20 Apr 2004 23:22

Я читал про деревья в SQL, помимо стандартного рекурсивного решения которое представил Евгений есть еще методы Celko и Tropashko
Уже точно не помню в чем заключались, но смысл в том что селекты по дереву были очень недорогими операциями.
С другой стороны инсерты и апдейты были чрезвычайно дорогими. Фактически приходилось перелопачивать полдерева при инсерте.

Strannik223 · Post by **Strannik223** » 20 Apr 2004 23:34

oMoses wrote:future-DB и future-SQL после 2100 года:
1. Базы данных, как механизм организации, хранения и обработки информации всегда были есть и будут.
2. Раз всегда будут future-DB, то всегда будет и средства общения с ними - future-SQL.
3. Объемы данных future-DB будут колоссальными (однако это мало скажется на их физических размерах, поскольку человечество всегда будет стремиться к предельно возможному).
4. Существенно меняться будет лишь форма, организация и интерфейсы общения с данными. На смену реляционной модели прийдет что-то качественно иное, возможно связанное с выходом за рамки ныне известных нам измерений.
5. Принципиально новые виды информации и прогресс в области интерфейсов повлекут и самые серьезные изменения в методах работы с данными. От ныне живущей (2004 г.) редакции SQL не останется и следа, но сам по себе язык общения с future-DB останется востребованным.

Не помню откуда,

Данные это еще не информация
Информация это еще не знания
Знания это еще не мудрость.
Мудрость это еще не любовь.

Предсказать прогрес так же сложно (невозможно) как и движение капли на лобовом стекле.
Пару десятков лет тому прорыв в области искуственного интелекта обещал проеобразить весь жизненный уклад, но не суждено было. Так же в начале эры транзисторов, не думаю что кто то предполагал что из этого может получится что то большее чем массовый и доступный радиоприемник.

Мы можем предсказывать будущее в той мере что мы знаем куда бы мы хотели двигатся и на основании этого делать более менее правдоподобный прогоноз что Это когда то свершится. Но предсказать когда и свершится ли это задача того же уровня что и изобретение машины времени. Будущее недетерминировано!

Возможно окажется что SQL для данных является тем же оптимумом что и коды Хемминга, но если для кодов Х было теоретически доказано что они оптимальны, то SQL докажет это временем.

Мое мнение: SQL останется восновном таким же каким и был на протяжении следующих 100 лет. Но новые задачи и объемы вместо того что бы мутировать SQL создадут новые уровни програмирования более близкие к естесвенным языкам, которые скорее всего будут базироватся на SQL или напрямую на реляционной модели без SQL как такового.

Единсвенной реальной угорзой SQL явлется желание создать новую генерацию иерархических Data Management Tool. Если удастся решить проблему эффективности.

Strannik223 · Post by **Strannik223** » 21 Apr 2004 00:55

Seryi wrote:Я читал про деревья в SQL, помимо стандартного рекурсивного решения которое представил Евгений есть еще методы Celko и Tropashko
Уже точно не помню в чем заключались, но смысл в том что селекты по дереву были очень недорогими операциями.
С другой стороны инсерты и апдейты были чрезвычайно дорогими. Фактически приходилось перелопачивать полдерева при инсерте.

Про деревья вынес отдельно
http://forum.privet.com/viewtopic.php?p=1004330#1004330

f_evgeny · Post by **f_evgeny** » 21 Apr 2004 06:39

Sergey___K wrote:
CREATE TABLE all_the_people (id int4,level0 int4,level1 int4,level2 int4,....,levelN int4,name varchar 32) ,

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

А какие Вы знаете длинные деревья? Давайте прикинем возможную длину дерева начальник подчиненный.
- Численность человечества возьмем 5*10^9
- Так же применим старинное древнеримское правило, что один начальник может управлять примерно ~10 подчиненными.
- Это дает нам иерархию примерно из 10 уровней
- Добавляем бога (гипотеза) - 11,

f_evgeny · Post by **f_evgeny** » 21 Apr 2004 11:04

Strannik223 wrote:
f_evgeny wrote:Разместить-то легко, а вот достать не очень, поскольку информация "деревянная". Но этого-то как раз я и не обещал. Точнее, методов реляционной алгебры не хватает, придется обходить деревья в циклах.
А разместить - пожалуйста.

Усложним задачку что бы вам совсем жарко стало.
Выбрать только тех сотрудников у которых есть подчиненный (на любом уровне) у которого имя "Вася", и начальника (не обязательно непосредственного) зовут "Петя"
И это не надуманый пример, задача реальная.
И это должно работать бысторо, очень бысторо, и даже еще быстрее!

Странник223, вот наш Вам ответ:
- У меня "деревянных" задач нет, поэтому я в этой области не силен
- Приведенные примеры я набросал за 30 минут, после гостей

, поэтому на совершенстве я не настаиваю, это иллюстрация к тому, что деревья можно всунуть в SQL
- Если Вы не поняли, основная моя мысль была в том, что деревья обрабатывать тяжелее, чем таблицы, что Вы по-моему не отрицаете.
Еще, по данному вопросу могу сказать, что алгоритмы и способы практически все изобретены и описаниы, и что с массивами (аналог таблиц) работать легче, чем с деревями, поэтому трудно ожидать, что изобретут что-нибудь такое нереляционное, что будет работать также или лучше, чем реляционные БД. Или, применяя аналогии, трудно ожидать, что самый быстрый автомобиль обгонит самый быстрый самолет.

zVlad · Post by **zVlad** » 21 Apr 2004 12:00

"Деревянным" и "реляционным" посвящается. Чтобы не забивать Привет длинными цитатами и пространными рассуждениями я просто решил посоветовать интересующимся вопросом представления иерархий в реляционных базах данных и методов работы с ними прочитать одно приложение с примерами из документации ДБ2 версии 8 (только обещайте прочитать все приложение если желаете прокоментировать, там всего несколько страниц):

http://www-306.ibm.com/cgi-bin/db2www/d ... 2w/en_main

Затем открываем ссылку: "SQL Reference Part. 1" (PDF document) и далее по оглавлению идем на "Appendix L".

Полробности синтаксиса для данного случая описаны в Chapter 4. Queries раздел Select-statement.

Sergey___K · Post by **Sergey___K** » 02 Jun 2004 22:46

А тем временем:

http://msdn.microsoft.com/XML/BuildingXML/XMLandDatabase/default.aspx?pull=/library/en-us/dnsql90/html/sql2k5xml.asp

Code: Select all

 SELECT xCol.query('/doc[@id = 123]//section')   
FROM   docs
WHERE  xCol.exist ('/doc[@id = 123]') = 1

или

SELECT pk, xCol.query('
   for $s in /doc[@id = 123]//section
   where $s/@num >= 3
   return <topic>{data($s/heading)}</topic>')   
FROM docs

Strannik223 · Post by **Strannik223** » 02 Jun 2004 23:17

Sergey___K wrote:А тем временем:

http://msdn.microsoft.com/XML/BuildingXML/XMLandDatabase/default.aspx?pull=/library/en-us/dnsql90/html/sql2k5xml.asp
Code: Select all
 SELECT xCol.query('/doc[@id = 123]//section')   
FROM   docs
WHERE  xCol.exist ('/doc[@id = 123]') = 1

или

SELECT pk, xCol.query('
   for $s in /doc[@id = 123]//section
   where $s/@num >= 3
   return <topic>{data($s/heading)}</topic>')   
FROM docs

То же мне фокус. Ну выбрал ты из поля стринг, ну построил xml, а дальше что? У меня один кудесник на проекте то же прочитал про эту фичу и заделал ее. Прийдется следующего релиза ждать что бы это выдрать на....
Здесь ведь убита вся сущность реляционный отношений!
Допустим как ты сделаешь

Code: Select all

where myTable.myXmlField/some/xpath/here = 'kukuruza' ?

А никак. Только тупым циклом перебирая все строчки. И что, далеко это уехало от DBase III?
Хотя иногда эта фича полезная, например передать параметр как список в хранимку. Что то вроде параметра-таблицы.

Sergey___K · Post by **Sergey___K** » 03 Jun 2004 00:08

Допустим как ты сделаешь ... Только тупым циклом перебирая все строчки

sql:variable() Но уже ясно, что Странник умную линку не читал.

Здесь ведь убита вся сущность реляционный отношений!

Но для этого нужно приложить руки, растущие оттуда же, окуда и ноги.

Strannik223 · Post by **Strannik223** » 03 Jun 2004 00:38

Sergey___K wrote:
Допустим как ты сделаешь ... Только тупым циклом перебирая все строчки
sql:variable() Но уже ясно, что Странник умную линку не читал.

Это я того, не разобравшись шашкой махать начал. :oops:

Я думал про 2000 речь.