S>Если ты не можешь доказать что при непустом seq в x будет лежать последнее значение из seq после выполнения цикла без того что бы испортить идентичность — то это не мои проблемы.
не понятно, какое это отношение имеет к исходному примеру.
там присвоения полей вообще не было.
S>Что конкретно тебя смущает? Присваивание?
эквивалентность чего с чем используется и на каком основании
Здравствуйте, DarkGray, Вы писали:
S>>Если ты не можешь доказать что при непустом seq в x будет лежать последнее значение из seq после выполнения цикла без того что бы испортить идентичность — то это не мои проблемы.
DG>не понятно, какое это отношение имеет к исходному примеру. DG>там присвоения полей вообще не было.
Вот что интересно. Если ты действительно понятия не имеешь, какое это имеет отношение к исходному коду, то как ты собрался доказывать корректность/некорректность исходного кода? Дай угадаю... С помощью твоей идентичности, которая к исходному коду вообще никакого отношения не имеет, ну то есть абсолютно никакого?
S>>Что конкретно тебя смущает? Присваивание?
DG>эквивалентность чего с чем используется и на каком основании
Я прозивел преобразование кода, эквивалентное преобразованию кода компилятором C#. На том основании, что я знаю, что он производит такое преобразование.
Если ты умудришься формально доказать корректность/некорректность этого кода благодаря своей идентичности и не раскрывая конструкций foreach, анонимные методы и т.п., то флаг тебе.
DG>>эквивалентность чего с чем используется и на каком основании S>Я прозивел преобразование кода, эквивалентное преобразованию кода компилятором C#. На том основании, что я знаю, что он производит такое преобразование.
т.е. ты используешь эквивалентность понятий переменная и объект?, но при этом также утверждаешь, что переменная не является объектом? интересно живешь...
DG>>>эквивалентность чего с чем используется и на каком основании S>>Я прозивел преобразование кода, эквивалентное преобразованию кода компилятором C#. На том основании, что я знаю, что он производит такое преобразование.
DG>т.е. ты используешь эквивалентность понятий переменная и объект?, но при этом также утверждаешь, что переменная не является объектом? интересно живешь...
Я не использовал эквивалентность этих понятий, они и не эквивалентны. Я заменил локальную переменную полем объекта, ровно как и компилятор. Для этого не требуется эквивалентность переменной и объекта.
DG>>т.е. ты используешь эквивалентность понятий переменная и объект?, но при этом также утверждаешь, что переменная не является объектом? интересно живешь... S>Я не использовал эквивалентность этих понятий, они и не эквивалентны. Я заменил локальную переменную полем объекта, ровно как и компилятор. Для этого не требуется эквивалентность переменной и объекта.
ты использовал, что переменная эквивалентна полю объекта, а из это следует, что переменная эквивалентна объекту.
или более формально, ты использовал, что:
1. объявление переменной типа T эквивалентно созданию объекта Переменная с полем T
2. присвоение переменной эквивалентно присвоение полю
3. получение значения переменной эквивалентно получению значения поля
доказательство:
4. поле объекта эквивалентно свойству объекта без доп. поведения
5. свойство объекта эквивалентно двум методам GetValue/SetValue
6. (из 2, 4, 5) присвоение переменной эквилентно вызову метода SetValue
7. (из 3, 4, 5) получение значения переменной эквивалентно вызову метода GetValue
из 1, 6, 7:
8. объявление переменной типа T эквивалентно созданию объекта Переменная<T>
9. присвоение переменной эквивалентно вызову метода SetValue
10. получение значения из переменной эквивалентно вызову метода GetValue
DG>>>т.е. ты используешь эквивалентность понятий переменная и объект?, но при этом также утверждаешь, что переменная не является объектом? интересно живешь... S>>Я не использовал эквивалентность этих понятий, они и не эквивалентны. Я заменил локальную переменную полем объекта, ровно как и компилятор. Для этого не требуется эквивалентность переменной и объекта.
DG>ты использовал, что переменная эквивалентна полю объекта,
Чушь DG>а из это следует, что переменная эквивалентна объекту.
Чушь
Из того что ты увеличил косвенность не следует что понятия переменной и объекта эквивалентны. Тем более, что обратная замена не всегда возможна.
DG>или более формально, ты использовал, что: DG>1. объявление переменной типа T эквивалентно созданию объекта Переменная с полем T
нет. Сравни:
T x;
new Переменная();
DG>2. присвоение переменной эквивалентно присвоение полю DG>3. получение значения переменной эквивалентно получению значения поля
И это чушь. Я это не использовал. Что бы делать утверждения относительно кода с сахаром, нужно знать, во что он разворачивается. Я произвел соответствующее преобразование. Все. Никаких спекуляций об эквивалентности и идентичности.
DG>доказательство: DG>4. поле объекта эквивалентно свойству объекта без доп. поведения DG>5. свойство объекта эквивалентно двум методам GetValue/SetValue DG>6. (из 2, 4, 5) присвоение переменной эквилентно вызову метода SetValue DG>7. (из 3, 4, 5) получение значения переменной эквивалентно вызову метода GetValue
DG>из 1, 6, 7: DG>
DG>8. объявление переменной типа T эквивалентно созданию объекта Переменная<T>
DG>9. присвоение переменной эквивалентно вызову метода SetValue
DG>10. получение значения из переменной эквивалентно вызову метода GetValue
DG>
DG>чтд
ты доказал эквивалентность замены переменной не объектом. Ты доказал эквивалентность замены переменной типа T на переменную типа O, храняющу объект (ссылку на объект) типа O, содержащего методы, которые позволяют ... Ты даже не избавился о переменной, а говоришь об эквивалентности объекта и переменной. А раньше утвреждал что переменная объектом является.
З.ы. Способ размещения/хранения значения переменной в модели вычислений не имеет значения при условии что значение сохраняется между его сохранением и последующими чтениями. Пусть хоть лента Тьюринга на хомячковой тяге.
Здравствуйте, DarkGray, Вы писали:
DG>или другими словами — берется элемент известного множества "число", и на него накладываются ограничения.
А можно в студию определение известного множества "число"?
DG>из какого множества берется "ссылка"? можно ли ссылки брать из множества "объект"?, сейчас определение про это ничего не говорит
Из некоторого счётного множества. Можно брать и из множества "объект", определение это никак не ограничивает.
DG>>>так можно определять, но здесь появилось новое понятие "реакция на сообщение". S>>Оно не является атомарным, а определяется в терминах существующих. Реакцией на сообщение является отправка от 0 до N сообщений другим объектам.
DG>из этого определения вытекает, что в понятие "поведение" не входит изменение состояния. DG>это так и есть? или это ты просто забыл указать?
Модель ООП не требует возможности обнаружить изменение состояния иначе, как по поведению. Поэтому определение реакции на сообщение не включает в себя никаких рассуждений об изменении состояния.
S>> сообщение — это элемент множества возможных сообщений. Способов строить множество сообщений — много
DG>как соотносятся множества сообщений и объектов? пересекаются? одно входит в другое? строго не пересекающиеся? имеют общие вырожденные точки?
Определение никак не ограничивает соотнесение множеств ссылок, объектов, и сообщений. Однако, в зависимости от выбора этих соотношений получаются разные модели. Например, если вложить множество ссылок в множество объектов, то сразу возникнут штуки типа "ссылка на ссылку", которые могут оказаться нежелательными.
Могут возникнуть артефакты, связанные с поведением объекта-сообщения.
DG>как соотносятся между собой множества ссылки и объекты?
Каждому элементу множества ссылок сопоставлен ровно один объект.
DG>множества ссылки и сообщения?
Ну, ссылка может содержаться в сообщении. Это означает, что может существовать некоторая функция Extract(m), которая определена на некотором подмножестве множества сообщений, которая сопоставляет сообщению ссылку. Таких функций может быть сколь угодно много, с частично пересекающимися областями определения.
DG>на все эти вопросы необходимо ответить, если речь идет о математических определениях
Сделать это легче, чем кажется.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>>или другими словами — берется элемент известного множества "число", и на него накладываются ограничения. S>А можно в студию определение известного множества "число"?
Число́ — абстракция, используемая для количественной характеристики и нумерации объектов.
а вот абстракция, количественная характеристика и нумерация — это уже неопределяемые понятия.
DG>>из какого множества берется "ссылка"? можно ли ссылки брать из множества "объект"?, сейчас определение про это ничего не говорит S>Из некоторого счётного множества. Можно брать и из множества "объект", определение это никак не ограничивает.
т.е. объект может являться ссылкой?
и в следующем коде — объект X является ссылкой? у него есть оба зафиксированные тобой свойств — сравнение ссылок и снятие ссылки
class X<T>
{
public T GetValue(){..}
..
}
DG>>>>так можно определять, но здесь появилось новое понятие "реакция на сообщение". S>>>Оно не является атомарным, а определяется в терминах существующих. Реакцией на сообщение является отправка от 0 до N сообщений другим объектам.
DG>>из этого определения вытекает, что в понятие "поведение" не входит изменение состояния. DG>>это так и есть? или это ты просто забыл указать? S>Модель ООП не требует возможности обнаружить изменение состояния иначе, как по поведению.
уничтожение объекта себя самим — это часть поведения или часть состояния?
S>Поэтому определение реакции на сообщение не включает в себя никаких рассуждений об изменении состояния.
это уже связка трех разных определений: Поведение, Наблюдаемое поведение и Инкапсуляции.
Инкапсуляция говорит, что в рамках ООП значимым является лишь Наблюдаемое поведение, и если через наблюдение невозможно отличить одно поведение от другого, то поведения считаются одинаковыми.
S>>>Оно не является атомарным, а определяется в терминах существующих. Реакцией на сообщение является отправка от 0 до N сообщений другим объектам.
т.е. исходя из твоих определений поведение объектов X считается различным? а как это можно наблюдать?
и исходя из твоих определений поведение объектов Y и Y1 считается одинаковым?
class X
{
public M(){x.M1();}
protected X1 x = new X1();
protected class X1
{
public void M1(){}//ничего не делает
}
}
class Y
{
public void M(){}
}
class Y1
{
public void M(){x = -x;}
protected int x;
}
Здравствуйте, DarkGray, Вы писали: DG>Число́ — абстракция, используемая для количественной характеристики и нумерации объектов.
Ну, то есть под такое определение числа подходит всё, что угодно, если оно используется для количественной характеристики и нумерации объектов.
В целом видно, что мы добрались до неопределимого понятия.
DG>>>из какого множества берется "ссылка"? можно ли ссылки брать из множества "объект"?, сейчас определение про это ничего не говорит S>>Из некоторого счётного множества. Можно брать и из множества "объект", определение это никак не ограничивает.
DG>т.е. объект может являться ссылкой?
DG>и в следующем коде — объект X является ссылкой? у него есть оба зафиксированные тобой свойств — сравнение ссылок и снятие ссылки DG>
DG>class X<T>
DG>{
DG> public T GetValue(){..}
DG> ..
DG>}
DG>
Из приведённого фрагмента кода непонятно, является ли объект ссылкой или нет, т.к. не приведено определение операции сравнения ссылок.
Но если его корректно доопределить, то да, объекты, построенные на основе такого класса могут служить в качестве ссылок.
DG>уничтожение объекта себя самим — это часть поведения или часть состояния?
Для ответа на этот вопрос нужно сначала решить, существует ли такая вещь, как уничтожение объекта. ООП не требует от модели детерминистической финализации.
DG>это уже связка трех разных определений: Поведение, Наблюдаемое поведение и Инкапсуляции.
DG>Инкапсуляция говорит, что в рамках ООП значимым является лишь Наблюдаемое поведение, и если через наблюдение невозможно отличить одно поведение от другого, то поведения считаются одинаковыми.
В целом да, но инкапсуляция — это свойство связки Поведения и Состояния. Примерно так же, как требование Дистрибутивности не даёт построить поле на вообще любых двух бинарных операциях.
DG>т.е. исходя из твоих определений поведение объектов X считается различным? а как это можно наблюдать?
Различным. Есть обмен сообщениями. В зависимости от подробностей модели и её реализации, способы наблюдения могут быть разными.
DG>и исходя из твоих определений поведение объектов Y и Y1 считается одинаковым?
Да.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>>уничтожение объекта себя самим — это часть поведения или часть состояния? S>Для ответа на этот вопрос нужно сначала решить, существует ли такая вещь, как уничтожение объекта. ООП не требует от модели детерминистической финализации.
не требует и обратного, соответственно для общности необходимо решить — это поведение или состояние, если уж сейчас даются определения для ООП вообще, а не для ООП без детерминистической финализации
DG>>это уже связка трех разных определений: Поведение, Наблюдаемое поведение и Инкапсуляции.
DG>>Инкапсуляция говорит, что в рамках ООП значимым является лишь Наблюдаемое поведение, и если через наблюдение невозможно отличить одно поведение от другого, то поведения считаются одинаковыми. S>В целом да, но инкапсуляция — это свойство связки Поведения и Состояния. Примерно так же, как требование Дистрибутивности не даёт построить поле на вообще любых двух бинарных операциях.
не спорю
DG>>т.е. исходя из твоих определений поведение объектов X считается различным? а как это можно наблюдать? S>Различным. Есть обмен сообщениями. В зависимости от подробностей модели и её реализации, способы наблюдения могут быть разными.
здесь важно что наблюдение делается клиентским объектом (тот который имеет ссылку на объект) в рамках используемого им подмножества сообщений (интерфейса объекта), а не произвольным сторонним наблюдателем.
произвольный сторонний наблюдателем всегда может послать сообщение — покажите мне память объекта, или сериализуйте мне объект,
и тогда не получится на следующий вопрос никогда ответить "да".
и если клиентский объект на используемом им подмножестве сообщений не может выявить отличие (в том числе косвенно через другие объекты), то поведение считается одинаковым
DG>>и исходя из твоих определений поведение объектов Y и Y1 считается одинаковым? S>Да.
Здравствуйте, DarkGray, Вы писали: DG>не требует и обратного, соответственно для общности необходимо решить — это поведение или состояние, если уж сейчас даются определения для ООП вообще, а не для ООП без детерминистической финализации
Вы опять лезете дальше, чем нужно. Базовая модель ООП не обязана ничего говорить о том, что должно считатся в надстроенных над ней моделях.
Если хочется заняться построением модели с детерминистической финализацией, то придётся ответить ещё на много вопросов — в том числе и на то, что делать с невалидными ссылками. Совершенно незачем тащить всю эту грязь в базовую модель.
DG>здесь важно что наблюдение делается клиентским объектом (тот который имеет ссылку на объект) в рамках используемого им подмножества сообщений (интерфейса объекта), а не произвольным сторонним наблюдателем.
В рамках ООП-модели у нас нет произвольного стороннего наблюдателя.
DG>произвольный сторонний наблюдателем всегда может послать сообщение — покажите мне память объекта, или сериализуйте мне объект, DG>и тогда не получится на следующий вопрос никогда ответить "да".
Совершенно необязательно. Модель не требует от объектов какой-то специальной реакции на сообщения типа "покажите мне память объекта", или "сериализуйте мне объект".
Мы можем ввести специальный объект "независимый наблюдатель", не нарушая черноты объектных ящиков — достаточно потребовать от фабричных объектов, чтобы они стучали наблюдателю обо всех создаваемых объектах. Если этого не делать, то у нас получится "релятивистская модель" с конусом причинности и прочими штуками.
DG>и если клиентский объект на используемом им подмножестве сообщений не может выявить отличие (в том числе косвенно через другие объекты), то поведение считается одинаковым
В базовой модели нет понятия "клиентский объект".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Если хочется заняться построением модели с детерминистической финализацией, то придётся ответить ещё на много вопросов — в том числе и на то, что делать с невалидными ссылками. Совершенно незачем тащить всю эту грязь в базовую модель.
но как минимум ты согласен, что ООП с детерминистической финализацией является ООП?
DG>>здесь важно что наблюдение делается клиентским объектом (тот который имеет ссылку на объект) в рамках используемого им подмножества сообщений (интерфейса объекта), а не произвольным сторонним наблюдателем. S>В рамках ООП-модели у нас нет произвольного стороннего наблюдателя.
есть только два варианта:
либо в моделе утверждения фиксируются относительные для конкретного наблюдателя (например, который сидит в каждом конкретном объекте),
либо в моделе утверждения фиксируются абсолютно (и тогда появляется сторонний произвольный наблюдатель)
DG>>произвольный сторонний наблюдателем всегда может послать сообщение — покажите мне память объекта, или сериализуйте мне объект, DG>>и тогда не получится на следующий вопрос никогда ответить "да". S>Совершенно необязательно. Модель не требует от объектов какой-то специальной реакции на сообщения типа "покажите мне память объекта", или "сериализуйте мне объект".
речь не об этом.
ты зафиксировал, что следующие объекты имеют одинаковое поведение
class Y
{
public void M(){}
}
class Y1
{
public void M(){x = -x;}
protected int x;
}
но в любом ЯП это не так, т.к. всегда можно послать сообщение, которое покажет, что внутри Y1 есть x, которого нет в Y.
S>Мы можем ввести специальный объект "независимый наблюдатель", не нарушая черноты объектных ящиков — достаточно потребовать от фабричных объектов, чтобы они стучали наблюдателю обо всех создаваемых объектах.
S>Если этого не делать, то у нас получится "релятивистская модель" с конусом причинности и прочими штуками.
чем это плохо, и кому мешает?
DG>>и если клиентский объект на используемом им подмножестве сообщений не может выявить отличие (в том числе косвенно через другие объекты), то поведение считается одинаковым S>В базовой модели нет понятия "клиентский объект".
дай тогда свое название для множества объектов, которые могут посылать сообщения конкретному объекту.
Здравствуйте, DarkGray, Вы писали: DG>но как минимум ты согласен, что ООП с детерминистической финализацией является ООП?
Конечно.
DG>есть только два варианта: DG>либо в моделе утверждения фиксируются относительные для конкретного наблюдателя (например, который сидит в каждом конкретном объекте), DG>либо в моделе утверждения фиксируются абсолютно (и тогда появляется сторонний произвольный наблюдатель)
Не совсем. Утверждения вроде "не существует ни одного конкретного наблюдателя, сидящего в каком-либо конкретном объекте, который был бы способен наблюдать явление хххх" фиксируется абсолютно, но никакого стороннего наблюдателя не требует.
DG>но в любом ЯП это не так, т.к. всегда можно послать сообщение, которое покажет, что внутри Y1 есть x, которого нет в Y.
Это потому, что "любой ЯП" имеет средства нарушения или обхода инкапсуляции, которые расширяют базовую модель.
DG>чем это плохо, и кому мешает?
Ничем.
DG>дай тогда свое название для множества объектов, которые могут посылать сообщения конкретному объекту.
Ну, это все объекты, обладающие ссылками на этот объект. Да, с этой точки зрения недостижимый объект не имеет ни поведения, ни состояния.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>>но в любом ЯП это не так, т.к. всегда можно послать сообщение, которое покажет, что внутри Y1 есть x, которого нет в Y. S>Это потому, что "любой ЯП" имеет средства нарушения или обхода инкапсуляции, которые расширяют базовую модель.
вот именно поэтому ООП в реальной программе всегда рассматривается на конкретном подмножестве сообщений, а не на всех сообщениях которые только возможно.
Здравствуйте, Sinclair, Вы писали:
V>>Что ближе к такой последовательности 3-х операций РА, являющихся решением обоих уравнений: V>>tmp1 = X x Y V>>tmp2 = ограничение(x1=y1) tmp1 V>>result = проекция{x1, x2, .. xN} tmp2 V>>Можно записать в виде одной формулы, не суть, все равно будет 3 примитивные операции РА в ней. S>Или две. Задача решается через переименование и полуджоин.
Что есть полуджоин в РА?
S>Или через equi-джоин и проекцию. Но не суть.
equi-джоин в РА тоже нет. Есть соединение (произвольное), но им обычно не пользуюсь как базовым, бо он по определению составной: (A TIMES B) WHERE c, где каждая из двух операций уже входит в базис. Т.е. в любом случае составная операция получается после разложения на примитивные операции (как мои первые две строчки), независимо от того, как бы ты записал в исходной формуле.
S>Суть в том, что порядок вычисления X и Y не важен. Можно сначала рассчитать Y, а потом уже X. А можно — наоборот. Нам не важно, какие формулы стоят на местах X и Y, т.к. эти формулы заведомо не имеют побочных эффектов. Именно в этом суть декларативности РА.
Мы уже это обсуждали. Это не контраргумент к тому, о чем я говорил, бо порядок вычисления аргументов операций не определен в РА, так же как во многих, даже императивных языках. Я приводил пример. А если он не определен, то спор ни о чем. Что на что менять-то? Поэтому снова и снова скатываться на удобную тему порядка вычислений аргументов операций контрпродуктивно. Речь была о порядке вычисления зависимых операций. Я попросил вполне конкретно попробовать поменять местами приведенные операции, чтобы понять о чем речь. В принципе мне фиолетово, если хочешь цепляться за порядок вычисления аргументов, я могу уточнить (хотя уже уточнял не раз), что речь была о зависимых операциях РА. Тем более, что говорилось "в общем случае". Собсно, это и есть специфика РА, что в общем случае у нас одни операции ТРЕБУЮТ ПРЕДВАРИТЕЛЬНЫХ других операций, например, обязательно проекции/переименования перед OR, AND и остальными теоретико-множественными операциями, бо они работают ТОЛЬКО над совместимыми отношениями. Т.е. как ни крути, а придется обеспечивать совместимость ДО операций. Тоже самое относительно декартова произведения — в случае одноименных атрибутов в исходных отношениях переименование обязательно должно быть выполнено ДО произведения. И тут тебе ни одна из приведенных ранее формул преобразований/оптимизаций не поможет поменять этот порядок вещей. Т.е. даже если вариантов приведения аргументов к нужным много (а их почти бесконечное кол-во), то они все должны быть выполнены ДО самой операции продукции. Такова специфика, на которую многократно намекал. Вроде бы на поверхности.
V>>Нету сайд-эффектов, а последовательность вычислений есть. V>>Понимаешь... злобные функциональщики малость лукавят. Ф-ий подход зиждется на процедурном, а тот не отрицает зависимость результата от порядка вычисления. Просто коль отсутствуют побочные эффекты, то аргументы ф-ий можно вычислять в произвольном порядке. Но это малость не то же самое, что зависимые вычисления делать в произвольном порядке. А я на этой зависимости настаивал изначально, мне случай независимых аргументов неинтересен, на то они и независимые. S>Вы делали всеобщее утверждение про фиксированность порядка вычислений в РА. Вам показали что нет, не всегда он фиксирован.
Еще раз, отсюда и до бесконечности: в общем случае порядок вычислений менять невозможно.
V>>Не совсем так. Я уже пояснял каждый пример, где речь действительно идет об оптимизации. Например, повторные ограничения никто не делает, они объдиняются по AND ф-ий ограничений. но это происходит еще до РА, еще во время автоматической генерации алгоритма запроса. S>В целом правильно, хотя и несколько наивно.
Почему наивно? Есть типовые шаблоны перевода структурных формул над отношениями в плоские над атрибутами + правила, управляющими преобразованиями ограничений при подстановке шаблонов. Вот на этом уровне обычно всё и происходит. Т.е. исходные ограничения разбиваются (если это возможно) и его составляющие помещаются как можно раньше к аргументам. Напомню, что в РА аргументами ограничений являются только значения отрибутов и скаляры. Если атрибуты одного отношения — прямо идет к выборке как первой операции над отношением. Если больше, чем из одной — то на первую же "точку" вычислений, где становятся доступны все необходимые атрибуты. Я понимаю, что приведенные преобразования познавательны и полезны (они даже расшифровывают физический смысл некоторых операций), но на практике преобразования ограничений на уровне РА уже не делают. Незачем. Делают преобразования только через подстановку отношений, управляемую зависимостями. Как раз поэтому настаивал на возможности автоматического выбора индекса по таблице, бо СУБД знает достоверно о зависимостях м/у индексами и таблицей.
V>>>>Я таки настаиваю ее изобразить. Потому что если это именно ф-ия как "черный ящик", то аргументы будут для такой ф-ии вычислены, хоть и не будут использованы внутри самой ф-ии, а если не черный ящик, то таки хотелось посмотреть на примере SQL (откуда она пойдет в РА). G>>>SQL, в отличие от РА предполагает аппликативный порядок вычислений. Найдешь реализацию SQL где это не так — спокойно сделаю.
V>>И где это ограничение явно указано? G>В семантике функций.
Незачет. Похоже, ты не понимаешь, что есть ф-ия в РА.
V>>Опять же, ты не забыл замечание про минимум 2 вида аналитических выражений в РА — это собственно выражения РА и выражения-ограничения в выборке или разновидностях соединений. Какой уровень ты имел ввиду? G>А ты какие когда говорил про коммутативность?
Коммутативность справедлива на обоих уровнях. На то она и коммутативность. В РА почти половина операций комутативны. А если брать ф-ию ограничения, то она, в отличие от операций РА, не ограничена неким базисом. Ф-ия ограничения может быть произвольной математической ф-ий возвращающей предикат или приводимой к предикату. Ф-ия не обязана иметь аналитический вид, она может быть "черным ящиком" от аргументов. Единственное ограничение накладывается на аргументы ф-ии: они должны быть атрибутами или скалярами. Это именно то, почему спекуляции на порядке вычислений на уровне ф-ии ограничения РА работает плохо — ведь атрибуты и скаляры считаются уже вычисленными для РА, их НЕ НАДО ВЫЧИСЛЯТЬ.
V>>Меняет. Ты же походя присвоил коммутативность некоей произвольной ф-ии, показав затем, что она нихрена не коммутативна из своего определения. Меня это улыбнуло, понятное дело, просто любопытно таки докопаться до всей цепочки рассуждений, которое могло ТАКОЕ породить.
G>Я привел функцию, которая формальному определению коммутативности соответствует. У тебя какое-то другое определение?
Уровень РА не предоставляет ср-в для определения пользовательский ф-ий ограничений. Т.е. или пиши в аналитическом виде, и тогда рассуждения о необхомости вычисления атрибутов в твоих примерах становятся неприменимы. Или используй ф-ию как "внешнюю" по отношению к РА, т.е. как ф-ия "черный ящик" с аргументами, но тогда все аргументы должны быть в эту ф-ию поставлены, независимо от того, использует она их внутри или нет. А раз все аргументы должны быть подставлены, мы сможем использовать эту ф-ию только в той точке вычислений, где доступны все ее аргументы. Т.е. я понимаю, что ты хотел там выразить, типа того, что раз аргумент не используется, его можно не вычислять, и из-за этого можно поменять порядок применения ф-ии, например применить ранее, там где еще нет игнорируемого аргумента... но это малость мимо специфики РА, бо повторюсь, или аналитический вид ф-ии полностью доступен, или полностью недоступен, и тогда никаких предположений делать не стоит.
V>>Мешает то, что ф-ии ограничения, где аргументами идут отношения — это уровень исчисления кортежей, но не уровень РА. Задача РА как раз преобразовать "структурные" формулы РИ в "плоские" операции РА, где ф-ии ограничения будут в терминах операций над атрибутами кортежей. Курить определение ограничения в РА. G>То есть ты признаешь что далеко не любые коммутативные функции соответствуют тому что ты написал. Теперь давай выясним какие все таки соответствуют.
Соответствуют любые коммутативные из всего доступного мат-аппарата, если речь о ф-ии ограничения.
Если же речь о ф-иях из базиса РА (8 операций), то в их определении сказано, какие из них коммутативные, а какие нет.
V>>Попробуй кстате, "просто поменять вычисления местами" (С), мне любопытно. Замечания про ленивые vs энергичные я уже делал — ничего не меняется на уровне вычисления атрибутов кортежей.
Вопрос оставляю в силе. Бо даже если я и выражался "коряво", предполагая, что собеседники понимают, о чем речь, то вот в конкретном примере двусмысленности быть не может. Хорошо видно, что именно имелось ввиду.
V>>Я это понимаю, и даже давал больше по этой теме, но ты невнимательно читал. Да, именно, уровень РА нужен для того, чтобы в его терминах породить ВСЕВОЗМОЖНЫЕ решения исходной формулы, потому что коль на уровне РА отсутствуют ф-ии над отношениями, т.е. отстуствует вложенность в ограничениях, т.е. отсутствует рекурсия формул, становится возможным произвести оценку сложности операций. Так вот, там, где некий автоматический движок, перечисляющий всевозможные решения в терминах РА знает об декомпозиции исходной схемы на отношения, он может не просто породить s'(t), он может породить s'(t'), где t' — другое отношение, но сохраняющее зависимости исходной схемы. Прочувствовал разницу?
G>Совершенно не понял о чем ты.
Я еще тогда понял, что ты не понял. Речь о том, что некая исходная схема R {ABCDE} с зависимостями A->BC, C->DE, может быть нормализована к одной из форм следующей декомпозицией:
X:{ABC}, Y:{CDE}. + некая избыточность для прикладных нужд: Z:{CE}.
Так вот, формулы на уровне РИ задают условия над доменами и атрибутами, и если нам нужен в ответе или условии атрибут E, то он может быть как минимум в 2-х отношениях декомпозиции, поэтому будут существовать минимум два решения в терминах РА, которые неприводимы один к другому на уровне РА, т.к. будут оперировать различными исходными отношениями Y и Z, но будут приводимы на уровне РИ, через исходные зависимости.
G>Я ведь говорю не только о некоторых преобразованиях в пределах одной операции, а в перестановке вычислений для композиции операций. И это при том что композиция в общем случае некоммутативна.
Если ты все еще о вычислении аргументов, то давай эту тему прикроем. Будем считать, что порядок вычисления аргументов операций базиса РА не важен. А аргументы ф-ий ограничений заведомо являются вычисленными по своему определению.
G>>>Конечно движок субд опирается на семантику того что происходит и некоммутативность некоторых операций в общем случае ему не помеха.
V>>Так вот, к большому пребольшому сожалению, движки СУБД не имеют понятия о семантике, т.к. обычно не реализовано одно из самых важных правил Кодда, позволяющее сохранять зависимости исходного прикладного отношения и проведенной конкретной декомпозиции. СУБД не делает никаких предположений относительно избыточности данных, принадлежащих одному домену и одному "логическому" атрибуту в рамках всей схемы.
G>Это тебя совсем не туда понесло.
Наверно ты не понял, что я написал. Так и подмывает спросить, профильное ли было образование...
V>>Нету сайд-эффектов, а последовательность вычислений есть. G>Она всегда есть, но она не совпадает с порядком записи аргументов и композиции функций.
Ты имеешь ввиду порядок записи на бумаге?
Представь лучше в виде направленного графа/дерева. Не важен будет лишь порядок вычисления независимых узлов. Мне от этой нубской очевидности уже просто становится лень отмахиваться. Детсад.
V>>Понимаешь... злобные функциональщики малость лукавят. Ф-ий подход зиждется на процедурном, а тот не отрицает зависимость результата от порядка вычисления. Просто коль отсутствуют побочные эффекты, то аргументы ф-ий можно вычислять в произвольном порядке. Но это малость не то же самое, что зависимые вычисления делать в произвольном порядке. А я на этой зависимости настаивал изначально, мне случай независимых аргументов неинтересен, на то они и независимые. G>А что значит "зависимые вычисления" если у нас есть ленивость? А по сути ничего.
Ленивость ничего не меняет на уровне кортежей. Попробуй хотя бы немного применить ленивость к любому простому примеру — поймешь о чем речь. Тем паче, что существует два вида ленивости — это при вычислении скаляров (предикаты) и при вычислении мн-в (курсоры). Оба варианта ничего не меняют ни для ф-ии ограничения, ни для операций РА.
Нет никакого изменения порядка в случае ленивости, бо если идет обращение к атрибуту кортежа промежуточного результата, например, то этот атрибут будет вычислен в любом случае согласно того самого графа вычислений. Формулы ограничений задаются над кортежами, и абсолютно все-равно, каким образом вычисляются множества этих кортежей, когда рассматривается порождение одного кортежа. Т.е. порядок вычисления мн-в и атрибутов — это малость ортогонально и даже не оговаривается и из формулы никак не следует, чтобы можно было обсуждать "порядок". Я настаивал исключительно на порядке операций РА. Выше Синклеру обрисовал малость подробнее, в чем именно там специфика.
G>Если итоговый результат не не нужен или нужен не полностью, то "зависимые вычисления" можно и не вычислять.
Их придется вычислять. Ты не узнаешь, нужен ли кортеж или не нужен, не породив его. И опять же, порядок вычисления атрибутов в кортеже вообще из формул никак не следует, это тебя не в ту степь понесло.
G>И опять таки коммутативность тут никакой роли не играет.
Он играет при доступности аналитического вида ф-ии ограничения, т.к. позволяет проводить некоторые декомпозиции операций РА. С натяжкой можно сказать, меняя порядок вычислений при этом. Хотя, более строго — проводя ДРУГИЕ (преобразованные) вычисления.
Здравствуйте, vdimas, Вы писали:
V>Что есть полуджоин в РА? http://en.wikipedia.org/wiki/Relational_algebra#Semijoin_.28.E2.8B.89.29.28.E2.8B.8A.29
S>>Или через equi-джоин и проекцию. Но не суть.
V>equi-джоин в РА тоже нет. http://en.wikipedia.org/wiki/Relational_algebra#.CE.B8-join_and_equijoin
V>Мы уже это обсуждали. Это не контраргумент к тому, о чем я говорил, бо порядок вычисления аргументов операций не определен в РА, так же как во многих, даже императивных языках. Я приводил пример.
Простите, но ваш пример с C++ ничего не доказывает.
V>>>Не совсем так. Я уже пояснял каждый пример, где речь действительно идет об оптимизации. Например, повторные ограничения никто не делает, они объдиняются по AND ф-ий ограничений. но это происходит еще до РА, еще во время автоматической генерации алгоритма запроса. S>>В целом правильно, хотя и несколько наивно.
V>Почему наивно? Есть типовые шаблоны перевода структурных формул над отношениями в плоские над атрибутами + правила, управляющими преобразованиями ограничений при подстановке шаблонов. Вот на этом уровне обычно всё и происходит.
То, что вы рассказываете — это неполный пересказ алгоритма работы эвристического оптимизатора запросов. Они вышли из моды примерно в конце девяностых, когда в промышленность вошли cost-based оптимизаторы. Так что бывает, что делают и повторные ограничения, если это выгодно. Поэтому я и говорю, что наивно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>ЧТД. Наконец ты сознался. Не верно. Декларативность — это относительное понятие, ортогональное к побочным эффектам. Если есть неких два уровня абстракции, то один из них декларативен к другому, если примитивы более высокоуровневой абстракции выражаются в терминах операций над примитивами более низкоуровневой. S>Это определение — ваше личное изобретение. Оно не имеет никакого отношения к традиционной трактовке разницы между императивным и декларативным программированием.
В вики не смотрел?
Согласно второму определению, программа «декларативна», если она написана на исключительно функциональном, логическом или языке программирования с ограничениями. Выражение «декларативный язык» иногда употребляется для описания всех таких языков программирования как группы, чтобы подчеркнуть их отличие от императивных языков.
Итого, не так давно, буквально уже на моей памяти, появилось это "второе" определение, которое является искажением исходного термина (приведенного там же в Вики как первое). Например, программирование с ограничениями (или логическое как частный случай) подходит под декларативность по-определению. А функциональные языки приписали сюда злобные функциональщики, как ср-во борьбы с императивным программированием. Дело в том, что императивная программа тоже может быть декларативной и наоборот, функциональная может ей не быть, согласно первоначального определения. Скажу больше, любой язык с аннотацией типов заведомо содержит элементы декларативности. Но есть же нетипизированные функциональные, которые вовсе не декларативны "из коробки", а декларативны только на прикладном уровне, достижимого согласно исходного определения.
В общем, второе определение я оставлю лишь недобросовестным фанам функционального программирования, бо оно неверно в общем случае.
S>Но это бы ничего, если бы определение имело хоть какой-то практический смысл. Но нет — не имеет. В частности, по вашему определению РА одновременно более декларативна чем РИ, и менее декларативна чем оно же, и мы возвращаемся к тому, с чего начали: РА и РИ одинаково декларативны.
Неодинаково. В общем случае одна операция РИ требует нескольких операций из базиса РА, обратное неверно. Опять же, операции базиса РА не описывают характер результата, а только лишь действия над ним. Т.е. если у нас более одной операции, то в рамках каждой отдельной операции РА мы не знаем характер аргументов, поэтому не можем достоверно судить о характере результата. В то время как РИ описывает именно характер результата. Но на прикладном уровне, когда мы будем реализовывать эту РА, то сами операции РА могут служить высокоуровневыми инструкциями по отношению к некоему следующему уровню, и будут являться по отношению к нему декларативными, в контексте одной независимой операции РА.
V>>>>С результатами других операций все еще хуже, бо они получены в порядке индекса одного из исходных вариантов и могут не быть сортированы по отношению к требуемой следующей соединительной операции. S>>>А могут и быть. V>>Ну так вот тебе и умножение вместо сложения в том случае, где нет. Видел порой в плане запроса операцию сортировки промежуточных результатов перед join? А сложность алгоритмов внешней сортировки какова? S>Вы путаете общее с частным, делая всеобщее утверждение на основе некоторго частного случая.
Не смеши. Наоборот, это общий случай для СУБД. Реляционные базы изобретены для данных, заведомо больших размера оперативной памяти. Для данных же, помещающихся в оперативной памяти на гарвардской или фон-неймановской архитектуре есть куча других, на порядки более эффективных техник, чем эмуляция ассоциативной памяти в реляционных СУБД. В общем, тот факт, что иногда реляционные СУБД юзают не потому что они реляционные, а потому они надежные — это и есть скорее частный случай, чем общий.
S>>>Нет. Реляционная модель была разработана не для джойнов по "произвольной формуле". А джойны по значению атрибута отлично работают и для больших внешних хранилищ. V>>Еще раз — только при упорядоченности внешнего ключа одной и основного ключа другой таблицы. S>Зачем вы продолжаете делать некорректные всеобщие утверждения? Очевидно, что для перехода от O(M*N) к O(M*log(N)) достаточно отсортированности только одного аргумента.
Мнэээ... Речь изначально была об O(M+N), если я ничего не пропустил. Сорри, не могу здесь поддержать твой очередной спор с самим собой.
V>>У меня тоже свой опыт... когда были пни-200, то нейтивный сервер, со складом-бухгалтерией, использующий DCOM для клиентов в одноранговой сети с низлежащей базой на JET просто летал как бабочка, а поставили выделенный MS SQL в кач-ве базы на втрое более мощный комп — и все стало гораздо печальнее минимум на год, пока еще вдвое характеристики компов не подросли. Это и спасло при росте базы, потому как пришлось уже делать меньше оперативный период, что не всегда удобно. S>Я ваш опыт обсуждать не буду. Не глядя в исходники невозможно сказать, движок ли виноват или плохо написанное приложение.
Когда речь идет о простых выборках, напр. join по основному и вненему ключу, то всё слишком очевидно, чтобы предполагать непонятно что. Исходники смотрел на предмет чувствительности к отсутствию выравнивания физических данных, когда идут вперемешку атрибуты, некратные 32 бит (на тот момент). Бо машины того времени гораздо хуже читали невыровненные данные, чем нынешние.
V>>Тогда твоя боязнь очень избирательна, на примере разницы логического и физического плана запроса. Ты взял, да и привязался к конкретной реализации конкретной СУБД. S>Я нигде не привязался к конкретной реализации. Разница между логическим и физическим планами есть везде, где есть оптимизатор запросов. Читайте литературу.
Надо полагать, "читайте литературу по MS SQL"?
S>Нет, я не считаю, что сами по себе знания во вред. Вред приносят заблуждения. Вы продолжаете их изрекать со скоростью 2-5 заблуждения за пост. И я вижу некоторую систему в отдельных заблуждениях. Как глядя на реку, я не вижу валунов, лежащих на дне; но по ряби на поверхности я могу делать выводы об их наличии и расположении.
Гы, я вижу аналогичное, только даже не заблуждения, а невладение предметом. И попытки рассуждать "чисто теоретически" без владения спецификой обсуждаемого. Например, часть якобы моих заблуждений относится таки к твоим, например относительно способа хранения блобов и требования фиксированного размера записи для кластерных индексов. Или характерны спекуляции относительно порядка вычисления аргументов в РА. Детсад как он есть. Невладение спецификой. Даже если я в первый раз некоректно выразился, то владей ты — давно бы поправил, бо понял бы о чем речь. Дык нет, я и сам сразу же поправился, но ты перестать спекулировать на можешь. Итого, сдается мне, что рябь это вызвана больше ветром пустых слов и придирок к формулировкам, в условиях непонимания о чем даже идет речь. Я уже пытался одернуть, что по этой теме изначально пытался беседовать как с людьми "в теме", но потом мы съехали на вот это никого не красящее разжевывание на пальцах, как здесь: http://www.rsdn.ru/forum/philosophy/4563653.1.aspx
Должно быть уже просто стыдно за такой уровень максимум 3-го курса обучения от профей с более 10-тилетним стажем (или даже еще большим).
S>Так же и здесь — глядя на форум, я не вижу валунов у вас в голове. Но они проявляются в виде ряби на поверхности — некорректных утверждений, которые вы делаете.
Пока что согласился только насчет оценок быстродействия кластерного индекса, и то, там бабка на двое сказала. Бо даже лишняя страница по тем временам на том размере ОП (т.е. не та политика кеширования была), с теми скоростями жестки дисков и т.д., могла и дать такую ощутимую разницу. Боюсь, на современных ОС и современном железе воспроизвести сей эффект будет сложновато. Только поэтому предпочел согласиться. А все остальное якобы мои заблуждения — было бы неплохо доказать, бо пока что ни пример — то мимо, причем очень мимо... Скажем так, торчат уши сугубо личного опыта, весьма одностороннего при этом (коль уже не первый раз странная реакция на замечания относительно соотношения ОП и размера данных, сценариев использования реляционных СУБД и т.д.), к тому же, по одной всего СУБД.
Еще желание фехтовать и понтоваться будет, или таки ближе телу?
V>>Ты ткнул несоответствием в плане возможной неуникальности промежуточных и даже итоговых данных. V>>Давай уже ближе к телу. Обоснуй, как более широкие возможности SQL мешают использовать наработки более узкой модели? S>ОМГ. Вы сейчас какое конкретно моё утверждение пытаетесь оспорить? Найдите его и процитируйте. Я понимаю, вам удобнее спорить с тезисом, которого я не высказывал. Но всё же постарайтесь держаться в рамках беседы.
Утверждение о неприменимости аппарата РА на разных уровнях. Напомню: оспаривалось на уровне SQL со стороны программиста, и на уровне выбора индексов таблицы со стороны СУБД, при составлении плана запроса по этому SQL. Утверждалось тобой неоднократно. Приводились примеры несоответствия модели. Неоднократно ты настаивал на несоответствии теории м-в, лежащей в основе операций РА, и реальных записей в СУБД, которые могут повторяться. Чушь собачья оба аргумента, если всерьез. С самого начала языки, типа SQL, использовались прямо в обычных язках программирования. Нет абсолютно никакого противоречия выполнить одну операцию по одним "законам" математики, но результат этой операции обработать далее уже по неким другим "законам". Вот так примерно позволяют современные развитые диалекты SQL. Утверждать, что более широкая модель не позволяет пользоваться наработками более узкой — несомненно ошибочно. Ты пытался меня переубедить многократно. Насчет второго аргумена, повтора записей, многократно просил продемонстрировать механизм нарушения работоспособности операций РА — не увидел. И не увижу, бо теория мн-в требует лишь различимости элементов, а они уже различимы как-то со стороны любого механизма реализации РА, коль он способен порождать дублирующиеся записи. Это аксиоматично, т.к. это значит, что сей механим различает элементы как-то еще, помимо значений атрибутов. Не зря в SQL встроили ALL или DISTINCT, т.е. способность различать элементы таки прямо декларируется.
V>>Таки придется, иначе просто заумная балаболка. Реализация всегда отличается от модели, на то она и модель, я не понимаю, почему у тебя проблема конкретно в СУБД. S>Да у меня-то нигде проблем нет. Я вам СУБД привёл как один только пример. Я не виноват, что вы полезли в дебри, в которых плохо разбираетесь.
Если ты чего-то плохо понимаешь, это не значит, что я плохо разбираюсь. Это может значить, что я плохо объясняю, т.к. не всегда сразу вижу, что именно непонятно. Иногда требуется несколько итераций, как с несчастным NULL. Заметь, в первых постах я давал совсем уж мало деталей и рассуждений, бо считал, что общаюсь с коллегами, многое и так должно быть понятно. К сожалению, сие не так, для доказательств своих утверждений приходится рассуждения раскладывать чуть ли не на молекулы. Это скучно уже давно.
V>>Ведь обыгрывают переполнения целых чисел в программах? S>Да, я вам даже привёл пример на эту тему.
Потому и напомнил. Что различия реализации и модели есть, а для 99% сценариев не помеха. А где помеха — там есть совсем простые паттерны обхода ограничения реализации.
V>>И даже ограничения по точности чисел в плавающей. Однако же не мешает пользоваться всем аппаратом математики в вычислениях. S>Ну, таки мешает. Я вам даже пример привёл на эту тему.
И я показал, что таки не очень мешает. И оценка в 1% от таких сценариев — это еще очень оптимистично, бо я с переполнениями борюсь даже далеко не в каждом проекте, где многие тысячи целочисленных переменных.
S>А уж в числах с плавающей запятой совсем копец: там аппаратом математики вещественных чисел пользоваться практически вовсе нельзя.
Ну-ну, не разгоняйся так быстро. Я такими аппаратами пользуюсь, что поверь, придумать их самому, специально под реализации вещественных чисел — ну просто никак. Например, в области обнаружения и обработки сигналов. Всего навсего погрешности округлений представляют как аддитивный шум, поэтому всё несоответствие реализации и модели сводится к оценке шума (тем более достоверно известен его спектральный состав), т.е. к достижению требуемого отношения сигнал/шум. И для этого тоже аппарат есть — "энтропийный": H + Y = 1 (Взаимосвязь энтропии и информации). А формула самой энтропии физику по образованию должна быть известна. Точно так же как должны быть известны правила сложения источников белого шума, например. Всё решаемо, не надо паники. Фактически выводится на кончике пера для каждого оператора/преобразователя для конкретной разрядности и соотношения граничной интересующей частоты и частоты квантования.
S>Но давайте не будем ещё и в плавающую запятую лезть — у меня не хватит энергии на всё.
Гы, почему нет? Мне уже весело. РА использовать нельзя, математику использовать нельзя... Синусы и косинусы я тоже не имею права вычислять?
V>>Улыбнуло, я думал ты уже понял, что тебе говорили. V>>Покажи-ка мне стоимость нахождения записи в случае кластерного индекса внутри страницы, если размер самой записи нефиксированный? S>Что вы называете "нахождением"? Указать, где начинается запись? Или прочесть некоторое поле F, не входящее в ключ индекса? Если второе — то стоимость в терминах логических чтений, очевидно, равна log(N, KeysPerPage)+ PagesPerRecord, где PagesPerRecord — количество страниц, занятых записью.
э нет, имеется ввиду стоимость поиска внутри уже прочитанной страницы. Логическое чтени — это конечно здорово, бо внешняя память медленная. Да только ресурсов процессора практически не ест, DMA всю работу само делает. А вот проход потом по записям внутри страницы — это уже 8к надо прогнать через кеш процессора, если размер записи не будет фиксированный. А вот это уже очень даже ест разделяемые ресурсы, т.е. даже те, где логические чтения не требуются.
S>Встречный вопрос: а что, для некластерного индекса ситуация будет какой-то другой?
Да, для некластерного указан точный адрес записи, в то время как для кластерного указан адрес диапазона с точностью до страницы. Фиксированный размер записи позволит найти запись двоичным поиском или по золотому сечению, резко уменьшив кол-во сравнений ключа с требуемым. Ну и там кеши проца и всё такое тоже играют рояль на современных многоуровневых кешах.
S>И, кстати, выходные прошли. Что там у вас со смелым экспериментом по определению количества логических чтений в кластерных и некластерных индексах? Удалось получить разницу хотя бы в одну страницу?
Пример надо модифицировать, чтобы получить разницу в страницу. Остальные соображения уже высказал в этом же посте выше.
S>Я ничего не путаю. Я понимаю, что вы пытаетесь обосновать порядок вычисления аргументов одних операций (над отношениями) коммутативностью других (над атрибутами).
А только это и тянет на изменение порядка зависимых операций.
S>Тем не менее принципиальным остаётся отсутствие побочных эффектов в запросах.
Детсад как он есть. Как еще побочные эффекты в операциях read-only? Их нет в таких сценариях даже в самых императивных языках. А ты можешь сдвинуться чуть дальше уровня 0, разве не интересно?
S>Поэтому когда мы берём дерево реляционных операций, листья в нём могут вычисляться в любом порядке. Это даже если мы не рассматриваем все эти эквивалентности, которые позволяют нам ещё и перестраивать само дерево.
Хе, вот только я хотел показать суть спекуляций на порядке вычисления аргументов на примере графа выражений (как выше показал твоему коллеге), ты и сам догадался. Хотя я самого начала попытался подобные спекуляции отрезать, сказав, что не интересует порядок вычисления НЕЗАВИСИМЫХ аргументов. Но ты так-то пяток постов именно по независимым и прошелся, увлекательно общаясь сам с собой. Красава. Нет чтобы спросить (коль сразу в голове специфика не нарисовалась), что именно я имел ввиду, говоря, что важна последовательность операций. Ведь что-то же подвигнуло утверждать это неоднократно? Не любопытно было? Ну натурально, вроде я не только в Политике отмечаюсь, да и кода за все эти годы выложил всякого достаточно на многих наглухо разных языках, вплоть до такого: http://www.contextfreeart.org/gallery/view.php?id=2496 Т.е. как бы таки понятно, что как минимум хоть каким-то программистом, но работаю , т.е. твой оппонент хоть как-то должен понимать, что если речь идет о независимых аргументах, то при тум здесь вообще обсуждение порядка их вычисления? Даже пример С++ был, где порядок вычисления вообще не определен by design, во как!!! Но ты же будешь мне пытаться это же самое объяснять примерно еще пяток постов, правильно? Ну не детсад, а? Скажу честно, на всю эту скукотищу мне просто было лень отвечать. Ведь не поспоришь с молодыми, что философия давно превратилась в УГ. Ни воображения, ни полета мысли. Хождения по кругу уровня детсада и понты, больше ничего.
S>>>Понятно. Просто есть два движка с одинаковым названием: Jet Blue и Jet Red. Внутри они принципиально разные. V>>Ну, в VB тоже была своя встроенная ADO, так же была либа для С и ADO-обертка над ней в MFC. S>Обёртки тут ни при чём. Я про engine. В MS Access использовался Jet Red. Jet Blue используется в Microsoft Exchange и Active Directory.
S>Что именно вы собрались "обыгрывать" в дополнительной таблице T2? Вынести туда IK и ссылку на PK основной таблицы? Ну так для чтения атрибутов A1..Ax вы получите по-прежнему log(N) чтений на поиск значения, + log(N)+M чтений на доступ к основной таблице.
Хм, потеря контекста... Никакого PK на основную таблицу не требуется. Иначе не было смысла в этой избыточной. В этой таблице должны быть ровно те атрибуты, что нужны для сценария/сценариев, которые обслуживает наша избыточность. Была задача — поиметь более одного кластерного индекса, коль единственный по условию мы отдали одному из внешних ключей, как я рекомендовал.
S>Если вы планируете включить в T2 что-то из A1..Ax, то их же можно включить в тот же неуникальный индекс и иметь те же преимущества доступа за log(N) без накладных расходов, связанных с поддержкой отдельной таблицы.
Это зависит от того, насколько более широкий такой "расширенный" индекс выйдет. Более широкий — более дорогой даже в выборке. Конечно, ради пары полей int32 овчинка может выделки не стоить, но я не собирался обсуждать количественные эффекты, а просто ответил на твой вопрос: "а зачем?". Надеюсь, ответил. К тому же, упорядоченность кластерного индекса работает хорошо для всяких join в терминах эффективности, невыразимых в логических чтениях. Например, очень эффективно читать страницы, идущие подряд на диске, тогда нам сильно помогает кеш низлежащей ОС, со всякими новомодными технологиями, и даже сами современные диски со встроенным упреждающим чтением.
V>>Для случая вставки в кластерный индекс всегда трудоемкость минимум O(n), помимо операции обновления дерева индекса, которая будет одинаковой стоимости что для исходной таблицы, что для избыточной. Но с этой сложностью борются, оставляя "зазоры" после удаления, чтобы свести ее ближе к логарифму. S>Откуда вы взяли трудоёмкость вставки в O(N)? Стоимость всегда логарифмическая — это же дерево.
Дело в том, что страницы данных кластерного индекса связаны м/у собой, что позволяет перебирать их подряд при всяких join без обращения к дереву индекса. Т.е. стоимость будет стремиться к логарифмической, только если если резервировать зазоры в данных, а если не резервировать, то все данные справа от вставки придется двигать. Внутри страницы двигают по-любому и вообще стараются поддерживать некий однородный коэф заполнения.
Ясно, это не базис РА, это комплексная операция. Идите, как ты любишь говорить, читайте букварь. Характерно, что по твоей же ссылке дана формула этой операции в терминах РА над другой комплексной операцией, для которой, в свою очередь дана расшифровка в базисе:
Так же характерно, что операция декартового произведения в РА есть, ссылка на нее в формулах есть, но определения её в статье, похоже, нет. Это баг статьи, надо слать замечание на доработку.
Туда же.
Хотя пример показательный. Эти комплексные операции отражают самые популярные сценарии в языке SQL. Вот тебе пример того, как целая формула из РА рассматривается как единое целое, т.е. та самая оценка по сложности может быть дана не над базисной операцией, а уже над такой комплексной.
V>>Мы уже это обсуждали. Это не контраргумент к тому, о чем я говорил, бо порядок вычисления аргументов операций не определен в РА, так же как во многих, даже императивных языках. Я приводил пример. S>Простите, но ваш пример с C++ ничего не доказывает.
Он доказывает наличие спекуляций вокруг известных вещей. ИМХО, за неимением чего сказать по самой сути вопроса. Мне, по аналогии с тем, как ты вцепился в эти аргументы, теперь десяток раз копипастить, какие именно врожденные ограничения реляционной алгебры требуют определенного порядка операций?
V>>>>Не совсем так. Я уже пояснял каждый пример, где речь действительно идет об оптимизации. Например, повторные ограничения никто не делает, они объдиняются по AND ф-ий ограничений. но это происходит еще до РА, еще во время автоматической генерации алгоритма запроса. S>>>В целом правильно, хотя и несколько наивно.
V>>Почему наивно? Есть типовые шаблоны перевода структурных формул над отношениями в плоские над атрибутами + правила, управляющими преобразованиями ограничений при подстановке шаблонов. Вот на этом уровне обычно всё и происходит. S>То, что вы рассказываете — это неполный пересказ алгоритма работы эвристического оптимизатора запросов. Они вышли из моды примерно в конце девяностых, когда в промышленность вошли cost-based оптимизаторы. Так что бывает, что делают и повторные ограничения, если это выгодно.
Покажи пример, где выгодно.
S>Поэтому я и говорю, что наивно.
Скорее, от отсутствия опыта по таким преобразованиям. Упомянутые алгоритмы пребирают всевозможные комбинации решений уровня РА для исходной формулы РИ. Хотя я это говорил уже не раз, видать ты подзабыл. А как затем затраты оценивают на уровне РА — мы уже прошли с самого начала. И кстати, что такое "эвристический алгоритм" — я понятия не имею.
Здравствуйте, vdimas, Вы писали:
S>>Это определение — ваше личное изобретение. Оно не имеет никакого отношения к традиционной трактовке разницы между императивным и декларативным программированием.
V>В вики не смотрел? V>В общем, второе определение я оставлю лишь недобросовестным фанам функционального программирования, бо оно неверно в общем случае.
И какое это имеет отношение к изобретённому вами определению? Я с
V>Неодинаково. В общем случае одна операция РИ требует нескольких операций из базиса РА, обратное неверно.
Ну начинается. Вы собрались ещё и метрику "количества операций" вводить? Это всё равно заведёт вас в тупик — именно поэтому ваша идея определения декларативности не получила широкого распространения.
V>Опять же, операции базиса РА не описывают характер результата, а только лишь действия над ним.
Да ладно! Как раз характер результата они и описывают. Скажем, оператор "сигма" никаких действий не описывает. Он просто говорит "результат будет содержать только кортежи, удовлетворяющие указанному ограничению". Что это по-вашему, как не характер результата?
V>Не смеши. Наоборот, это общий случай для СУБД. Реляционные базы изобретены для данных, заведомо больших размера оперативной памяти.
Вы невнимательно читаете. V>Мнэээ... Речь изначально была об O(M+N), если я ничего не пропустил. Сорри, не могу здесь поддержать твой очередной спор с самим собой.
К счастью, в форуме записаны все ходы. "Изначально" речь шла о том, что вы почему-то заложили O(N*M*K) в стоимость операции join трёх составляющих:
Насчет порядка: если некая соединительная операция из 3-х (грубо) составляющий выполняется в 4 раза быстрее, что каждая в среднем стала выполняться быстрее в корень 3-й степени из 4.
Я вам тактично намекнул, что для того, чтобы это было так, нужно сочетание большого количества факторов, которые редко встречаются в жизни. Нужно, чтобы объём всех отношений был больше объёма доступных буферов, и чтобы джоин был по произвольной формуле, а не по равенству атрибутов.
Более реалистичный случай — join по внешнему ключу — стоит O(N*log(M)) независимо от размера отношений N и M. А для star-join с тремя составляющими стоимость будет O(N*log(M*K)). Так что если всё вместе выполняется в 4 раза быстрее, то каждая из операций ускорилась вовсе не в корень третьей степени из четырёх.
V>Когда речь идет о простых выборках, напр. join по основному и вненему ключу, то всё слишком очевидно, чтобы предполагать непонятно что.
Ну, судя по вашим перлам про кластерные индексы и про оценки стоимости джойнов, очевидных вещей вообще не существует. Объяснять надо буквально каждую запятую.
Многие приложения, построенные по принципу select N+1 и client-side join, прекрасно работают на встроенных движках, и даже на тупом ISAM.
И, естественно, со страшной силой начинают сливать при переходе на клиент-серверную архитектуру, потому что там это честный roundtrip с парсингом и исполнением каждого запроса. Поэтому всякий раз, как я вижу упоминание тормозов при переходе с фокспра на оракл или с аксесса на MSSQL, я начинаю подозревать худшее.
Но это, естественно, не единственное объяснение. Понятно, что, скажем, в линейном чтении с локального диска любой dBase порвёт любой сиквел как тузик грелку. Поэтому я и написал, что не могу делать выводы о вашем опыте, не глядя в исходники приложения.
V>Надо полагать, "читайте литературу по MS SQL"?
Я вам давал ссылку. "Системы баз данных. Полный курс".
V>Гы, я вижу аналогичное, только даже не заблуждения, а невладение предметом. И попытки рассуждать "чисто теоретически" без владения спецификой обсуждаемого. Например, часть якобы моих заблуждений относится таки к твоим, например относительно способа хранения блобов и требования фиксированного размера записи для кластерных индексов.
О да, конечно. Я жду с нетерпением результатов ваших замеров, которые вы планировали провести на выходных.
V>Пока что согласился только насчет оценок быстродействия кластерного индекса, и то, там бабка на двое сказала. Бо даже лишняя страница по тем временам на том размере ОП (т.е. не та политика кеширования была), с теми скоростями жестки дисков и т.д., могла и дать такую ощутимую разницу.
Да-да, разницу в "десять-пятнадцать страниц". Я понял. Но я же говорю не о том, что ваш конкретный проект работал как-то не так. Я говорю ровно про то, что ваш подход к исследованию мира даёт вот такие вот результаты: вы увидели некий эффект, и вместо того, чтобы разобраться, поставили кластерные индексы на полочку "тормозное г". С тех пор и память стала другая, и диски несколько другие, но ментальная модель кластерных индексов в вашей голове изменений не претерпела — потому, что там монолит. Нет границы между архитектурой кластерных индексов и её реализацией.
V>Боюсь, на современных ОС и современном железе воспроизвести сей эффект будет сложновато.
Боюсь, вы по-прежнему не понимаете предмета обсуждения. Количество логических чтений в MS SQL никак не зависит ни от ОС, ни от железа. Запрос, который я привёл, покажет те же результаты на вашем мега-сервере, что и на моём ноутбуке. Только у меня дождаться результатов с pageCount = 100000 будет трудно, потому что ограничена скорость записи на винт.
V>Только поэтому предпочел согласиться. А все остальное якобы мои заблуждения — было бы неплохо доказать, бо пока что ни пример — то мимо, причем очень мимо...
Да без проблем.
V>Утверждение о неприменимости аппарата РА на разных уровнях. Напомню: оспаривалось на уровне SQL со стороны программиста, и на уровне выбора индексов таблицы со стороны СУБД, при составлении плана запроса по этому SQL.Утверждалось тобой неоднократно. Приводились примеры несоответствия модели. Неоднократно ты настаивал на несоответствии теории м-в, лежащей в основе операций РА, и реальных записей в СУБД, которые могут повторяться. Чушь собачья оба аргумента, если всерьез. С самого начала языки, типа SQL, использовались прямо в обычных язках программирования. Нет абсолютно никакого противоречия выполнить одну операцию по одним "законам" математики, но результат этой операции обработать далее уже по неким другим "законам".
Всё правильно. Вот только я никаких противоречий и не декларировал. Я объяснял, что одних законов РА недостаточно для функционирования реальных СУБД. И что нужно понимать, где начинаются "дополнительные подробности". Иначе можно запросто попасть впросак, написав бред типа "стоимость операции join пропорциональна O(N*M)".
V>Потому и напомнил. Что различия реализации и модели есть, а для 99% сценариев не помеха. А где помеха — там есть совсем простые паттерны обхода ограничения реализации.
В программировании все помехи — исключительно в голове. Именно поэтому так важно хорошо во всём разбираться.
V>И я показал, что таки не очень мешает. И оценка в 1% от таких сценариев — это еще очень оптимистично, бо я с переполнениями борюсь даже далеко не в каждом проекте, где многие тысячи целочисленных переменных.
Ну я рад за ваши проекты. Это всего лишь означает, что ваши программы — некорректны, просто вас не везде поймали за руку ваши QA. И, кстати, из двух предоженных вами решений проблемы с переполнением при построении компаратора одно не работает.
V>Ну-ну, не разгоняйся так быстро. Я такими аппаратами пользуюсь, что поверь, придумать их самому, специально под реализации вещественных чисел — ну просто никак. Например, в области обнаружения и обработки сигналов. Всего навсего погрешности округлений представляют как аддитивный шум, поэтому всё несоответствие реализации и модели сводится к оценке шума (тем более достоверно известен его спектральный состав), т.е. к достижению требуемого отношения сигнал/шум. И для этого тоже аппарат есть — "энтропийный": H + Y = 1 (Взаимосвязь энтропии и информации). А формула самой энтропии физику по образованию должна быть известна. Точно так же как должны быть известны правила сложения источников белого шума, например. Всё решаемо, не надо паники. Фактически выводится на кончике пера для каждого оператора/преобразователя для конкретной разрядности и соотношения граничной интересующей частоты и частоты квантования.
Ну вот видите, как здорово. Я же не говорю, что нерешаемо. Я говорю, что надо понимать, что "чистая" математика, где все сигналы без шумов, тут неприменима. И вы это понимаете, т.к. пользуетесь специальными моделями, куда входят разрядности и частоты квантования.
V>э нет, имеется ввиду стоимость поиска внутри уже прочитанной страницы. Логическое чтени — это конечно здорово, бо внешняя память медленная. Да только ресурсов процессора практически не ест, DMA всю работу само делает. А вот проход потом по записям внутри страницы — это уже 8к надо прогнать через кеш процессора, если размер записи не будет фиксированный. А вот это уже очень даже ест разделяемые ресурсы, т.е. даже те, где логические чтения не требуются. V>Да, для некластерного указан точный адрес записи, в то время как для кластерного указан адрес диапазона с точностью до страницы. Фиксированный размер записи позволит найти запись двоичным поиском или по золотому сечению, резко уменьшив кол-во сравнений ключа с требуемым. Ну и там кеши проца и всё такое тоже играют рояль на современных многоуровневых кешах.
Отлично. Просто отлично. И вы имеете наглость утверждать, что это я не разбираюсь в практической стороне вопроса?
Поясняю по пунктам.
1. Временами сканирования страниц в ОП при подсчёте стоимости можно пренебречь. Потому что соотношение стоимостей чтения страницы с диска и из памяти чудовищно велико.
2. Размеры записей внутри страницы MS SQL не фиксированы. Независимо от наличия или отсутствия кластерного индекса. Это вы с фокспро перепутали.
Зачем вы читали исходники, если нихрена из них не поняли? Читайте лучше RTFM — там картинки есть: http://msdn.microsoft.com/en-us/library/ms190969.aspx. Цитирую:
A row offset table starts at the end of the page, and each row offset table contains one entry for each row on the page. Each entry records how far the first byte of the row is from the start of the page. The entries in the row offset table are in reverse sequence from the sequence of the rows on the page.
3. В некластерном индексе не указан "точный адрес записи". Адресация записей в странице при помощи RID — косвенная. Приходится лезть в row offset table. Это если по таблице нет кластерного индекса. А если есть, то в некластерном индексе вместо RID хранится ключ кластерного индекса, и поиск выполняется точно так же, как и для кластерного индекса.
3. Так что, никакого двоичного поиска или золотого сечения для нахождения записей внутри страницы не применяется.
Вопросы есть?
V>Пример надо модифицировать, чтобы получить разницу в страницу. Остальные соображения уже высказал в этом же посте выше.
Зачем же модифицировать? Этот пример и так ставит кластерный индекс в заведомо невыгодное положение.
V>Детсад как он есть. Как еще побочные эффекты в операциях read-only? Их нет в таких сценариях даже в самых императивных языках.
Вот именно. Пока операции read-only, никаких побочных эффектов нет, и можно выполнять эти операции в любом порядке. Или вовсе не выполнять, если не хочется.
Императивность начинается там, где появляются побочные эффекты.
V>Хе, вот только я хотел показать суть спекуляций на порядке вычисления аргументов на примере графа выражений (как выше показал твоему коллеге), ты и сам догадался. Хотя я самого начала попытался подобные спекуляции отрезать, сказав, что не интересует порядок вычисления НЕЗАВИСИМЫХ аргументов.
Ну мало ли что лично вас не интересует.
V>Хождения по кругу уровня детсада и понты, больше ничего.
Понты, коллега, в этом топике видны только от вас. И опыт-то у вас больше других, и исходники-то вы у закрытых продуктов читали, и даже одногруппник вас с полуслова понимает. А все остальные тут так, погулять вышли.
V>Хм, потеря контекста... Никакого PK на основную таблицу не требуется. Иначе не было смысла в этой избыточной. В этой таблице должны быть ровно те атрибуты, что нужны для сценария/сценариев, которые обслуживает наша избыточность. Была задача — поиметь более одного кластерного индекса, коль единственный по условию мы отдали одному из внешних ключей, как я рекомендовал. V>Это зависит от того, насколько более широкий такой "расширенный" индекс выйдет. Более широкий — более дорогой даже в выборке. Конечно, ради пары полей int32 овчинка может выделки не стоить, но я не собирался обсуждать количественные эффекты, а просто ответил на твой вопрос: "а зачем?". Надеюсь, ответил.
Да нет, пока что не ответил. Напомню: вы предположили, что неуникальный некластерный индекс — "почти всегда спорное решение", и вместо этого типа лучше иметь отдельную таблицу. Вот я и пытаюсь понять, с какого момента начинается выгода в такой "почти всегда бесспорной" архитектуре. Пока что я вижу, что вы затрудняетесь с пояснениями.
Вы не стесняйтесь — спрашивайте, если есть какие-то проблемы с пониманием архитектуры.
Вот, кстати, из новостей в MS SQL есть included columns, которые позволяют получить бенефиты кластерных индексов без применения кластерных индексов ровно в тех случаях, которые вы описываете как повод для "обыгрывания в отдельном отношении".
V>К тому же, упорядоченность кластерного индекса работает хорошо для всяких join в терминах эффективности, невыразимых в логических чтениях. Например, очень эффективно читать страницы, идущие подряд на диске, тогда нам сильно помогает кеш низлежащей ОС, со всякими новомодными технологиями, и даже сами современные диски со встроенным упреждающим чтением.
Я вижу, вы делаете несколько неявных предположений. Как обычно, демонстрируя трогательное незнакомство с предметом. Поясняю по пунктам:
1. Вы предполагаете, что страницы в кластерном индексе идут подряд на диске. Конечно же, в общем случае это не так, и механизм выделения страниц работает совершенно независимо от кластерности индекса. Если кластерный индекс вы применяете по монотонному ключу (например, это именно так для полей int identity), то механизм выделения страниц приведёт к повышению шансов на то, что соседние страницы окажутся в пределах одного экстента. В остальных случаях распределение страниц по екстентам более-менее случайно.
2. Вы предполагаете, что движок СУБД будет настолько тупым, что станет полагаться на механизмы кэширования ОС. Для случая MS SQL это, конечно же, не так. Он открывает файлы базы со специальными опциями типа FILE_FLAG_NO_BUFFERING, FILE_FLAG_OPEN_NO_RECALL, FILE_FLAG_WRITE_THROUGH, FILE_FLAG_RANDOM_ACCESS. Это чтобы дать по рукам ОС, которая захочет применить новомодные технологии кеша. Я надеюсь, вам не нужно объяснять, что делают эти флаги?
3. Конечно же, та часть движка СУБД, которая отвечает за подкачку страниц, написана не идиотами. Поэтому есть predictive reading, которому не шибко важно, в каком именно порядке идут leaf-страницы. Страницы, которые нам потребуется прочесть, ставятся в очередь, а очередь упорядочивается по адресу страницы.
S>>Откуда вы взяли трудоёмкость вставки в O(N)? Стоимость всегда логарифмическая — это же дерево. V>Дело в том, что страницы данных кластерного индекса связаны м/у собой, что позволяет перебирать их подряд при всяких join без обращения к дереву индекса.
Ну да, страницы формируют связный список. Не массив. S>>Т.е. стоимость будет стремиться к логарифмической, только если если резервировать зазоры в данных, а если не резервировать, то все данные справа от вставки придется двигать.
1. Если резервировать зазоры в данных, то вставку можно выполнить за O(1). Это понятно, почему, или нет?
2. Ок, предположим, у нас нет зарезервированных зазоров в данных. Конечно же, "все" данные справа от вставки двигать не придётся.
Мы просто разделим пополам ту страницу, на которой не хватило места, и вернёмся к коэффициенту заполнения 50%. Понятно, что сам по себе split потребует доступа к двум страницам (O(1)). Ну, и понятно, что в худшем случае нам придётся поправить O(log(N)) страниц на пути вверх к корню, чтобы отразить этот split.
Ну, то есть это как бы основы B-деревьев, но вы спрашивайте, если что-то непонятно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
, т.е. твой оппонент хоть как-то должен понимать, что если речь идет о независимых аргументах, то при тум здесь вообще обсуждение порядка их вычисления? Даже пример С++ был, где порядок вычисления вообще не определен by design, во как!!! Но ты же будешь мне пытаться это же самое объяснять примерно еще пяток постов, правильно? 
