DG>>вопрос всё тот же: DG>>почему функцию Inverse корректно преобразовывать в метод Inverse S>В общем случае — нет, некорректно. Вы же сами привели пример, где эти реализации не ведут себя одинаково. В конкретном коде это может оказаться корректным. То есть, к примеру, если вы выполнили в первом и втором случае все оптимизации компилятора — инлайнинг, распространение констант, алгебраические преобразования — и получился одинаковый целевой код, то да, преобразование было корректным.
ответ не конструктивный, и соответственно бесполезный — потому что не фиксирует, каких условий достаточно для входа, чтобы сделать определенный вывод про выход.
S>Ну, если у вас есть готовый автоматический преобразователь, то напустите его на код, использующий "функцию проверки". Он вам и выдаст результат.
так вот этот преобразователь и выдает так, как я говорил выше...
Здравствуйте, vdimas, Вы писали: V>Хе, в С++ тоже нет никакого вычислителя явно.
1. В С++ есть изменяемые переменные. Ничего подобного в РА нет.
2. В С++ есть чётко определённый порядок выполнения операций при вычислении аргументов бинарных операторов. Ничего подобного в РА нет.
3. В С++ есть побочные эффекты от операций (проявляющиеся в изменении состояния "вычислителя", т.е. значений переменных), из-за которых нужен пункт 2. Ничего подобного в РА нет. V>Речь шла об упорядоченности операций. Ты заявлял о том, что последовательность операций не принципиальна.
Всё наоборот. Вы кричали, что я вообще никогда не могу менять порядок операций в заданной РА-формуле. Я вас тыкаю носом в раздел, где английским по белому написано, при каких условиях и какие операции можно местами менять.
V>Для конкретной выбранной формулы — навязывает еще как. Ты не обратил внимание на характер "раскрытия скобок" по ссылке? Зачастую никакие скобки раскрыть невозможно,
"Зачастую" != "всегда". Учите формальную логику — в жизни пригодится.
V>Log2(N) просматривается в любом случае, отличие в том самом К.
Откуда вы взяли 2 в основании логарифма? Чему у вас равно K? За счёт чего у вас K при кластерном индексе окажется больше, чем при некластерном?
V>Запущу на досуге, но другой. У тебя два индекса идут по одной таблице, а это не соответствует нашему спору.
Нет проблем. Вот вам вариант с двумя таблицами — тут я вообще выкинул всё лишнее. Даже специально для вас заполнил padding данными, чтобы не было искушения сказать, что я смухлевал. Ну, и чтобы было понятно, что происходит, вывел статистику по allocation units.
create database TestDB;
GO
use TestDB;
GO
CREATE TABLE [dbo].[Test1]
(
id int identity primary key clustered,
padding char(7950) not null default replicate('#', 7950)
)
CREATE TABLE [dbo].[Test2]
(
id int identity primary key nonclustered,
padding char(7950) not null default replicate('#', 7950)
)
GO
CREATE PROCEDURE [dbo].[Initialize]
@size int
AS
set nocount on;
delete from Test1;
delete from Test2;
declare @i int;
set @i = 0;
while @i< @size
begin
insert into Test1 default values;
insert into Test2 default values;
set @i = @i + 1;
if (@i / 100)*@i = @i
begin
commit tran
begin tran
end
end
RETURN 0
GO
set nocount on
begin tran
declare @pageCount int
set @pageCount = 10000 -- укажите здесь количество страниц, которые вы хотите поместить в эту таблицу exec Initialize @pageCount
SELECT left(o.name, 10) AS table_name, p.index_id, left(i.name, 25) AS index_name , left(au.type_desc, 25) AS allocation_type, au.data_pages
FROM sys.allocation_units AS au
JOIN sys.partitions AS p ON au.container_id = p.partition_id
JOIN sys.objects AS o ON p.object_id = o.object_id
JOIN sys.indexes AS i ON p.index_id = i.index_id AND i.object_id = p.object_id
WHERE o.name like N'Test%'
ORDER BY o.name, p.index_id;
set statistics io on
declare @testid int
select @testid = cast(round(RAND()*@pageCount, 0, 0) as int)
select len(padding) from Test1 where id = @testid;
select len(padding) from Test2 where id = @testid;
commit tran
use master
drop database TestDB
Как вы думаете, какая будет разница в "К перед Log2(N)"?
V>И? Результат-то удовлетворяет. Что первично, а что вторично?
Первично то, что у запросов SQL есть определённая семантика. И она определена так, как я говорю, а не так как вам хочется, и не так, как в РА.
V>"Потом" — это всё еще в рамках того же выражения.
Это неважно. Промежуточные результаты в SQL-запросе тоже имеют тип.
V>Ага, таки неканонические данные не особо доступны извне (обычно это действительно так в нормальных приложениях). Дык, о чем речь тогда? О тонкостях реализации самого сервера? Смешно.
Речь о тонкостях стандарта SQL, которые отличают его модель от реляционной модели.
V>Ну, значит мало ты переносил SQL-кода м/у базами. Так и будешь теоретизировать. Более 90% SQL-кода приходится переписывать/исправлять, при переходе с одной СУБД на другую.
Вот у вас столько апломба при суждениях о моём опыте. Вы облажаться с разбегу не боитесь?
По делу: вот ну нас нынешний проект. Работает одновременно на двух СУБД. Довольно-таки разных. Как вы думаете, сколько процентов SQL-кода в нём являются СУБД-специфичными?
Если ваше предположение выше верно, то должно быть 90%.
S>>Кстати, об IS NOT NULL: выражение R IS NOT NULL не эквивалентно выражению NOT R IS NULL.
V>Oh my God V>Можно я таки буду использовать то имя константы, которое использовано во всех виденных мною и тобою в реальной работе СУБД?
Ну, если вы мне покажете, где именно "в реальной работе СУБД" логическое выражение возвращает NULL, то на здоровье — используйте его.
V>Что нет никакого несоответствие с РА. Есть прописанное в стандарте правило, которое приводит результат выражения из домена { true, false, null} к домену { true, false }. Это преобразование в терминах РА обыгрывается вводом такого отношения и вперед! Твой пример становится очень даже решабельным в терминах РА, хотя ты трижды перед этим утверждал обратное.
Речь не о "решабельности", а о соответствии модели. Теперь у вас уже выходит, что в каждом select у нас неявно выполняется оператор объединения со специальным отношением SQLLogicToBoolean и последующим оператором выбора. А вовсе не так, что column list — это проекция, а where — это выбор, как кажется на первый взгляд.
V>Дык, и в реальную модель не всегда вбивают. Понимаешь, не имеет значения, на каком уровне мы обеспечим соответствие данных требованиям реляционной модели. Частично это делается декларативными ср-вами СУБД, частично явно пользовательским кодом внутри триггеров, частично — клиентским приложением (неважно, трехзвенка там с еще одним промежуточным серваком или клиент-сервер).
Это всё очень хорошо, но для того, чтобы начать "обпеспечивать соответствие данных требованиям реляционной модели" на клиенте, нужно сначала умственным мозгом понять, что "декларативных средств СУБД" может не хватить. А для этого надо понимать, что модель, предлагаемая стандартом SQL, и, тем более, реализованная в реальной СУБД, не совпадают с РА. V>Я уже 10-й раз говорю, что коль такое соответствие получено, то аппарат становится доступен.
Оттого, что вы что-то повторяете, оно не становится полезнее. Отвлечёмся на минуту от сложной для вас темы РА, возьмём простую арифметику.
Пусть у нас от функции сравнения двух "чего-нибудь" требуется возвращать отрицательное целое число, если первый аргумент меньше второго, 0, если аргументы равны, и положительное целое число, если второй аргумент больше первого (Ничего, если я в С# синтаксисе буду писать?):
public delegate int Comparer<T>(T x, t y);
Такой компаратор можно использовать, например, в обобщённом коде сортировки коллекций.
Теперь поставим задачу так: мы хотим написать обёртку, которая умеет "инвертировать" произвольный компаратор — чтобы легко сортировать "в обратном" порядке:
public class ComparerInvertor<T>
{
private Comparer<T> _innerComparer;
public ComparerInvertor(Comparer<T> innerComparer)
{
_innerComparer = innerComparer;
}
public Compare(T x, T y)
{
return ??? // как будет выглядеть код здесь?
}
}
Вопрос приведён прямо в коде.
V>Это именно то, что происходит при составлении реального алгоритма исполнения запросов.
Не совсем. Поверьте мне на слово — при составлении "реального алгоритма исполнения запросов" всё гораздо сложнее. В частности, selection operators запросто могут продвигаться и в обратную сторону — от листьев к корню.
V>Твою задачу с where (id=1) ты решил неверно для случая РА.
Приведите правильное решение.
V>Затем, чтобы иметь возможность выходить за рамки реляционной модели, когда это действительно нужно.
И когда же это действительно нужно? Почему мы не видим ни одной промышленной СУБД, которая не даёт выходить за рамки реляционной модели, если такие потребности "почти никогда" не встречаются?
V>Для ответа на этот вопрос надо задавать именно такое отношение, которое хранит эти зависимости, и которое будет избыточным по отношению к наивной схеме, что не всегда удобно. ИМХО, идеальным решением было бы создание СУБД, которая поддерживает как реляционную модель, так и иерархическую, и работу этого хозяйства совместно, тогда вопрос не возникал бы.
Ну, вообще-то в рамках реальных СУБД решение уже давно есть. Как в диалектах (см. CONNECT BY), так и в стандарте (см. WITH). Но это ничего — это всего лишь небольшое расширение
V>О, так уже ты согласился с тем, что на этот счет вполне можно использовать теория реляционных БД? Без всей этой твоей "бездны"?
Те теории, которые я имею в виду, не совпадают с "реляционной моделью", описанной в классике. А какие теории вы имеете в виду — мне остаётся только гадать.
V>Теории. Просто раздел РА — это всего лишь раздел. А вся теория реляционных БД как раз и посвящена разработке эффективных и непротиворечивых решений.
А что такое "вся теория реляционных БД", стесняюсь спросить?
V>Я не увидел постановки задачи для этого решения. Пока нечего верифицировать.
V>А я пытаюсь объяснить, откуда взялась реляционная теория, и почему реальные сервера таки выгоднее таки делать как можно ближе к ней. Что ж они так далеко-то от неё делаются, если ближе якобы выгоднее?
V>Можно поинтересоваться, что это была за рефлексия и что она должна была доказать?
Она доказывает, что вопросы производительности не связаны напрямую с тем, каков объём возвращаемых данных. И что вопросы производительности получения промежуточных результатов очень даже важны.
S>>Всё зависит не от внешности ключа, а от паттернов доступа. Если я использую запросы типа where primary_key between @low and @high, то несмотря на его уникальность я получу range. Ситуация часто возникает при, скажем, постраничном доступе к данным.
V>OMG, постраничный доступ по первичному ключу?
А что вас беспокоит? Вы хотите ещё какую-то глупость сказать, как в случае с кластерными индексами? V>Нахрена вам вообще реляционная СУБД, не пояснишь?
Для хранения и обработки данных.
V>Это ты не разбрался как следует. Практически всегда неуникальный ключ можно обыграть дополнительным отношением, явно отражающим сценарии/потребности прикладной области, и получить больше прибавки к эффективности в итоге, ведь неуникальный индекс тоже сугубо для эффективности вводится.
Серъёзно что ли? Мне нравятся кванторы типа "практически всегда". Это вы себе лазейку оставляете для того, чтобы когда я вас носом ткну в реалистичный пример применения неуникального индекса, вы начали юлить типа "ой, ну это же так редко нужно"? Давайте вы вместо "практически всегда" напишете, когда именно "обыгрывание ключа дополнительным отношением" будет приводить к росту эффективности по сравнению с банальным create index. А когда, соответственно, наоборот.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>Эта рекомендация — полный бред. Размер данных таблицы не играет никакой роли.
DG>у вас не зафиксированы до конца термины, чтобы можно было делать такое сильное утверждение. DG>как минимум не зафиксировано: "о каких запросах вообще идет речь"?
В своих рекомендациях я указал, о каких запросах идёт речь.
Рекомендация vdimas-а бредовая, даже если попытаться её уточнить путём ограничения набора запросов, для которых она будто бы полезна.
DG>также не зафиксировано как определена операция сравнения для множеств через операцию сравнения для элементов.
Какие множества вы предлагаете сравнивать?
DG>зы DG>например, если запрос можно выполнить на основе лишь некластерного индекса(в частности, например, запрос существования записи) без последующего обращения к кластерному индексу, то поиск по некластерному индексу будет быстрее, и эффект будет тем сильнее проявляться, чем шире таблица.
О, ещё один великий практик SQL подтянулся. Давайте, глумитесь над бедным теоретиком.
И насколько конкретно поиск по некластерному индексу будет быстрее? Какова зависимость от ширины таблицы?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>ответ не конструктивный, и соответственно бесполезный — потому что не фиксирует, каких условий достаточно для входа, чтобы сделать определенный вывод про выход.
Какой вопрос, такой и ответ. Вы задаёте вопрос в стиле "почему бог создал адама из глины, а еву — из ребра". Что я могу вам ответить, кроме совета почитать что-нибудь о происхождении видов?
S>>Ну, если у вас есть готовый автоматический преобразователь, то напустите его на код, использующий "функцию проверки". Он вам и выдаст результат. DG>так вот этот преобразователь и выдает так, как я говорил выше...
Что? Ваш преобразователь как-то ухитряется вычислять невычислимую функцию "трассы"? Очень интересно. Вы мне исходничек преобразователя не скинете?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>данный mutable-код нарушает спецификацию, что должна вернутся одна из эталонных точек
Не вижу нарушения. Вы, наверное, хотели чтобы правильным ответом было
Здравствуйте, DarkGray, Вы писали:
S>>Во-первых — я считаю что Sinclair читал достаточно много, и по субъективным впечатлениям значительно больше меня, а главное, с большим толком. Во-вторых, я считаю что Sinclair достаточно глубоко понимает материал, раскладывает его по полочкам, очень четко выделяет абстракции и их уровни.
DG>для хорошего специалиста особенно при групповой деятельности (а форум — это, в первую очередь, групповая деятельность) этого мало. DG>хороший специалист еще должен осознавать, что он оперирует исходя из своей карты мира, и эта карта отдаленно совпадает с реальностью, и еще более отдаленно совпадает с картами мира, которые используют другие люди.
DG>и не ощущается, что Sinclair это осознает. у тебя оно менее выражено, но тоже достаточно заметно.
По-моему твоя реальность и карта мира намного дальше. И по твоему кунгфу ООП это заметно.
Здравствуйте, DarkGray, Вы писали:
S>>А для функции FindNearest ты результат не специфицировал.
DG>FindNearest возвращает одну из эталонных точек, и точку Zero, если эталонных точек нет.
Я о той, к которой якобы должен был стремиться суперкомпилятор, наваяв void FindNearest_Inplace(this Point[] points, IEnumerable<Point> etalonPoints).
Вот она совершенно не специфицирована.
>> Т.е. если даже points и etalonPoints содержат идентичные точки, то ничего дурного не случится
DG>данный mutable-код нарушает спецификацию, что должна вернутся одна из эталонных точек
Эту спецификацию я не видел и всерьез полагал что тебя устроит совпадение координат а не идентичность эталонной точки.
DG>>также не зафиксировано как определена операция сравнения для множеств через операцию сравнения для элементов. S>Какие множества вы предлагаете сравнивать?
множества времен выполнения запросов для кластерного и некластерного индекса.
или ты что-то другое имел ввиду когда заявлял "Размер данных таблицы не играет никакой роли"?
DG>>зы DG>>например, если запрос можно выполнить на основе лишь некластерного индекса(в частности, например, запрос существования записи) без последующего обращения к кластерному индексу, то поиск по некластерному индексу будет быстрее, и эффект будет тем сильнее проявляться, чем шире таблица. S>О, ещё один великий практик SQL подтянулся. Давайте, глумитесь над бедным теоретиком. S>И насколько конкретно поиск по некластерному индексу будет быстрее? Какова зависимость от ширины таблицы?
в первом приближении: пропорционально отношению размера записи некластерного индекса к размеру записи в кластерном индексе.
изменение скорости выполнения обусловлено тем, что при запросе одной записи за то же время читается сразу группа записей, при этом размер группы фиксирован в байтах, а не в кол-ве записей, соответственно, чем меньше размер записи, тем больше их читается за один запрос, и соответственно тем выше вероятность, что следующая проверяемая запись будет уже в кэше, и что не надо будет ждать пока головка винта доедет до нужного места.
S>Я о той, к которой якобы должен был стремиться суперкомпилятор, наваяв void FindNearest_Inplace(this Point[] points, IEnumerable<Point> etalonPoints). S>Вот она совершенно не специфицирована.
функция FindNearest сдвигает каждую точку к ближайшей эталонной
ps
в итоге есть два варианта:
1. функция Point FindNearest(Point p, IEnumerable<Point> etalonPoints) возвращает ближайшую эталонную точку
2. функция Point FindNearest(Point p, IEnumerable<Point> etalonPoints) сдвигает точку к ближайшей эталонной (тогда, конечно, лучше эту функцию по другому назвать)
первый вариант корректно преобразуется к Point Point.FindNearest(IEnumerable<Point> etalonPoints), а второй к void Point.FindNearest(IEnumerable<Point> etalonPoints) и изменению текущего экземпляра
и соответственно, вопрос — в каких терминах можно записать это отличие для функции Point FindNearest(Point p, IEnumerable<Point> etalonPoints), если утверждается, что понятие identity здесь не применимо?
DG>>и не ощущается, что Sinclair это осознает. у тебя оно менее выражено, но тоже достаточно заметно. S>По-моему твоя реальность и карта мира намного дальше. И по твоему кунгфу ООП это заметно.
вот только в этом треде:
в основном только я выдаю какие-то реальные рабочие куски кода,
и это я выдал без запуска профайлера достаточно подробный анализ примера Sinclair-а содранного у липпера,
и это мой алгоритм выдал вариант InversePoints более оптимизированный, чем твой,
это я тебе показал два способа получить бинарное представление value-типов в .net, когда ты не смог найти ни одного
и т.д.
а ты (а уж тем более Sinclair) максимум, что делаете — это говорите бла-бла-бла, что мое кунфу плохое, потому что что-то там не совпадает с определениями, которые никто из вас даже не то что сам сформулировать не смог, а даже не смог тупо содрать из нужного места в интернете.
а наши кунфу, вы говорите, самое убойное, мы его подсмотрели у крутых авторитетов, мы, конечно, в нем ничего не понимаем — что откуда следует, но оно реально крутое, чувак.
соответственно, у тебя какая-то очень странная линейка, который ты измеряешь насколько близки твоя и моя карта мира к реальности.
Здравствуйте, DarkGray, Вы писали:
S>>Я о той, к которой якобы должен был стремиться суперкомпилятор, наваяв void FindNearest_Inplace(this Point[] points, IEnumerable<Point> etalonPoints). S>>Вот она совершенно не специфицирована.
DG>функция FindNearest сдвигает каждую точку к ближайшей эталонной
DG>ps DG>в итоге есть два варианта: DG>1. функция Point FindNearest(Point p, IEnumerable<Point> etalonPoints) возвращает ближайшую эталонную точку DG>2. функция Point FindNearest(Point p, IEnumerable<Point> etalonPoints) сдвигает точку к ближайшей эталонной (тогда, конечно, лучше эту функцию по другому назвать)
DG>первый вариант корректно преобразуется к Point Point.FindNearest(IEnumerable<Point> etalonPoints), а второй к void Point.FindNearest(IEnumerable<Point> etalonPoints) и изменению текущего экземпляра
DG>и соответственно, вопрос — в каких терминах можно записать это отличие для функции Point FindNearest(Point p, IEnumerable<Point> etalonPoints), если утверждается, что понятие identity здесь не применимо?
Я тебя спрашивал о другой функции, ведь твой предыдущий вопрос был о ней.
Совершенно непонятно, почему утверждается что понятие identity не применимо?
Здравствуйте, DarkGray, Вы писали:
DG>множества времен выполнения запросов для кластерного и некластерного индекса. DG>или ты что-то другое имел ввиду когда заявлял "Размер данных таблицы не играет никакой роли"?
Время тут ни при чём. Время выполнения запроса предсказать очень тяжело, т.к. оно зависит от огромного количества посторонних факторов.
В СУБД обычно считают логические чтения — количество страниц, которые нужно прочесть в процессе выполнения запроса. Берутся они из кэша или диска — зависит много от чего.
Так вот, если мы зафиксируем те ограничения, которые предложил коллега vdimas — поиск одного значения по ключу — то стоимость запроса для конкретных фиксированных данных в таблице не будет зависеть от параметра. Поэтому для кластерного индекса будем иметь KI чтений, а для некластерного — NI чтений.
Так вот, истинность KI>NI не зависит от размера одной записи S. И от количества записей N она тоже не зависит.
Именно это я и имел в виду, когда говорил, что "размер данных таблицы не играет никакой роли".
Она зависит только от того, входит ли запрашиваемое поле F в состав ключа некластерного индекса, или нет.
DG>>>зы DG>в первом приближении: пропорционально отношению размера записи некластерного индекса к размеру записи в кластерном индексе.
Давайте уточним, что вы назыв DG>изменение скорости выполнения обусловлено тем, что при запросе одной записи за то же время читается сразу группа записей, при этом размер группы фиксирован в байтах, а не в кол-ве записей, соответственно, чем меньше размер записи, тем больше их читается за один запрос, и соответственно тем выше вероятность, что следующая проверяемая запись будет уже в кэше, и что не надо будет ждать пока головка винта доедет до нужного места.
Понятно. То есть вы тоже не знаете, как устроены индексы в реальных СУБД. Вам слово B-tree что-нибудь говорит?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>>>и не ощущается, что Sinclair это осознает. у тебя оно менее выражено, но тоже достаточно заметно. S>>По-моему твоя реальность и карта мира намного дальше. И по твоему кунгфу ООП это заметно.
DG>вот только в этом треде: DG>в основном только я выдаю какие-то реальные рабочие куски кода,
Как я понимаю, в основном ты пытаешься доказать что без твоих трасс жить нельзя, но ни один кусок кода не оказался убедительным. Реальными и рабочими я бы их тоже постеснялся назвать, т.к. там участвует некий суперкомпилятор, чье существование под большим сомнением.
DG>и это я выдал без запуска профайлера достаточно подробный анализ примера Sinclair-а содранного у липпера,
Я читал блог Липперта и ковыряться в том коде мне было совершенно не интересно. Извини. DG>и это мой алгоритм выдал вариант InversePoints более оптимизированный, чем твой,
Разве было какое-то соревнование в оптимизаторстве? Я не знал. Ты мне пытался доказать что-то по трассам, разве нет?
DG>это я тебе показал два способа получить бинарное представление value-типов в .net, когда ты не смог найти ни одного DG>и т.д.
Даже не понимаю, о чем ты говоришь.
DG>а ты (а уж тем более Sinclair) максимум, что делаете — это говорите бла-бла-бла, что мое кунфу плохое, потому что что-то там не совпадает с определениями, которые никто из вас даже не то что сам сформулировать не смог, а даже не смог тупо содрать из нужного места в интернете.
Так ведь не совпадает. Сдесь важно это, а не то, кто смог содрать. DG>а наши кунфу, вы говорите, самое убойное, мы его подсмотрели у крутых авторитетов, мы, конечно, в нем ничего не понимаем — что откуда следует, но оно реально крутое, чувак.
Мы тебе только показываем что твое кунгфу не имеет ничего общего с кунгфу авторитетов.
DG>соответственно, у тебя какая-то очень странная линейка, который ты измеряешь насколько близки твоя и моя карта мира к реальности.
Странность — это отклонение от нормы. А что говоря о норме — так это твои теории далеки от нормального понимания ООП. Найди как минимум 2 человека, которые бы поддерживали твои взгляды на ООП, тогда поговорим о странностях еще раз.
V>>Хе, в С++ тоже нет никакого вычислителя явно. S>1. В С++ есть изменяемые переменные. Ничего подобного в РА нет. S>2. В С++ есть чётко определённый порядок выполнения операций при вычислении аргументов бинарных операторов. Ничего подобного в РА нет. S>3. В С++ есть побочные эффекты от операций (проявляющиеся в изменении состояния "вычислителя", т.е. значений переменных), из-за которых нужен пункт 2. Ничего подобного в РА нет.
Гы, ты опять пытаешься спор со мной увести на спор с самим собой... Было возражение насчет императивности? Я согласился, что подразумевал лишь то, что порядок вычисления важен, но коль тебе этого было мало, то давай уж добъем тему. Был дан конкретный пример инициализации переменных в С++, который остается корректным даже если в объявлении переменных поставить const (специально не поставил, было интересно спровоцировать и порассуждать о принципах иммутабельности, декларатиивной и фактической, по сути алгоритма, например). И был поставлен вопрос — это какое программирование? Ты же придрался, что не императивное, вот и расскажи, какое. Я вижу, что не функциональное ни разу, т.к. не присутствуют ф-ии как первокласссные объекты или операции над ними. А потом вернемся к РА, попробуем определить, под какое программирование оно подходит.
V>>Речь шла об упорядоченности операций. Ты заявлял о том, что последовательность операций не принципиальна. S>Всё наоборот. Вы кричали, что я вообще никогда не могу менять порядок операций в заданной РА-формуле.
Брехня, утверждалось, что в общем случае это невозможно. Опять же, крайне сложно спорить с "общей эрудицией"... то, что должно идти как само собой разумеющееся (а) не понимается, (б) требует итераций чтобы осознать, что не поняли (с) требует пояснять в итоге всё до молекул. Например, вот это преобразование:
Заметь, в этой формуле показано, коль анлитически из A удалось выделить B, C и D, то B и C могли быть применены к каждому из отношений предварительно, а D — нет. В общем, случае B и C могут быть пусты, там об этом тоже сказано. Т.е. их невозможно быдет выделить аналитически из А, например при обычном join по внешнему ключу. Надо просто читать внимательней. И самое главное, повторюсь — это не есть изменения порядка операций, даже если было что выделять, это выполнение ДРУГИХ операций после преобразования.
S>Я вас тыкаю носом в раздел, где английским по белому написано, при каких условиях и какие операции можно местами менять.
Что совсем не соответствует твоему утверждению, что порядок вычислений не важен. В РА выражение f(g(x)) не эквивалентно в общем случае g(f(x)). Более того, когда такая эквивалентность наблюдается, то эту формулу сводят в одну h(x) = f(x) AND g(x) еще на этапе упрощения выражения. Дабы уменьшить общее кол-во операций, банально не сканировать одни и те же данные многократно. Кароч, много слов, достаточно было знать, что не все операции РА являются коммутативными. Поэтому, если некие действия менять местами, то будут получены разные промежуточные результаты, что может сделать формулу невалидной. Что значит невалидной? Например, у нас есть объединение двух мн-в, эта операция требует 2 или более операндов одного уровня, и эти операнды должны быть совместимыми отношениями. Легко сделать так, что "тупое" изменение порядка операций при вычислении одного из операндов рассматриваемой операции объединения породит несовместимое с другими операндами отношение. Например при простой перестановке операций переименования и проекций — мы получим не те проекции не из тех атрибутов (не из тех доменов т.е.).
Т.к. толстых намеков было недостаточно, вот пример на пальцах. (докатились)
Есть унарное отношение A{a}, хранящее целые числа, допустим от -100 до 100. Есть отношение A'{a1, a2}, которое хранит результат некоей формулы, напр. a2(a1) = (-a1). Есть следующая последовательность операций:
B = выборка из А с ограничением x>5
D = выборка из B с ограничением x<15
E = выборка A'.a2 из D x A' где D.a = A'.a1
Легко заметить, что из всех возможных перестановок правых частей допустима только перестановка первой и второй операции, т.е. одна из 5-ти возможных. И то, пример искусственный. Обычно ни одной нельзя произвести после упрощения исходных формул (здесь — объединение первой и второй операции в одну). Т.е. вот у нас в примере есть целые числа и мы даже знаем как правильно менять условия, чтобы сохранить семантику даже после изменения порядка. Но для случая РА предполагается, что мы не можем делать никаких предположений о св-вах операций внутри доменов, которыми оперируем.
Ты же сам дал ссылку, где приведены правила (довольно нетривиальные) преобразования формул РА, а так же даны условия допустимости таких преобразований. Преобразования порождают другую формулу, т.е. другой конечный алгоритм, т.е. будут другие действия при выполнении алгоритма запроса. Это же не есть твоё "порядок выполнения операций не важен". Он важен точно так же, так же как для классичесского функционального программирования, где вышестоящие ф-ии используют результаты нижестоящих. Порядок не важен только для вычисления независимых промежуточных переменных-аргументов одного уровня. Ну дык, слово "независимый" ключевое, т.е. тут и обсуждать нечего. По крайней мере везде, где я говорил, что будет получаться другой тип промежуточных отношений — явно не про этот случай. (это я заранее на предмет возможных твоих виляний в плане независимых частей формулы).
V>>Для конкретной выбранной формулы — навязывает еще как. Ты не обратил внимание на характер "раскрытия скобок" по ссылке? Зачастую никакие скобки раскрыть невозможно, S>"Зачастую" != "всегда". Учите формальную логику — в жизни пригодится.
Гы, это ты себя поправил? Утверждалось, что в общем случае изменять порядок операций невозможно. Еще это:
Важно только одно — аргументами последующих операций являются результаты предыдущих. Это позволяет утверждать, что порядок вычислений важен.
Более того, в РА формулах допустимо вводить переменные и описывать конечный реультат как последовательность вычисления этих переменных. Да, при переносе алгоритма с бумаги в программу, сии переменные будут иммутабельные, т.к. вычисляются лишь однажды. Ну или можно использовать одну мутабельную переменную-ячейку для всех совместимых отношений, куда по мере вычислений помещать результаты вычисления разных "бумажных" переменных.. Но это всё подробности реализации и прочей экономии памяти, т.е. да, вполне можно расписать на иммутабельных переменных, если захотеть. Так вот, если эти вычисления делать не на ООП- или ФП-итераторах, а в виде энергичных вычислений, так какое это будет программирование?
S>Нет проблем. Вот вам вариант с двумя таблицами — тут я вообще выкинул всё лишнее. Даже специально для вас заполнил padding данными, чтобы не было искушения сказать, что я смухлевал. Ну, и чтобы было понятно, что происходит, вывел статистику по allocation units.
Ок, на выходных проверю, бо тут надо на 3 порядка больше страниц для моей машины, чтобы делать выводы.
V>>Ага, таки неканонические данные не особо доступны извне (обычно это действительно так в нормальных приложениях). Дык, о чем речь тогда? О тонкостях реализации самого сервера? Смешно. S>Речь о тонкостях стандарта SQL, которые отличают его модель от реляционной модели.
Лихо ты скачешь. Если вернуться чуть вверх, то спор зашел изначально об индексах, bookmark lookup и прочих низкоуровневых операциях, для которых я утверждал, что аппарат РА к ним применим. И ты правильную ссылку дал, кстати, что этот аппарат таки применим аж бегом. прямо по ссылке и написано, что используется для оптимизации запросов. А я снабдил твою ссылку правильными комментариями относительно того, что если принять индексы за декомпозицию исходных данных (с избыточностью, разумеется), то формулы выборки по разным индексам будут неприводимы друг другу на уровне РА, хотя приводимы на уровне РИ.
V>>Ну, значит мало ты переносил SQL-кода м/у базами. Так и будешь теоретизировать. Более 90% SQL-кода приходится переписывать/исправлять, при переходе с одной СУБД на другую. S>Вот у вас столько апломба при суждениях о моём опыте. Вы облажаться с разбегу не боитесь?
Нет.
S>По делу: вот ну нас нынешний проект. Работает одновременно на двух СУБД. Довольно-таки разных. Как вы думаете, сколько процентов SQL-кода в нём являются СУБД-специфичными? S>Если ваше предположение выше верно, то должно быть 90%.
Это зависит от того, насколько вы решили себя ограничить в конструкциях языка. У нас были проекты одновременно под Oracle, MS SQL, Postgre, иногда MS Jet. Проблемы начинаются уже на банальных вложенных запросах с зависимостями м/у уровнями, с квотированием, с пребразованием типов, синтаксисом параметров, типов данных, доступа из триггеров к текущей строке и т.д. до бесконечности. А когда доходит до кода процедур на оракле в сравнении с TSQL, то там примерно 100% кода требуют хоть какой-то, но коррекции. В общем, если база используется как хранилище объектов, а не серверное приложение, то в том же BLT есть адаптеры под различные СУБД, обыгрывающие небольшие тонкости небольшого класса выражений. Тут разница невелика. Если же "интеллектуальная нагрузка" на СУБД высока, то оценка в ~90% кода, требующего хотя бы косметических коррекций — вполне.
V>>Oh my God V>>Можно я таки буду использовать то имя константы, которое использовано во всех виденных мною и тобою в реальной работе СУБД? S>Ну, если вы мне покажете, где именно "в реальной работе СУБД" логическое выражение возвращает NULL, то на здоровье — используйте его.
SELECT (TRUE AND (5 > NULL)) — покатит?
Только это это какой-то шаг в сторону непонятно для чего. Не к чему больше придраться что ле?
V>>Что нет никакого несоответствие с РА. Есть прописанное в стандарте правило, которое приводит результат выражения из домена { true, false, null} к домену { true, false }. Это преобразование в терминах РА обыгрывается вводом такого отношения и вперед! Твой пример становится очень даже решабельным в терминах РА, хотя ты трижды перед этим утверждал обратное. S>Речь не о "решабельности", а о соответствии модели. Теперь у вас уже выходит, что в каждом select у нас неявно выполняется оператор объединения со специальным отношением SQLLogicToBoolean и последующим оператором выбора. А вовсе не так, что column list — это проекция, а where — это выбор, как кажется на первый взгляд.
Тю, блин, какой конфуз. А как по-твоему выглядит в терминах РА вот это:
select * from X where X.x1 in (select y1 from Y)
?
Тоже самое замечание относительно ANY, EXISTS, IN, CASE и т.д.
Таков уж язык SQL — позволяет одно и то же сказать десятками способов. Прямо как человеческая речь... её и копировал, кстате.
S>Это всё очень хорошо, но для того, чтобы начать "обпеспечивать соответствие данных требованиям реляционной модели" на клиенте, нужно сначала умственным мозгом понять, что "декларативных средств СУБД" может не хватить. А для этого надо понимать, что модель, предлагаемая стандартом SQL, и, тем более, реализованная в реальной СУБД, не совпадают с РА.
Ну мне остается только повторяться... Ограничения РА — это есть реляционная модель. Реляционная модель накладывает ограничения на данные, а не на инструментарий. Ферштейн?
И у меня есть в СУБД всяческий инструментарий для обеспечения целостности данных. Даже если нехватает декларативных ср-в в условиях специально примененной избыточности декомпозиции — есть механизм триггеров и транзакций, т.е. целостность можно соблюдать как "изнутри" базы, так и "снаружи".
Да, ты можешь не поддерживать целостность твоих данных, и тогда данные не будут отвечать реляционной модели, и тогда формулы РА по разным отношениям в условиях избыточности в декомпозиции схемы не будут эквивалентны на уровне РИ. Вот с этим предложением я уже давно согласился и тут же отбросил этот сценарий, как неинтересный для обсуждения. Бо нафига тогда реляционная СУБД была взята для задачи?
V>>Я уже 10-й раз говорю, что коль такое соответствие получено, то аппарат становится доступен. S>Оттого, что вы что-то повторяете, оно не становится полезнее. Отвлечёмся на минуту от сложной для вас темы РА, возьмём простую арифметику.
С какой целью?
S>Пусть у нас от функции сравнения двух "чего-нибудь" требуется возвращать отрицательное целое число, если первый аргумент меньше второго, 0, если аргументы равны, и положительное целое число, если второй аргумент больше первого (Ничего, если я в С# синтаксисе буду писать?):
... S>Вопрос приведён прямо в коде.
Если речь о "простой арифметике", то бишь о числах, то можно два варианта: поменять местами x и y согласно условия задачи (сортировки в обратном порядке), либо воспользоваться св-вом коммутативности числовой алгебры и просто поменять знак результата исходного компаратора, коль будет известно, что результат сравнения чисел реализован через вычитание. Если характер сравниваемых величин неизвестен, то остается первый способ, согласно условию.
Опять же ХЗ зачем ты делаешь очередные ответвления от и так раздутых постов...
V>>Это именно то, что происходит при составлении реального алгоритма исполнения запросов. S>Не совсем. Поверьте мне на слово — при составлении "реального алгоритма исполнения запросов" всё гораздо сложнее. В частности, selection operators запросто могут продвигаться и в обратную сторону — от листьев к корню.
Обратная сторона — это от корня выражения к листьям, а от листьев к корню — это естественный порядок вычисления ф-ий при энергичных вычислениях. Но опять же, не зацикливайся на простом selection, у него самое простое правило и им пользуются для упрощения, дабы не ходить многократно по одним и тем же правилам. Интерес представляют преобразования формул при наличии соединений, проекции и переименования. Чаще всего передвигают ближе к листьям именно проекции (т.е. вносят в скобки, размножают операцию), дабы минимизировать промежуточные результаты, а все переименования обычно наоборот — выносят за скобки на самый верх, чтобы сделать лишь одно результирующее переименование. наибольшую пищу для ума представляют, конечно, различные виды соединений. Их действительно иногда меняют местами, но не "просто", а именно порождая другой алгоритм.
V>>Твою задачу с where (id=1) ты решил неверно для случая РА. S>Приведите правильное решение.
Вводится ф-ия сравнения f для домена ID {MIN_INT..MAX_INT, null} возвращающая результат в домене SQL_PREDICATE {true, false, null}. Дальше продолжать или уже понятно, с учетом сказанного в пред. посте?
V>>Затем, чтобы иметь возможность выходить за рамки реляционной модели, когда это действительно нужно. S>И когда же это действительно нужно? Почему мы не видим ни одной промышленной СУБД, которая не даёт выходить за рамки реляционной модели, если такие потребности "почти никогда" не встречаются?
Наверно потому, что современные СУБД — это "вещь в себе", с дорогостоящей связью с внешним миром, т.е. требуется предоставить максимум ср-в внутри СУБД, чтобы писать разносторонние приложения. Как мы еще не дошли до обсуждения временных таблиц и императивных алгоритмов на курсорах? Непорядок, непорядок...
В общем, для СУБД в виде библиотек, используемых прямо из процесса-приложения, такого требования нет, поэтому сии библиотеки давали/дают более-менее небольшой набор операций, в отличие от современных TSQL или PL/SQL, остальное делается на прикладном уровне, коль позволяется навигация по результату выборки.
V>>Для ответа на этот вопрос надо задавать именно такое отношение, которое хранит эти зависимости, и которое будет избыточным по отношению к наивной схеме, что не всегда удобно. ИМХО, идеальным решением было бы создание СУБД, которая поддерживает как реляционную модель, так и иерархическую, и работу этого хозяйства совместно, тогда вопрос не возникал бы. S>Ну, вообще-то в рамках реальных СУБД решение уже давно есть. Как в диалектах (см. CONNECT BY), так и в стандарте (см. WITH). Но это ничего — это всего лишь небольшое расширение
Далеко не всех, а лишь где задекларирована поддержка SQL-99. MySQL, MS Access, MS ESQL и т.д. не понимают. Да и не такое уж это и небольшое расширение. Стало возможным задавать запросы, непредставимые в терминах РИ.
V>>О, так уже ты согласился с тем, что на этот счет вполне можно использовать теория реляционных БД? Без всей этой твоей "бездны"? S>Те теории, которые я имею в виду, не совпадают с "реляционной моделью", описанной в классике. А какие теории вы имеете в виду — мне остаётся только гадать.
V>>Теории. Просто раздел РА — это всего лишь раздел. А вся теория реляционных БД как раз и посвящена разработке эффективных и непротиворечивых решений. S>А что такое "вся теория реляционных БД", стесняюсь спросить?
Ссылку на самый популярный учебник уже давал. Там собраны теоретические наработки по реляционным БД, ИМХО, этот учебник больше всех рахватан на цитаты, конспекты, методички и прочие учебные пособия ВУЗов. По крайней мере выдержки из него встречал крайне часто в перечисленном.
V>>Я не увидел постановки задачи для этого решения. Пока нечего верифицировать.
V>>А я пытаюсь объяснить, откуда взялась реляционная теория, и почему реальные сервера таки выгоднее таки делать как можно ближе к ней. S> Что ж они так далеко-то от неё делаются, если ближе якобы выгоднее?
Делаются конкретные приложения. Ты снова и снова путаешь св-ва инструментария и характера данных. Не нужна тебе целостность — да не поддерживай, какие проблемы?
Мне важно обратное, что СУБД предоставляет все ср-ва для построения реляционной модели данных.
V>>Можно поинтересоваться, что это была за рефлексия и что она должна была доказать? S>Она доказывает, что вопросы производительности не связаны напрямую с тем, каков объём возвращаемых данных. И что вопросы производительности получения промежуточных результатов очень даже важны.
Ну это да... чтобы производительность получения промежуточных результатов не волновала особо, для исторических есть отдельно стоящий OLAP, а оперативные не особо велики, по меркам современных машин. Даже в конце 90-х на тех смешных машинах работа СУБД банка после отделения оперативных от промежуточных не вызывала проблем, не то что, на современной технике. Сегодня, даже если брать торговый день крупнейших бирж (чем занимаемся), то это сущая фигня, бо независимые данные разносятся по независимым таблицам, базам, серверам, кластерам.
V>>Это ты не разбрался как следует. Практически всегда неуникальный ключ можно обыграть дополнительным отношением, явно отражающим сценарии/потребности прикладной области, и получить больше прибавки к эффективности в итоге, ведь неуникальный индекс тоже сугубо для эффективности вводится. S>Серъёзно что ли? Мне нравятся кванторы типа "практически всегда". Это вы себе лазейку оставляете для того, чтобы когда я вас носом ткну в реалистичный пример применения неуникального индекса, вы начали юлить типа "ой, ну это же так редко нужно"? Давайте вы вместо "практически всегда" напишете, когда именно "обыгрывание ключа дополнительным отношением" будет приводить к росту эффективности по сравнению с банальным create index. А когда, соответственно, наоборот.
Когда будет — уже привел, это для случая кластерного неуникального индекса. А когда не будет эффективно — это описано много где в и-нете, не будет тогда, когда в сценарии требуются другие поля записи, помимо входящих в ключ. Для неуникального ключа — это практически всегда, кроме сценариев типа EXISTS. Вот из-за редкости такого сценария я позволил себе некое усиление, никакой тебе лазейки. Если сценарий доступа по такому неуникальному ключу устоявшийся, требует еще полей основной записи, выгодней сделать отдельное отношение, избыточное, но хранящее необходимые поля исходного отношения (естественно, если требуется не вся запись исходной таблицы, бо нет смысла в дубликате). Насколько выгодней — уже второй вопрос. Речь шла о выборке, напомню, иначе бы об эффективности не было разговору, бо при обновлении любой лишний индекс только утяжеляет операцию. Для примера, сокращение физического размера строк таблиц движений примерно вдвое (из-за выбора более узких типов данных для внешних ключей) подняло производительность пересчета проводок примерно вчетверо. Это эффект от уменьшения физического размера обрабатываемых данных, об этом речь. Ну и твой псих относительно "лазеек" таки доставляет. В чем вообще цель нашего обсуждения тут?
Здравствуйте, vdimas, Вы писали:
V>Гы, это ты себя поправил? Утверждалось, что в общем случае изменять порядок операций невозможно. Еще это: V>
V>Важно только одно — аргументами последующих операций являются результаты предыдущих. Это позволяет утверждать, что порядок вычислений важен.
Порядок вычислений и порядок композиции не одно и то же. Композиция не коммутативна, но никто не говорит что функция справа должна быть вычислена раньше, чем функция слева оператора композиции.
Здравствуйте, vdimas, Вы писали:
V>Гы, ты опять пытаешься спор со мной увести на спор с самим собой... Было возражение насчет императивности? Я согласился, что подразумевал лишь то, что порядок вычисления важен, но коль тебе этого было мало, то давай уж добъем тему. Был дан конкретный пример инициализации переменных в С++, который остается корректным даже если в объявлении переменных поставить const (специально не поставил, было интересно спровоцировать и порассуждать о принципах иммутабельности, декларатиивной и фактической, по сути алгоритма, например). И был поставлен вопрос — это какое программирование? Ты же придрался, что не императивное, вот и расскажи, какое. Я вижу, что не функциональное ни разу, т.к. не присутствуют ф-ии как первокласссные объекты или операции над ними. А потом вернемся к РА, попробуем определить, под какое программирование оно подходит.
Оставьте функциональное программирование в покое. Речь идёт об императивном vs декларативном.
V>Брехня, утверждалось, что в общем случае это невозможно.
Цитирую:
S>Я имею право как угодно переупорядочивать операции, если семантика сохраняется.
Не можешь! Сколько еще об этом говорить?
Цитирую опять:
На уровне РА отношения эквивалентности есть только у тех операций, которые выразимы через другие...
Оба утверждения, мягко говоря, далеки от истины. Я ткнул носом в отношения эквивалентности, которые применимы к невыразимым через другие операциям (например, к операции выбора), и которые, собственно, и задают границы "сохранения семантики".
V>Заметь, в этой формуле показано, коль анлитически из A удалось выделить B, C и D, то B и C могли быть применены к каждому из отношений предварительно, а D — нет. В общем, случае B и C могут быть пусты, там об этом тоже сказано. Т.е. их невозможно быдет выделить аналитически из А, например при обычном join по внешнему ключу. Надо просто читать внимательней. И самое главное, повторюсь — это не есть изменения порядка операций, даже если было что выделять, это выполнение ДРУГИХ операций после преобразования.
Давайте начнём с простого. Вот, например, попробуйте доказать, что это — не изменение порядка операций:
V>Что совсем не соответствует твоему утверждению, что порядок вычислений не важен. В РА выражение f(g(x)) не эквивалентно в общем случае g(f(x)).
Вы, по-видимому, неправильно понимаете утверждение, которое пытаетесь оспорить. Вы утверждаете, что в РА "порядок операций" задан всегда.
А я утверждаю, что нет, не всегда. Есть масса ситуаций, когда порядок операций можно изменить. Именно потому, что нет понятия "состояние вычислителя", т.е. РА имеет декларативную природу.
V>Легко заметить, что из всех возможных перестановок правых частей допустима только перестановка первой и второй операции, т.е. одна из 5-ти возможных.
Ну вот видите — возможна же? Это ровно совпадает с моим утверждением "возможна перестановка там, где не меняется семантика".
V>Он важен точно так же, так же как для классичесского функционального программирования, где вышестоящие ф-ии используют результаты нижестоящих.
Совершенно верно. Но ведь это не делает "классическое функциональное программирование" императивным.
V>Ок, на выходных проверю, бо тут надо на 3 порядка больше страниц для моей машины, чтобы делать выводы. Ну давайте хотя бы порядок разницы предскажем, ок?
V>Лихо ты скачешь. Если вернуться чуть вверх, то спор зашел изначально об индексах, bookmark lookup и прочих низкоуровневых операциях, для которых я утверждал, что аппарат РА к ним применим. И ты правильную ссылку дал, кстати, что этот аппарат таки применим аж бегом. прямо по ссылке и написано, что используется для оптимизации запросов.
Да нет же, не используется.
V>Нет.
Ну, давайте подождём результатов запроса.
V>Если же "интеллектуальная нагрузка" на СУБД высока, то оценка в ~90% кода, требующего хотя бы косметических коррекций — вполне.
Ну вот видите, уже начинаются "если", "то", вводятся понятия "косметических коррекций"...
S>>Ну, если вы мне покажете, где именно "в реальной работе СУБД" логическое выражение возвращает NULL, то на здоровье — используйте его.
V>SELECT (TRUE AND (5 > NULL)) — покатит? Вот сразу и видно, у кого есть практика, а у кого её нету.
MS SQL: Incorrect syntax near the keyword 'AND'.
SQLite3: Error: no such column: TRUE
Так что нет, не покатит. Приходите в другой раз.
V>Тю, блин, какой конфуз. А как по-твоему выглядит в терминах РА вот это: V>select * from X where X.x1 in (select y1 from Y) V>?
А это зависит от того, как определена табличка X. А то может и вовсе никак не выглядеть.
V>>>Я уже 10-й раз говорю, что коль такое соответствие получено, то аппарат становится доступен. S>>Оттого, что вы что-то повторяете, оно не становится полезнее. Отвлечёмся на минуту от сложной для вас темы РА, возьмём простую арифметику.
V>С какой целью?
S>>Пусть у нас от функции сравнения двух "чего-нибудь" требуется возвращать отрицательное целое число, если первый аргумент меньше второго, 0, если аргументы равны, и положительное целое число, если второй аргумент больше первого (Ничего, если я в С# синтаксисе буду писать?): V>... S>>Вопрос приведён прямо в коде.
V>Если речь о "простой арифметике", то бишь о числах, то можно два варианта: поменять местами x и y согласно условия задачи (сортировки в обратном порядке), либо воспользоваться св-вом коммутативности числовой алгебры и просто поменять знак результата исходного компаратора, коль будет известно, что результат сравнения чисел реализован через вычитание. Если характер сравниваемых величин неизвестен, то остается первый способ, согласно условию.
Ок, пусть у нас результат сравнения чисел реализован через вычитание. Я правильно понял из выделенного, что вы считаете вот такую реализацию корректной для "обычных" int32?
public class ComparerInvertor<T>
{
private Comparer<T> _innerComparer;
public ComparerInvertor(Comparer<T> innerComparer)
{
_innerComparer = innerComparer;
}
public int Compare(T x, T y)
{
return -_innerComparer(x, y);
}
}
...
public int IntCompare(int x, int y)
{
return x-y;
}
V>Опять же ХЗ зачем ты делаешь очередные ответвления от и так раздутых постов...
Минуточку. Скоро всё станет ясно.
V>Обратная сторона — это от корня выражения к листьям, а от листьев к корню — это естественный порядок вычисления ф-ий при энергичных вычислениях.
Перечитайте текст, который вы мне процитировали. Речь не о порядке вычисления, а о перемещении операций по дереву запроса ещё до начала исполнения.
V>Вводится ф-ия сравнения f для домена ID {MIN_INT..MAX_INT, null} возвращающая результат в домене SQL_PREDICATE {true, false, null}. Дальше продолжать или уже понятно, с учетом сказанного в пред. посте?
Ок, я понял вашу идею. Она заслуживает рассмотрения, хотя, скажем, сам Кодд почему-то был другого мнения, и построил расширение своей РА вместо сведения к дополнительным Join+Selection.
V>Наверно потому, что современные СУБД — это "вещь в себе", с дорогостоящей связью с внешним миром, т.е. требуется предоставить максимум ср-в внутри СУБД, чтобы писать разносторонние приложения.
Удивительно, как это авторы SQL предусмотрели вот эту возможность писать "разносторонние приложения" сразу же из коробки — не дожидаясь, когда появятся разносторнние приложения и начнут требовать поддержки нереляционных данных. И всё ещё в 80х. Зато вот производительность серверов их никак не интересовала — во-времена то, когда 16 мегабайт памяти на машине были большой редкостью, а гигабайтные базы — нет. V>Как мы еще не дошли до обсуждения временных таблиц и императивных алгоритмов на курсорах? Непорядок, непорядок...
Вы не переживайте, если потребуется — дойдём. V>Далеко не всех, а лишь где задекларирована поддержка SQL-99. MySQL, MS Access, MS ESQL и т.д. не понимают. Да и не такое уж это и небольшое расширение. Стало возможным задавать запросы, непредставимые в терминах РИ.
MS Access, простите, это настольная СУБД. Для промышленного использования она никогда и не предназначалась. А в SQL Server (всех редакций, включая Express) — есть. В оракле — есть. DB2 — есть. PostgeSQL — есть. Чего ещё?
V>Ссылку на самый популярный учебник уже давал.
А, понятно. То есть для вас теория == "предмет". Я так и думал.
V>Делаются конкретные приложения. Ты снова и снова путаешь св-ва инструментария и характера данных. Не нужна тебе целостность — да не поддерживай, какие проблемы? V>Мне важно обратное, что СУБД предоставляет все ср-ва для построения реляционной модели данных.
Задам вам ваш любимый вопрос: что первично?
V>Ну это да... чтобы производительность получения промежуточных результатов не волновала особо, для исторических есть отдельно стоящий OLAP, а оперативные не особо велики, по меркам современных машин.
Ага. То есть в 1986 году авторы стандарта SQL заранее знали, что в 2011 будет отдельно стоящий OLAP, а оперативные данные будут не особо велики, по меркам современных машин. И с дьявольской предусмотрительностью сделали основой модели SQL мультимножества для того, чтобы сразу же колбасить на SQL-совместимых СУБД постреляционные приложения и дать в полный рост развернуться системам ORM. Моя гипотеза про соображения производительности просто смехотворна.
Потрясающий анализ причинно-следственных связей, коллега. Поздравляю. Я бы так не смог.
S>>Серъёзно что ли? Мне нравятся кванторы типа "практически всегда". Это вы себе лазейку оставляете для того, чтобы когда я вас носом ткну в реалистичный пример применения неуникального индекса, вы начали юлить типа "ой, ну это же так редко нужно"? Давайте вы вместо "практически всегда" напишете, когда именно "обыгрывание ключа дополнительным отношением" будет приводить к росту эффективности по сравнению с банальным create index. А когда, соответственно, наоборот.
V>Когда будет — уже привел, это для случая кластерного неуникального индекса.
То есть для "кластерного неуникального индекса" ваше "обыгрывание ключа дополнительным отношением" будет приводить к росту эффективности, я вас правильно понял?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>>это я тебе показал два способа получить бинарное представление value-типов в .net, когда ты не смог найти ни одного DG>>и т.д. S>Даже не понимаю, о чем ты говоришь.
S> Пардон, с наскоку не получилось сравнить структуры побитово.
DG>>а ты (а уж тем более Sinclair) максимум, что делаете — это говорите бла-бла-бла, что мое кунфу плохое, потому что что-то там не совпадает с определениями, которые никто из вас даже не то что сам сформулировать не смог, а даже не смог тупо содрать из нужного места в интернете. S>Так ведь не совпадает. Сдесь важно это, а не то, кто смог содрать.
как только ты говоришь про совпадение с реальностью, для начала необходимо показать (или хотя бы задуматься) какое определение одного и того же лучше совпадает с реальностью.
DG>>а наши кунфу, вы говорите, самое убойное, мы его подсмотрели у крутых авторитетов, мы, конечно, в нем ничего не понимаем — что откуда следует, но оно реально крутое, чувак. S>Мы тебе только показываем что твое кунгфу не имеет ничего общего с кунгфу авторитетов.
религия никакого отношения к реальности не имеет, а аппелирование к авторитету (а не к реальности) — это религия
DG>>соответственно, у тебя какая-то очень странная линейка, который ты измеряешь насколько близки твоя и моя карта мира к реальности. S>Странность — это отклонение от нормы. А что говоря о норме — так это твои теории далеки от нормального понимания ООП. Найди как минимум 2 человека, которые бы поддерживали твои взгляды на ООП, тогда поговорим о странностях еще раз.
тоже не понятно, какое это всё отношение имеет к совпадению с реальностью.
S> Странность — это отклонение от нормы.
и опять ты берешь слабое определение, сформулированное к тому же через понятие "норма" с очень высокой долей неопределенности
и приведенное тобой определение намного хуже совпадает с реальностью, чем определение "странный — не соответствующий ожиданиям".
S>Так вот, истинность KI>NI не зависит от размера одной записи S. И от количества записей N она тоже не зависит.
как только ты от словоблудия перейдешь к написанию формулы кол-ва логических чтений для B-tree для тех или иных запросов, то сразу увидешь, что зависит.
DG>>>это я тебе показал два способа получить бинарное представление value-типов в .net, когда ты не смог найти ни одного DG>>>и т.д. S>>Даже не понимаю, о чем ты говоришь.
DG>http://rsdn.ru/forum/philosophy/4535554.aspx?tree=tree
S>> Пардон, с наскоку не получилось сравнить структуры побитово.
Ты не въехал, что у меня не получилось. У меня не получилось сравнить побитово структуры в общем виде. Пример —
struct X { object v; }
А уж как сравнить побитово встроенные значимые типы я бы догадался без твоих подсказок.
DG>>>а ты (а уж тем более Sinclair) максимум, что делаете — это говорите бла-бла-бла, что мое кунфу плохое, потому что что-то там не совпадает с определениями, которые никто из вас даже не то что сам сформулировать не смог, а даже не смог тупо содрать из нужного места в интернете. S>>Так ведь не совпадает. Сдесь важно это, а не то, кто смог содрать.
DG>как только ты говоришь про совпадение с реальностью, для начала необходимо показать (или хотя бы задуматься) какое определение одного и того же лучше совпадает с реальностью.
Твои определения не работают в рамках определений ООП. Потому связи с реальностью нет как раз у них. Я тебе показывал это на примере идентичности различных строк.
DG>>>а наши кунфу, вы говорите, самое убойное, мы его подсмотрели у крутых авторитетов, мы, конечно, в нем ничего не понимаем — что откуда следует, но оно реально крутое, чувак. S>>Мы тебе только показываем что твое кунгфу не имеет ничего общего с кунгфу авторитетов.
DG>религия никакого отношения к реальности не имеет, а аппелирование к авторитету (а не к реальности) — это религия
Я аппелировал к определению идентичности.
DG>>>соответственно, у тебя какая-то очень странная линейка, который ты измеряешь насколько близки твоя и моя карта мира к реальности. S>>Странность — это отклонение от нормы. А что говоря о норме — так это твои теории далеки от нормального понимания ООП. Найди как минимум 2 человека, которые бы поддерживали твои взгляды на ООП, тогда поговорим о странностях еще раз.
DG>тоже не понятно, какое это всё отношение имеет к совпадению с реальностью.
Это имеет отношение к "странности" линейки.
S>> Странность — это отклонение от нормы.
DG>и опять ты берешь слабое определение, сформулированное к тому же через понятие "норма" с очень высокой долей неопределенности DG>и приведенное тобой определение намного хуже совпадает с реальностью, чем определение "странный — не соответствующий ожиданиям".
А ты формулируешь через понятие "ожидание", которое еще более неопределенно, чем "норма".
Что ж они так далеко-то от неё делаются, если ближе якобы выгоднее?
