Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 29   вперед  Ctrl
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127

Вот я и спрашиваю, откуда система в ДАННОМ СЛУЧАЕ знает, что признак бронирования в
set ^(место,"статус")=1 ;признак "бонирован"
не символьный "t", а числовой 1.


она не знает - это прерогатива системной надстройкой реализующей декларацию структуры или самого приложения, если надстройки нет

c127

Т.е. в данном случае (речь только о Вашем примере) нет возможности выяснить, как правильно спросить у системы
set ^(место,"статус")=1
либо
set ^(место,"статус")="t"


нет такой возможности в чистом M

с127

Когда в ^БИЛЕТЫ(дата,рейс,место) добавляется нечто, то это должно быть отражено в индексе. Как система может не знать, что индекс должен быть модифицирован? Это же индекс.


М-система оперерирует только глобалами (деревьями) и не знает взаимосвязей между ними. Поэтому для того чтобы работало так как мы хотим придется писать код типа такого ...


Речь идет не об использовании, речь идет о поддержании целостности между данными и индексом. Данные меняются, если они проиндексированы, то индекс должен поменяться.
БРОНИРОВАТЬ(дата,рейс,место,пассажир)
 {
	tstart
	set ^БИЛЕТЫ(дата,рейс,место)=пассажир
	set ^(место,"статус")=1   ;признак "бронирован"
        set ^БИЛЕТЫИНДЕКСЫ(1,дата,рейс,место)=""
        set ^БИЛЕТЫИНДЕКСЫ(2,рейс,дата,место)=""
	tcommit
 }

ОТМЕНАБРОНИ(дата,рейс,место)
 {
	tstart
	kill ^БИЛЕТЫ(дата,рейс,место)
        kill ^БИЛЕТЫИНДЕКСЫ(1,дата,рейс,место)
        kill ^БИЛЕТЫИНДЕКСЫ(2,рейс,дата,место)
	tcommit
 }


с127


Еще все время забываю спросить по синтаксису. Есть структуры
^БИЛЕТЫ(дата,рейс,место)=имя пассажира
^БИЛЕТЫ(дата,рейс,место,"статус")=выкуплен|бронирован

^БИЛЕТЫ определены по-разному. Это что, разные деревья? Если это имя дерева, то почему разные деревья называются одинаково, если не имя то что? Второй не используется или я ошибаюсь?


они не определены по разному :) Понимать это нужно так

Есть корневой узел ^БИЛЕТЫ, на первом уровне ветвления которого расположены 0 или более дат вылета. Для каждой даты вылета существует 0 или более рейсов которые вылетают в эту дату - это второй уровень ветвления.
Для каждого рейса вылетающего в указанную дату проданы/бронированы билеты на 0 или более указанных конкретно мест, на котором сидит (=) пассажир - это третий уровень ветвления, но на нем уже есть заполненные узлы (имя пассажира). Осталось только прицепить признак-характеристику билета, которую еще не учли - делаем для бронированного/купленного места дочерний именованный подузел "статус" и помежаем туда 1-бронирован/2-куплен или иные коды статуса.

Две строки в описании структуры пришлось привести ввиду того, что необходимо было показать что на месте сидит какой-то пассажир.
                                           ^БИЛЕТЫ
                                                |
                                                *
                                              дата
                                                |
                                                *
                                              рейс
                                                |
                                                *
                                              место = пассажир
                                                |
                                                1
                                               статус = статус брони

c127

В самом первом листинге в функции БРОНИРОВАТЬ есть:
^(место,"статус")=1
Типа дерево, но без имени. Это что-то вроде виртуального дерева? Откуда оно там взялось, в параметрах функции этого нет? Где хранится этаединица в смысле как к потом обратиться к этой информации?


Видно что Вы разбирались детально :)

Нотация

set ^БИЛЕТЫ(дата,рейс,место)=имя пассажира

затем сразу же

^(место,"статус")=1

означает использование т.н. "голой ссылки" - так как при обращении к любому узлу необходимо указывать полный путь начиная с родительской вершины, синтаксис языка позволяет не дублировать длинные пути к родителю и оставить только указание значение контекстного узла, по отношению к предыдущей опеации чтения/записи в глобал, и возможно, добавив дополнительные подузлы ("статус") к контекстному. Мне не следовало употреблять такой синтаксис, т.к. считается плохим тоном из-за скрытых ошибок, когда значение контекста вдруг меняется строкой кода в промежутке
1 мар 06, 15:52    [2404653]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127

И если несложно, вот воросы, заданные сторонникам фастобджекса.
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=138641&pg=4#1281128


1) типы самолетов, которыми летал Scott Tiger, 1,9,12,13,18,22,28 января 2003 года
В предположении, что индекса по пассажирам нет
 set месяц="2003-01"
 set пассажир="Scott Tiger"
 for число=1,9,12,13,18,22,28 {
	 set дата=$ZDATEH(месяц_"-"_число,3)  //формируем дату во внутреннем представлении из вида YYYY-MM-DD
	 set рейс=""

         kill тип самолета    //очищаем приемник для результата
        
	 for {
		 //Обходим все рейсы за заданную дату
		 set рейс=$ORDER(^БИЛЕТЫ(дата,рейс)) 
		 quit:рейс=""
		 
		 set типсамолета=^РАСПИСАНИЕ(дата,рейс)
		 
		 set место=""	 

		 for {
			  set место=$ORDER(^БИЛЕТЫ(дата,рейс,место))
			  quit:место=""
			  quit:^(место)=пассажир           //если такой в самолете был
		 }
                
                set:место'="" типсамолета(типсамолета)=""   //кладем в массив типы самолета, если найдено место на котором сидел заданный пассажир

	 }
 }
 
 zw типсамолета   //печатаем найденные типы самолетов

 /*   Имеется индекс
      ^БИЛЕТЫИНДЕКСЫ(3,имя пассажира,дата,рейс)=""
 */
 
 set месяц="2003-01"
 set пассажир="Scott Tiger"
 for число=1,9,12,13,18,22,28 {
	 set дата=$ZDATEH(месяц_"-"_число,3)  //формируем дату во внутреннем представлении из вида YYYY-MM-DD
	 set рейс=""
	 for {
		 //Обходим все рейсы за заданные даты для искомого пассажира
		 set рейс=$ORDER(^БИЛЕТЫИНДЕКСЫ(3,пассажир,дата,рейс)) 
		 quit:рейс=""
		 
    	 set типсамолета(^РАСПИСАНИЕ(дата,рейс))=""   //кладем в массив типы самолета
	 }
 }
 
 zw типсамолета   //печатаем найденные типы самолетов


номера рейсов которые были в январе 2003 года и на которые оставалось от 10 до 20 непроданных билетов включительно, но самолет не "TU 154"
 //Функция-счетчик дочерних подузлов дерева path
COUNT(path)
 {
	 set idx=""
	 for count=0:1 set idx=$ORDER(@path@(idx)) quit:idx=""
	 quit count
 } 

 set месяц="2003-01"
 set кромесамолета="TU-154"
 set кол1=10,кол2=20           ;от [кол1,кол2] билетов
 
 set дата=$ZDATEH(месяц_"-01",3)  // начинаем с 1-го числа месяца
 for {
	 set дата=$ORDER(^РАСПИСАНИЕ(дата))
	 quit:дата=""
	 quit:$EXTRACT($ZDATE(дата,3),1,7)'=месяц  //прекращаем поиск если достигли конца месяца
	 
	 set рейс=""
	 for {
		 set рейс=$ORDER(^РАСПИСАНИЕ(дата,рейс)) 
		 quit:рейс=""
		 set типсамолета=^РАСПИСАНИЕ(дата,рейс)
		 if (типсамолета'=кромесамолета) { //отбрасываем лишние типы
			set проданомест=$$COUNT($NAME(^БИЛЕТЫ(дата,рейс)))
			set мествналичии=$$COUNT($NAME(^САМОЛЕТ(типсамолета)))
			set непродано=мествналичии-проданомест
			if (непродано'<кол1) && (непродано'>кол2) set рейсы(рейс)=""
		 }
	 }
	 
 }
 zw рейсы
1 мар 06, 21:40    [2406070]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Наверное банальность - у SQL более высокий уровень абстракции, чем у MUMPS. У модели 1с более высокий уровень абстракции, чем у СУБД с любой МД. И на 1с криво получаются многие вещи, не укладывающиеся удобно в ее МД. То же самое и с SQL по сравнению с MUMPS. Причем у MUMPS не то что более низкий, а весьма оптимальный уровень абстракции. Для разработки приложений приходится помимо SQL использовать какие-то другие языки, тогда как MUMPSом вполне можно обойтись. Да и напрямую глобалами пользуются только истинные патриоты. Умеренные сначала создают инструменты с милыми их сердцу МД, и уж на них творят приложения.
1 мар 06, 21:48    [2406091]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
MX -- ALEX
okdoky
okdoky
Как вы представите дерево с повторяющимися вершинами в разных ветвях. Например:
a(100)    b(60)
| |
c(50) c(30)
| |
d(20) e(10)
Этот же вопрос не только к сторонникам SQL но и к сторонникам M? Пока интересен только ввод (представление), не запросы. Конечно в скобках это значения атрибута, например с именем s

M:
set T("a")=100,T("a","c")=50,T("a","c","d")=20
set T("b")=60,T("b","c")=30,T("b","c","e")=10
----------------------------------------

или я не так понял вопрос ?
Имя атрибута s (salary) придется держать в голове? Очевидно, если дерево будет расти, достаточно ввести T("a","c","d","e")=19? В принципе понятно, эта задача в М выполнима.

vadiminfo
Ну зачем тада называть интересными идеями все чего нет в Зигзаге, как-будто этого нет в СУБД скарлупы? Про запрос бы пояснили - что там надо было получить.
Что тут непонятного? Мамписты сразу поняли, скулистам надо что-то объяснять. Конечно здесь тот номер с таблицей
a; c; 100
b; c; 60
c; d; 50
c; e; 30
d; null; 20
e; null; 10
не проходит. Нижние для "c" вершины зависят и от более верхних вершин. Именно в этом заключается особенность дерева. Да и возможности роста дерева в высоту тоже надо учитывать. Фокус с таблицей
a; c; d
b; c; e
также не проходит. Особенности скорлупы сказываются :))

На Zigzag все это реализуется очень легко:
{a(s:100):c(s:50):d(s:20), b(s:60):c(s:30):e(s:10)};
Чтобы добавить новую вершину можно использовать выражение:
a:c:d:e(s:19);
А если я приведу примеры с наследованием классов и со сложными атрибутами .... Вот когда нужно будет удивляться...
1 мар 06, 22:13    [2406143]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

Мамписты сразу поняли, скулистам надо что-то объяснять.

Слишком дешевенький пропагандисткий трюк.

В чем была задача объясните, плиз. А Вы обясняете что что-то не пройдет, а что именно не говорите. Что-то там про деревья.

Можете нарисовать результат в виде таблы, который должен вернуть запрос?
Или нет?

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

Что дано нарисовали. Сэнкс за это. Теперь соберитесь и нарисуйте что же должен вернуть запрос.

В прошлый раз Вы поставили свои якобы сложные задачки и скулисты слишком легко решили? Поэтому Вы теперь прибегли к более хитрой тактике?
Или в Зигзаге так принято - че надо на всякий случай внятно не говорим, а приводим формулы - Зигзаг это может? Он луче. А то если узнают шо была за задача выяснится, шо он хуже? Хитро. Но грязновато.
1 мар 06, 23:53    [2406372]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ораклоидальный мампсист
Наверное банальность - у SQL более высокий уровень абстракции, чем у MUMPS. У модели 1с более высокий уровень абстракции, чем у СУБД с любой МД.

Судя по всему имеется в виду, что более высокий уровень абстракции это хуже. Скорей всего, тада под абстракцией понимается что-то отличное от общепринятого. Если же в обычном смысле, то получается MUMPS не может абстрагироваться от ненужных деталей так хорошо как SQL? Или что?

Тем более не ясно что понимается под моделью 1с и как оно соотносится с СУБД? Если внешние модели типа накладных, то они должны быть менее абстракты, чем то что в СУБД - модель данных. Таков как бы закон жанра ИС.

ораклоидальный мампсист

И на 1с криво получаются многие вещи, не укладывающиеся удобно в ее МД. То же самое и с SQL по сравнению с MUMPS. Причем у MUMPS не то что более низкий, а весьма оптимальный уровень абстракции.

Это уже пропаганда пошла в чистом виде, или все еще следует искать технический смысл?

ораклоидальный мампсист

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

Да кто захочет и на тока С обойдется без других языков при большом желании. Проблема тока в том, что то чем занимется SQL - язык БД, он слишком преуспел. И может оказаться, что его неполнота значительно меньший недостаток. Потому что другие, возможно, проигрывают именно в этом - в управлении БД. Вот в чем трабла. Вы на велосипеде и по тропинке проедете. А на мерсе нет. Что теперь велосипед луче? Ить на нем везде можно.

ораклоидальный мампсист

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

Это лирика? Или какой-то принцип проектирования? На SQL глобалями вообще не пользуются. Так что такой проблемы нет.
2 мар 06, 00:22    [2406432]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
c127
Guest
Rus000

Нотация

set ^БИЛЕТЫ(дата,рейс,место)=имя пассажира

затем сразу же

^(место,"статус")=1

означает использование т.н. "голой ссылки" - так как при обращении к любому узлу необходимо указывать полный путь начиная с родительской вершины, синтаксис языка позволяет не дублировать длинные пути к родителю и оставить только указание значение контекстного узла, по отношению к предыдущей опеации чтения/записи в глобал, и возможно, добавив дополнительные подузлы ("статус") к контекстному. Мне не следовало употреблять такой синтаксис, т.к. считается плохим тоном из-за скрытых ошибок, когда значение контекста вдруг меняется строкой кода в промежутке


Понял. Не было ясно к чему оно отностися. Это напоминает асемблер:
add a,b
складывает содержимое регистров a и b. А для того чтобы узнать значения каких переменных на самом деле складываются нужно пойти вверх по коду и найти нечто вроде:
mv x,a
mv y,b
и при этом убедиться что между этими операторами ничто не поменяло значений регостров. Просто я от такого отвык.

Rus000

В предположении, что индекса по пассажирам нет
....
Имеется индекс


Мы как-то по-разному понимаем индексы. Индекс на длину программы не влияет, он влияет только на эффективность. Похоже что в М индекс нужно не толко поддерживать руками, но и явно указывать системе, что его нужно использовать, иначе она его не увидит. Точнее даже не указывать, что его нужно использовать, а использовать вручную вместо основного дерева. Но тогда это не индекс, это просто другая структура данных, в РСУБД тоже иногда так поступают, но этого лучше избегать пока возможно.

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

Вот решения на СКЛ-е для сайбейз АСА. Могут быть небольшие ошибки, я запросы не прогонял. Кроме того я использовал схему БД предложенную SergSuper-ом, которую я возможно не совсем понимаю, тут тоже могут быть непринципиальные неточности. Например я предположил что тип самолета хранится в Fly.caption, но если он во Fly.fly, т.е. если Fly.fly это строка вида 'TU 154', то таблицу Fly в запросы можно не включать, а тип взять из Shedul.fly.
Задача 1) типы самолетов, которыми летал Scott Tiger, 1,9,12,13,18,22,28 января 2003 года
select f.caption
from Fly f, Shedul h, Sold s
where s.race=h.race  // связываются таблицы
    and h.fly=f.fly      // связываются таблицы
    and s.fio='Tiger Scott'
and s.date in ('2003.01.01','2003.01.09','2003.01.12','2003.01.13','2003.01.18','2003.01.22','2003.01.28')
Задача 2) номера рейсов которые были в январе 2003 года и на которые оставалось от 10 до 20 непроданных билетов включительно, но самолет не "TU 154"
Ваше решение если не ошибаюсь не учитывает разницу между забронированными и выкупленными билетами. В невыкупленные это непроданные, денег-то нет.

select s.race 
  from Sold s, Shadule h, Fly f 
  where s.race=h.race // связываются таблицы
    and h.fly=f.fly       // связываются таблицы
    and f.caption<>'TU 154'
    and datediff(month,'2003.01.01',h.date)=0 // можно заменить на h.date between  '2003.01.01' and '2003.01.31' 
    and s.flag=1
  group by s.race
  having (((select sum(cnt) from place p where p.fly=f.fly) - count(*)) between 10 and 20)
2 мар 06, 04:19    [2406559]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
osse
Member

Откуда: Н-ск
Сообщений: 162
okdoky

Что тут непонятного? Мамписты сразу поняли, скулистам надо что-то объяснять. Конечно здесь тот номер с таблицей
a; c; 100
b; c; 60
c; d; 50
c; e; 30
d; null; 20
e; null; 10
не проходит. Нижние для "c" вершины зависят и от более верхних вершин. Именно в этом заключается особенность дерева. Да и возможности роста дерева в высоту тоже надо учитывать.


Во первых не
a; c; 100
b; c; 60
c; d; 50
c; e; 30
d; null; 20
e; null; 10

а

a; null; 100
b; null; 60
c; a; 50
c; b; 30
d; c; 20
e; c; 10

И все от чего надо зависит.
А в
первоначальном запросе нужно будет добавить distinct после select, чтобы "c" не выводился более одного раза
2 мар 06, 06:12    [2406591]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
ораклоидальный мампсист
Наверное банальность - у SQL более высокий уровень абстракции, чем у MUMPS. У модели 1с более высокий уровень абстракции, чем у СУБД с любой МД. Да и напрямую глобалами пользуются только истинные патриоты. Умеренные сначала создают инструменты с милыми их сердцу МД, и уж на них творят приложения.


Это точно
2 мар 06, 07:08    [2406634]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127

Мы как-то по-разному понимаем индексы. Индекс на длину программы не влияет, он влияет только на эффективность. Похоже что в М индекс нужно не толко поддерживать руками, но и явно указывать системе, что его нужно использовать, иначе она его не увидит. Точнее даже не указывать, что его нужно использовать, а использовать вручную вместо основного дерева.


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

c127

Но тогда это не индекс, это просто другая структура данных, в РСУБД тоже иногда так поступают, но этого лучше избегать пока возможно.


Вопрос терминов. Думаю в РСУБД все обстоит абсолютно аналогично, за исключением того, что в SQL это скрыто на уровне реализации страндарта.
Предложения SQL - суть высокоуровневые процедуры. Мы пытаемся сейчас копаться в более низких слоях

c127

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


Конечно же не хитрю. В моем понимании индексов (см.выше) это классический инверсный индекс, который позволяет оптимизировать скорость запроса. Оптимизатор SQL делает примерно такой же анализ по какой индексной структуре или их комбинации обработать запрос

c127

Вот решения на СКЛ-е для сайбейз АСА. Могут быть небольшие ошибки, я запросы не прогонял. Кроме того я использовал схему БД предложенную SergSuper-ом, которую я возможно не совсем понимаю, тут тоже могут быть непринципиальные неточности. Например я предположил что тип самолета хранится в Fly.caption, но если он во Fly.fly, т.е. если Fly.fly это строка вида 'TU 154', то таблицу Fly в запросы можно не включать, а тип взять из Shedul.fly.


Безусловно все быглядит куда более понятнее и лаконичнее, но мы сравниваем несколько разные вещи. Гораздо интереснее было б взглянуть на сгенерированный низкоруовневый год для этих запросов.

Ваши примеры будут работать, например, и в кашовом SQL, но в любом случае СУБД должна сгенерировать исполняемы код, который выдаст искомы результат. Просто в случае, например опять же, каше этот исполняемый код будет на M.
2 мар 06, 07:41    [2406684]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127

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


да, упустил, ночью писал, но это не принципиально, согласитесь, достаточно добавить фильтр по условию в $$COUNT(path,filter) и указать в качестве фильтра статус=2 (продан)
2 мар 06, 07:48    [2406698]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
ораклоидальный мампсист
Наверное банальность - у SQL более высокий уровень абстракции, чем у MUMPS. У модели 1с более высокий уровень абстракции, чем у СУБД с любой МД. И на 1с криво получаются многие вещи, не укладывающиеся удобно в ее МД. То же самое и с SQL по сравнению с MUMPS. Причем у MUMPS не то что более низкий, а весьма оптимальный уровень абстракции.
По определению, абстракция/абстрагирование -- это
1. Форма познания, представляющая собой мысленное выделение существенных свойств и связей предмета и отвлечение от других его свойств и связей, признаваемых "частными", несущественными."
2. Метод научного исследования, основанный на том, что при изучении некоторого явления, процесса не учитываются его несущественные стороны и признаки, что позволяет упрощать картину изучаемого явления и рассматривать его как бы в "чистом виде".
Таким образом, чем ниже уровень абстракции языка, тем большее количество несущественных деталей обязан учитывать и использовать программист. Там, где важны один-два концепта, он принужден применять 5. Вместо десяти крупных операторов он должен писать восемьдесят мелких. Что же в низком уровне абстракции такого хорошего и "оптимального"?
ораклоидальный мампсист
Для разработки приложений приходится помимо SQL использовать какие-то другие языки, тогда как MUMPSом вполне можно обойтись. Да и напрямую глобалами пользуются только истинные патриоты. Умеренные сначала создают инструменты с милыми их сердцу МД, и уж на них творят приложения.
Знаете, в век ООП, RAD-средств и компонентного программирования довольно странно читать заявления о том, что для разработки клиентских приложений вполне можно обойтись MUMPSом.
2 мар 06, 08:00    [2406712]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
okdoky
Member

Откуда:
Сообщений: 349
vadiminfo
Можете нарисовать результат в виде таблы, который должен вернуть запрос?
Или нет?
Вот именно, вы все сводите к таблице. Я не спрашиваю про результат. Это могут быть все вершины подчиненные "а", или подчиненные "а" и "с", или значения s-атрибутов для всех вершин выше "e". Что угодно, применимое к дереву. Меня интересует, какие формы таблиц предложат скулисты для дерева, с учетом его потенциального роста?

vadiminfo
Хитро. Но грязновато.
Разве Вам неинтересно узнать о слабых местах SQL? Ничего тут грязного нет. Мамписты признают некоторые слабости своих моделей. Я признаю слабости в Zigzag. Но только не в представлении данных, а в функциональности. Он изначально предлагался как дополнение к языку Java. Собственно поэтому я и заинтересовался Zigzag. Для меня Java роднее.

osse
a; null; 100
b; null; 60
c; a; 50
c; b; 30
d; c; 20
e; c; 10
И все от чего надо зависит.
Вы попались на ту самую хитрость, о которой говорит vadiminfo. Получается другое дерево:
   a      b
| |
c c
/ \ / \
d e d e
2 мар 06, 08:15    [2406732]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
[quot okdoky Получается другое дерево:

a b
| |
c c
/ \ / \
d e d e
[/quot]
это ввоще не дерево а граф (учите матчасть потом на форум)

a b
| /
c
/ \
d e
2 мар 06, 09:41    [2406937]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
okdoky

Вот именно, вы все сводите к таблице.

А Вы к чему? Во-первых, Вы зигзаг по началу для РБД предлагали, а там данные структурированы только в таблицы. Во-вторых, если нужна не таблица, то зачем Вы про SQL говорите? В-третьих, надо точно тада указать структуру. У Вас структура типа XML, ООМД или ваще ни как не структурированы данные - рисунки на бумаге? Надо бы уж с такими вещами сразу определиться.

okdoky

Я не спрашиваю про результат.

А про что? Тада просто нет задачи. Решить задачу без результата? И зачем тада Вы писали запрос? Он ить результаты возращает - это его как бы назначение.

okdoky

Это могут быть все вершины подчиненные "а", или подчиненные "а" и "с", или значения s-атрибутов для всех вершин выше "e". Что угодно, применимое к дереву.

Ну и что? Это что противоречит понятию результата? Но это какие-то пояснения к нему. Дерево как дерево.

okdoky

Меня интересует, какие формы таблиц предложат скулисты для дерева, с учетом его потенциального роста?

Так Вы ее сами и нарисовали. Табла с унарной связью, например. Если же в задаче позволяется и структуру выбирать под запросы, то шансы SQL тока увеличиваются.
Однаков, Вы нарисовали таблу. И попытались самомстоятельно написать запрос - получить какой-то результат. Рисовали иерархический подзапрос, что-то складывали. Хотя что именно должно было получится не потрудились объяснить. И сказали, что так не получится. А теперь говорите, что результат не интересует.
Вы уже точно решите чего хОчите.

okdoky

Разве Вам неинтересно узнать о слабых местах SQL?

Хочу. Но не надуманные. Тем более даже не ясно о чем речь. Читаем литрературу - там обоснованно все приводится. И Вы уж старайтесь недостатки формулировать ясно. Проблема однако для зигзага, у которого трудности даже с группировками, в его достоинствах.

okdoky

Вы попались на ту самую хитрость, о которой говорит vadiminfo.

Не ту. Я про про намеренно неясную постановку задачи говорил. Это вообще не постановка. Уж извените. Поставьте так 10 проггерам задачи - получите разные результаты. Если тока среди нех телепатов, чтобы читать Ваши мысли на расстоянии.
2 мар 06, 10:07    [2407077]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 okdoky

[quot okdoky Получается другое дерево:


a b
| |
c c
/ \ / \
d e d e

[/quot]

Уважаемый, это называется лес, вообще-то.

А как вы себе представляете дерево " дерево с повторяющимися вершинами в разных ветвях." ?

Так :

a b
| /
c |
/ \
d e

?


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


2 мод

>>это ввоще не дерево а граф (учите матчасть потом на форум)

любое дерево это граф.


А вот это дерево :

a b
| /
c
/ \
d e

Его можно перерисовать по-другому :


a
|
c
/ | \
d b e
2 мар 06, 10:21    [2407155]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
мод
Guest
Andreww
любое дерево это граф.

но не любой граф дерево :)
Andreww

А вот это дерево :
a b
| /
c
/ \
d e
Его можно перерисовать по-другому :
a
|
c
/ | \
d b e

низзя. имелся ввиду направленный граф, т.е.
с принадлежит а и b
d принадлежит c
e принадлежит c
a и b никому не принадлежат
2 мар 06, 12:07    [2407918]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
okdoky
Oracle SQL


insert into test_sal values('a',null,100);
insert into test_sal values('b','a',60);
insert into test_sal values('c','a',50);
insert into test_sal values('d','a',40);
insert into test_sal values('e','b',30);
insert into test_sal values('f','b',20);


(об этом уже упоминали но как-то никто не отреагировал )

если дерево задать только списком ветвей
это может привести к неоднозначному построению графа

например на заводе есть две пары нач-подчиненный
"иванов-петров":500
"иванов-петров":700
однофамильцы но работают в разных цехах и оклады разные
если рисовать дерево - то где кого ставить?
видимо предложенное решение на ORACLE - некорректно
может кто даст более правильное ?
============================
2 мар 06, 12:16    [2407989]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 мод

>>имелся ввиду направленный граф, т.е.

Согласен на все 100%.

Если "направленный граф" это то же самое что ориентированный граф, то конечно нельзя и предложенная структура уже однозначно будет не деревом.

Пытаюсь осилить структуру "дерево с повторяющимися вершинами в разных ветвях.", предложенную борцами со скорлупой (есть слабая надежда что они понимают в предмете который пытаются ниспровергать), с одной стороны дерево (в этом случае надо быть осторожнее с орграфом) а с другой с повторяющимися вершинами (т.е. совсем не дерево, по крайней мере не та структура которая рассматривается в теории графов).
2 мар 06, 12:40    [2408186]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
токарь
Guest
Andreww
Пытаюсь осилить структуру "дерево с повторяющимися вершинами в разных ветвях.", предложенную борцами со скорлупой
Имелось ввиду с повторяющимися именами вершин. Он же дал пример, можете назвать это лес, а не дерево, если хотите. Важно, что выражена зависимость, при которой тот первоначальный способ с бинарными связями не подходит. MX -- ALEX пояснил в последнем посте. Может Вам будет понятнее такое дерево
      o
/ \
a b
| |
c c
| |
d e
Привыкли думать таблицами? Получается ограниченность (скорлупа) сидит не в SQL, а в таблице? Как Вы представите, что "е" является сыном того "с", который является сыном "b"?
2 мар 06, 13:11    [2408419]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 Токарь

>>повторяющимися именами вершин

А вершины "с" они вообще равны или эквивалентны ?
Может вопрос не в свойствах дерева а в способах идентификации узлов и вершин ?

>>способ с бинарными связями не подходит

Дерево не имеет кратных ребер (кратные ребра - соединяющие одну и ту же пару вершин) и ещё не имеет петель, только БИНАРНЫЕ СВЯЗИ и ПОДХОДЯТ, ИМХО.

>>Привыкли думать таблицами

Нет, я привык мозгом.

>>Получается ограниченность (скорлупа) сидит не в SQL, а в таблице?

Скорее в головах.

>>Как Вы представите, что "е" является сыном того "с", который является сыном "b"?

А вы как привыкли идентифицировать человека ? Только по фамилии до первого однофамильца?
2 мар 06, 13:28    [2408530]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
токарь
Andreww
Пытаюсь осилить структуру "дерево с повторяющимися вершинами в разных ветвях.", предложенную борцами со скорлупой
Имелось ввиду с повторяющимися именами вершин. Он же дал пример, можете назвать это лес, а не дерево, если хотите. Важно, что выражена зависимость, при которой тот первоначальный способ с бинарными связями не подходит. MX -- ALEX пояснил в последнем посте. Может Вам будет понятнее такое дерево
      o
/ \
a b
| |
c c
| |
d e
Привыкли думать таблицами? Получается ограниченность (скорлупа) сидит не в SQL, а в таблице? Как Вы представите, что "е" является сыном того "с", который является сыном "b"?

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

И для деревьев и для леса связь один ко многим. А это связь многие ко многим. В РМД она реализуется с помощью дополнительной ассоциативной таблы.
Но я не буду говорить, что МУМПСисты все такие - не могут выразить что хотят.
2 мар 06, 16:45    [2409880]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
ораклоидальный мампсист
Guest
Мне сложновато спорить с mir и vadiminfo - они крепче сидят на SQL. Сейчас пишу ХП под Oracle. А всю прошлую неделю программировал на MUMPS. Программировать на MUMPS и использовать Cache приятнее, чем программировать на PL/SQL и использовать Oracle. Лично мне. Пусть кто-нибудь другой, кто знает и использует и то и другое, расскажет о своих ощущениях.
2 мар 06, 17:03    [2410009]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
MX -- ALEX
Guest
vadiminfo
токарь
Andreww
Пытаюсь осилить структуру "дерево с повторяющимися вершинами в разных ветвях.", предложенную борцами со скорлупой
Имелось ввиду с повторяющимися именами вершин. Он же дал пример, можете назвать это лес, а не дерево, если хотите. Важно, что выражена зависимость, при которой тот первоначальный способ с бинарными связями не подходит. MX -- ALEX пояснил в последнем посте. Может Вам будет понятнее такое дерево
      o
/ \
a b
| |
c c
| |
d e
Привыкли думать таблицами? Получается ограниченность (скорлупа) сидит не в SQL, а в таблице? Как Вы представите, что "е" является сыном того "с", который является сыном "b"?

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

И для деревьев и для леса связь один ко многим. А это связь многие ко многим. В РМД она реализуется с помощью дополнительной ассоциативной таблы.
Но я не буду говорить, что МУМПСисты все такие - не могут выразить что хотят.

получается что для правильной работы в SQL все узлы дерева
должны быть именованы уникально.
нам кажется это не совсем удобно на практике.
(да и зачем тогда было браться решать такую задачу
если изначально по условию это требование не удовлетворяется)
в М понятно что Иванов который в пятом цехе
это не тот Иванов что во втором.
в М не надо ВСЕ узлы именовать РАЗЛИЧНО - предки то разные.
SQL эту информацию не учитывает ?
2 мар 06, 17:05    [2410022]     Ответить | Цитировать Сообщить модератору
 Re: Каше vs. Фокс....  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
MX -- ALEX
получается что для правильной работы в SQL все узлы дерева
должны быть именованы уникально.
нам кажется это не совсем удобно на практике.


Во первых не для правильной или не правильной работы SQL, а из соображений оптимальности, в том числе и для запросов SQL проектируется схема. Наличие дубликатов в основной табле - нарушение целостности отношения. Какую запись хто будет заполнять другой раз? Какое же тут удобство? Одна ему зарплату укажет в одной записи, а другая в другой. Поди потом разбери где правильно. В ассоциативной табле все про так связвны идетификаторы предков и потомков.


MX -- ALEX

(да и зачем тогда было браться решать такую задачу
если изначально по условию это требование не удовлетворяется)

Мысль не понял. Кото за какую задачу брался и что было изначально известно?
Если Вы про okdoky, то известно. Он исчет чем же все-таки зигзаг луче. Вот и сам ставит задучи, которые думает, что нерешаются Скулем. И в подтвержение приводит свои не совсем удачные попытки их решать на Скуле.
Что же тут непонятного? Но к постановке задачи в плане ясности он относится с некоторым принебрежением.

MX -- ALEX

в М понятно что Иванов который в пятом цехе
это не тот Иванов что во втором.

Это вообще означает, что и до сих пор мы понимаем задачу по разному. Т.е. там первое с не есть второе? Чисто идентификаторы совпадают у разных объектов (разных Ивановых)???!!!!
Т.е. там все-таки дерево? Т.е. на самом деле
        o  
       / \
    а     b
     |     |
    с      c1
     |     |  
    d      e
?
Или при чем тут разные Ивановы? И почему понятно, что они разные? Может оператор по ошибке одного в два места засандалила. В SQL БД есть ограничения целостности для этого.


MX -- ALEX

в М не надо ВСЕ узлы именовать РАЗЛИЧНО - предки то разные.
SQL эту информацию не учитывает ?

Т.е.? Разные объекты имеют совпадающие по идентификации узлы или что? Или ваще нельзя никак отличить узлы РАЗНЫЕ?
2 мар 06, 19:24    [2410750]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 7 8 9 10 11 [12] 13 14 15 16 .. 29   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить