Здравствуйте, vdimas, Вы писали:
V>Вообще, спор насчет порядка операций — это малость в бок. Это невладение проблематикой. Я так нутром чую, что ты имел нечто вроде примера Selection and cross product, где если рассматривать формулу слева направо, то вроде как какие-то оптимизации есть...
Я имел в виду то, что написал. И в жизни, и в теории реальный порядок вычисления промежуточных результатов весьма гибок.
V>Ноги нашего спора растут из-за различного понимания проблематики составления алгоритмов исполнения запросов.
Да.
V>
V>Выражения реляционной алгебры строятся на основе алгебраических операций (высокого уровня), и подобно тому, как интерпретируются арифметические и логические выражения, выражение реляционной алгебры также имеет процедурную интерпретацию. Другими словами, запрос, представленный на языке реляционной алгебры, может быть вычислен на основе вычисления элементарных алгебраических операций с учетом их старшинства и возможного наличия скобок. Для формулы реляционного исчисления однозначная интерпретация, вообще говоря, отсутствует. Формула только устанавливает условия, которым должны удовлетворять кортежи результирующего отношения. Поэтому языки реляционного исчисления являются более непроцедурными или декларативными.
Ну, это только одно из мнений. Я ссылку на другое приводил. Корни этого мнения понятны — выражение РА сразу подсказывает нам порядок вычисления "по умолчанию", из него легко построить императивный алгоритм. Это не означает, что этот императивный алгоритм — единственный.
V>И вообще, мне сложно вспомнить операцию, которая коммутативна и не ассоциативна при этом, всегда считал, что из одного следует другое. Обратное явно неверно.
Это да.
V>Я не ошибаюсь. В С/С++ компилятор имеет право сгенерить произвольный порядок вычисления твоей формулы, а за побочными эффектами пусть следит программист.
Ну и что? Это всего лишь означает, что С/С++ не следят за корректностью программы на таком уровне. А сама программа, очевидно, потеряет корректность при перестановке порядка вычислений только в случае наличия побочных эффектов. Коммутативность, ассоциативность, и приоритеты операций совершенно не важны.
Любопытно, C# гарантирует порядок вычисления аргументов операций и методов? Вроде тоже нет.
Вот как раз в C# всё хорошо: http://msdn.microsoft.com/en-us/library/Aa691322 http://msdn.microsoft.com/en-us/library/Aa691335
Но при этом у среды исполнения есть право переупорядочивания операций без побочных эффектов: http://msdn.microsoft.com/en-us/library/Aa691105
Обратите внимание, что само по себе это ничего не доказывает — есть разные языки. Алгоритмическая корректность никак не зависит от от того, что делается в реальном Паскале и разрешает ли С++ выстрелить себе в ногу.
V>Он верен из-за коммутативности операции AND: V>
А, ок.
V>>>Возможно, хотя может сделать его процедурным, если мы не используем первоклассные ф-ии, не? S>>Не, не может.
V>Т.е. в отсутствии первоклассных ф-ий всё равно функциональный подход? Хорошо себя чувствуешь?
V>>>А процедурный подход относится к императивному или нет? Мне таки интересно твое развернутое мнение. Таки машина Тьюринга описана как автомат с ленточной памятью. S>>А частично рекурсивные функции — нет. Дальше что?
V>А уже можно составить SQL-выражение, эквивалентное частично-рекурсивной ф-ии?
Всякое SQL-выражение эквивалентно некоторой частично-рекурсивной функции.
V>Давай определимся с твоим высказыванием сначала, что мой пример не делает функциональный подход императивным. Я предупреждал, что тема иммутабельности — скользкая. Мне любопытны аргументы.
Я потерял нить вашей мысли. Свою мысль я высказал — императивность начинается там, где есть состояние вычислителя, а с ним и возможность побочных эффектов. Декларативность начинается там, где кончаются побочные эффекты.
V>Когда на странице одна запись, то вроде не важно. Кластерный индекс всегда будет указывать не на диапазон, а на одну запись, как и некластерный.
Да.
V>>>Насчет порядка: если некая соединительная операция из 3-х (грубо) составляющий выполняется в 4 раза быстрее, что каждая в среднем стала выполняться быстрее в корень 3-й степени из 4. V>Ну это если одна таблица хранится сортированной под внешнему ключу, а другая по первичному.
Почему вы всё время скатываетесь на таблицы? Они участвуют только в примитивных запросах. В мало-мальски интересном случае аргументами операции являются не таблицы, а результаты других операций. V>А если это не так и обе сильно не влазят в память, то формула будет малость посложнее. А если происходит join по какой-либо формуле, которой нет в виде индекса, то ближе к O(N*M).
Это опять если они сильно не влазят в память. Это я к тому, что не стоит делать утверждения вроде выделенного — это так только в экстремальном частном случае.
(Интересно, умеет ли MS SQL решать уравнения, чтобы привести join по формуле к O(log(N) + log(M) + N + M)?)
Нет. Внутрь формул SQL не лезет (по крайней мере вплоть до 2005). Эффективность join можно убить насмерть написав on a.bID = b.id+0.
V>Ух, лихо. Т.е. движок базы данных и офисное приложение — это уже одно и то же?
Нет. Но аксессовый движок — для настольного применения.
V>Как ответный реверанс — я вижу ограниченность/замкнутость на MS SQL. А у себя не помню ни одного проекта, где бы делали только под MS SQL. Мимимум под 3 базы обычно, где MS SQL — одна из них. Наиболее весело, когда одновременно под MS SQL и под Oracle.
Большая тройка — это MS SQL, Oracle, DB2. Их легко найти в результатах TPC-C.
V>Дык, что разница есть — это говорилось. Так же как и то, что местами разницы нет. Например здесь: select * from X where X.x1 = 42. Для этого выражения есть только одно отображение в РА, поэтому и говорят, что в SQL присутствуют элементы РА, коль некоторые выражения будут взаимно-однозначны.
Ну так я о том, чтобы подчеркнуть — даже в этом случае выражение не сведётся к одной сигме в РА, хотя на первый взгляд это так.
V>Не меньшей! А тебя смущает, что SQL обладает бОльшей выразительностью. Дык, пусть себе...
Меня смущает только перспектива склеить РА, РИ, и SQL в голове программиста в одно понятие.
V>Я понял рассуждения, но это рассуждения по аналогии. Например std::set прекрасно может обслужить задачи алгебры множеств в кач-ве контейнера, коль мн-ва будут заведомо конечны и влезут в память (пусть виртуальную). Т.е. я бы хотел таки услышать аргумент конкретно по РА. Бо в реальности мы тоже работаем с конечными мн-вами, и обратное не предполагается даже теорией РА, поэтому аналогия с конечностью разрядов малость хромает.
Речь не о конечности чего-то, а о том, что математическая модель отличается от компьютерной.
V>Когда речь идет о сценариях фактически read-only (крайне редкое обновление), и сами данные вменяемых размеров, то встраиваемые движки идут для "промышленного применения" аж бегом. Бо они резвые и эффективные в плане ресурсов. Это примерно как с микропроцессорами: на каждый центральный процессор компьютера есть около десятка суммарно в системнике и всей периферии, и еще больше в окружающих гаджетах... Сама MS использует движок Jet в нескольких приложениях для хранения реляционных данных (хотя файлы зачастую имеют другое расширение, не MDB),
Это вы, наверное, про какой-то другой Jet. Вы же в курсе, что их два, да?
V>а в некоторых других использует MS SQL CE для тех же целей. Именно поэтому мы и делали задачи под разные СУБД, дабы давать возможность масштабирования. И плюс есть такая фишка — не все клиенты согласны на Windows + MS SQL, поэтому приходилось делать и под Oracle, и под остальное юниховое.
Ну вот наш продукт сейчас работает на MS SQL и PostreSQL
V>Если неуникальный индекс некластерный, то все-равно в общем случае каждая запись будет доставаться из разных страниц. Сценарий уже был дан: это потребность в полях, помимо входящих в индекс. Тут рассматривать нечего: если записей этого "искусственного" индекса будет больше на каждой странице, то уже выигрыш на чтении есть. Вопрос, конечно, в том, насколько именно, тут зависит от физического размера искуственного индекса по отношению к размеру строки исходной таблицы и от кол-ва самих данных. Тут правильно делали замечание, что кеширование страниц со счетов сбрасывать не стоит, оно влияет оч. сильно на конечный результат. Ну и относительная частота записи-чтения играет роль, т.к. любой лишний индекс, даже искусственный — это лишняя нагрузка при обновлении.
Ничего не понял. Где сравнение расходов на неуникальный некластерный индекс и расходов на внешнее отношение, играющее роль такого индекса?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>> Но я не делал сильных утверждений что только такой идентичностью можно достичь чего-то, что она имеет практический смысл.
DG>такая формулировка означает, что есть какое-то смутное доп. требование к функции идентичности, выполнение которого необходимо для того, что функция идентичности имела смысл.
DG>озвучь это требование
Единственное требование идентичности — различать объекты. Я утвеждал что ее можно немного ослабить в случаях когда объекты с различной идентичностью ECMA неотличимы по поведению.
Здравствуйте, DarkGray, Вы писали:
S>>> Но известно что ты пока не смог предоставить непротиворечивую идентичность для того что бы рассматривать строки "с версионной иммутабельностью" и переменные как объекты.
DG> для [строка, строка] = DG> программа разбивается на отдельные кодовые операции, из кодовых операции выделяются подмножество кодовых типизированные операции вида строка op(строка, ..), для которых специфицировано, что op не меняет identity. для данных случаев считается, что строка на входе и строка на выходе это один и тот же объект (true). последовательность таких операций назовем трассой. DG>если два объекта не входят в одну трассу, то они считаются разными(false).
А если входят, то ты должен уметь различать их по определению идентичности.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>Тем не менее, для коммутативных операций это так. G>>Тоже неверно. Представим коммутативную операцию a ~ b = b ~ a = 1. То есть всегда возвращающую одно значение. Для нее требуется вычислять аргументы? Вообще-то нет.
V>А как мы ее представим в SQL или РА?
Функция, которая всегда возвращает пустую реляцию.
G>>Представим другую, некоммутативную операцию, a | b = not a. Для вычисления требуется вычислять аргументы? Тоже нет.
V>Ну.. сочинять несуществующие алгебры можно хоть до посинения.
Тем не менее такое можно выразить в терминах РА.
V>В любом случае, коль семантика операции известна (ты же настаиваешь, что вычислять аргументы не надо, т.е. мы знаем об этом), кто мешает привести ее к правой (канонической) части, и затем отбросить все эти рассуждения за ненадобностью?
Так именно знание семантики позволяет проводить преобразования без вычисления. Ты же делаешь утверждения касающиеся всех коммутативных функций и говоришь что для них порядок вычислений связан с порядком композиции.
G>>Вообще если принять нормальный порядок вычислений, а не аппликативный, то порядок вычислений с порядком композиции почти никак не зависят друг от друга. V>Это для независимых аргументов так. Дык, случай независимых аргументов априори не может вызвать разногласий, тут спорить нечего.
Это для любых аргументов.
G>>Так как нормальный порядок вычислений всегда дает результат если это возможно, то его можно принять за умолчание в любой выичслительной теории если явно не указано обратное. G>>И в РА кажись не предполагается энергичный порядок.
V>Если у нас идут в выражении постоянные проекции и переименования, то даже для ленивого порядка вычислений необходимо будет сделать всю "линкову" всех проекций атрибутов и их переименований ДО начала вычислений, причем именно таким образом, как если бы эти значения распространялись в случае энергичного вычисления. Но и это не важно.
Именно это и важно, и в РА описано что и как можно переставлять и объединять. Ты же говоришь что это сделать нельзя для некоторого класса преобразований.
Здравствуйте, DarkGray, Вы писали:
S>>А если входят, то ты должен уметь различать их по определению идентичности.
DG>кому должен? DG>и как можно отличать строки внутри трассы по идентичности, если в данном случае утверждается что внутри одной трассы строки индентичны?
var empty = "";
var s1 = "1";
Это ведь разные объекты?
var emptyPlus1 = empty + s1;
А теперь empty и s1 разные? Или теперь они стали одним объектом? Если стали одним, куда делись empty и s1?
Я вижу, что ты трактуешь определение идентичности как "существуют как минимум два объекта и момент времени t, в который идентичность позволяет их отличить". Так это лично твои тараканы, которые не имеют отношения к ООП. Хочешь — назови это "конструктивным ООП".
Здравствуйте, gandjustas, Вы писали:
V>>>>Тем не менее, для коммутативных операций это так. G>>>Тоже неверно. Представим коммутативную операцию a ~ b = b ~ a = 1. То есть всегда возвращающую одно значение. Для нее требуется вычислять аргументы? Вообще-то нет.
V>>А как мы ее представим в SQL или РА? G>Функция, которая всегда возвращает пустую реляцию.
Я таки настаиваю ее изобразить. Потому что если это именно ф-ия как "черный ящик", то аргументы будут для такой ф-ии вычислены, хоть и не будут использованы внутри самой ф-ии, а если не черный ящик, то таки хотелось посмотреть на примере SQL (откуда она пойдет в РА).
G>>>Представим другую, некоммутативную операцию, a | b = not a. Для вычисления требуется вычислять аргументы? Тоже нет.
V>>Ну.. сочинять несуществующие алгебры можно хоть до посинения. G>Тем не менее такое можно выразить в терминах РА.
Нельзя.
V>>В любом случае, коль семантика операции известна (ты же настаиваешь, что вычислять аргументы не надо, т.е. мы знаем об этом), кто мешает привести ее к правой (канонической) части, и затем отбросить все эти рассуждения за ненадобностью? G>Так именно знание семантики позволяет проводить преобразования без вычисления. Ты же делаешь утверждения касающиеся всех коммутативных функций и говоришь что для них порядок вычислений связан с порядком композиции.
Речь о коммутативных операциях, а они даны были по ссылке. В остальном рассуждения такие же как для предыдущего примера, т.е. ты изобрел не операцию РА, а просто некую ф-ию и спекулируешь на порядке вычисления ее аргументов. Ты еще не забыл, ф-ии в РА применимы к каждому кортежу, а не ко всему отношению?
G>>>Вообще если принять нормальный порядок вычислений, а не аппликативный, то порядок вычислений с порядком композиции почти никак не зависят друг от друга. V>>Это для независимых аргументов так. Дык, случай независимых аргументов априори не может вызвать разногласий, тут спорить нечего. G>Это для любых аргументов.
G>>>Так как нормальный порядок вычислений всегда дает результат если это возможно, то его можно принять за умолчание в любой выичслительной теории если явно не указано обратное. G>>>И в РА кажись не предполагается энергичный порядок.
V>>Если у нас идут в выражении постоянные проекции и переименования, то даже для ленивого порядка вычислений необходимо будет сделать всю "линкову" всех проекций атрибутов и их переименований ДО начала вычислений, причем именно таким образом, как если бы эти значения распространялись в случае энергичного вычисления. Но и это не важно. G>Именно это и важно, и в РА описано что и как можно переставлять и объединять. Ты же говоришь что это сделать нельзя для некоторого класса преобразований.
Да, именно. Утверждал что перестановку в общем случае проводить нельзя. Можно только для случаев, являющихся заведомо коммутативными. Для всех остальных это будут преобразования, с получением совсем других выражений, что совсем не есть тоже самое, что перестановка. Это уже пошло жонглирование и уловки. К тому же, большинство преобразований имеют ограничения применимости, т.е. про общий случай говорить не приходится. Понятное дело, что коль с самого начала утверждалось о "вариантах" формул РА, то таки на каждый запрос РИ может быть несколько вариантов формул РА. Но вот получены ли они перестановкой порядка операций — это большой вопрос ни о чем.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
V>>>>>Тем не менее, для коммутативных операций это так. G>>>>Тоже неверно. Представим коммутативную операцию a ~ b = b ~ a = 1. То есть всегда возвращающую одно значение. Для нее требуется вычислять аргументы? Вообще-то нет.
V>>>А как мы ее представим в SQL или РА? G>>Функция, которая всегда возвращает пустую реляцию.
V>Я таки настаиваю ее изобразить. Потому что если это именно ф-ия как "черный ящик", то аргументы будут для такой ф-ии вычислены, хоть и не будут использованы внутри самой ф-ии, а если не черный ящик, то таки хотелось посмотреть на примере SQL (откуда она пойдет в РА).
SQL, в отличие от РА предполагает аппликативный порядок вычислений. Найдешь реализацию SQL где это не так — спокойно сделаю.
G>>>>Представим другую, некоммутативную операцию, a | b = not a. Для вычисления требуется вычислять аргументы? Тоже нет.
V>>>Ну.. сочинять несуществующие алгебры можно хоть до посинения. G>>Тем не менее такое можно выразить в терминах РА. V>Нельзя.
Значит можно аналогичное. Сути не меняет.
V>>>В любом случае, коль семантика операции известна (ты же настаиваешь, что вычислять аргументы не надо, т.е. мы знаем об этом), кто мешает привести ее к правой (канонической) части, и затем отбросить все эти рассуждения за ненадобностью? G>>Так именно знание семантики позволяет проводить преобразования без вычисления. Ты же делаешь утверждения касающиеся всех коммутативных функций и говоришь что для них порядок вычислений связан с порядком композиции.
V>Речь о коммутативных операциях, а они даны были по ссылке. В остальном рассуждения такие же как для предыдущего примера, т.е. ты изобрел не операцию РА, а просто некую ф-ию и спекулируешь на порядке вычисления ее аргументов. Ты еще не забыл, ф-ии в РА применимы к каждому кортежу, а не ко всему отношению?
А что мешает такую функцию представить как функцию отношения? Например t — отношение, s — органичение, f — функция. если рассмотреть композицию s(f(t)), то она не равна f(s(t)), но ведь никто не мешает построить ограничение s' такое что s(f(t)) = f(s'(t)), причем при некоторых условиях на для f получится s семантически эквивалентно s'. Причем эти условия элементарно можно проверить.
При этом f(s'(t)) может вычисляться быстрее, чем s(f(t)). И конечно любой движок субд пытается по-максимуму такие преобразования делать. Конечно движок субд опирается на семантику того что происходит и некоммутативность некоторых операций в общем случае ему не помеха.
V>Да, именно. Утверждал что перестановку в общем случае проводить нельзя. Можно только для случаев, являющихся заведомо коммутативными.
См выше. Некоммутативность не помеха перестановке вычислений. А если рассмотреть более общую картину, где могут быть сайд-эффекты, то и коммутативность не всегда дает возможность вычисления переставить.
V>Для всех остальных это будут преобразования, с получением совсем других выражений, что совсем не есть тоже самое, что перестановка.
Это будет перестановка вычислений. Просто у тебя в мозгу засело что "порядок вычислений" == "порядок аргументов", что как раз не верно в большинстве случаев.
V>Это уже пошло жонглирование и уловки.
Это правда жизни. Большинство оптимизации так выполняется.
Здравствуйте, Sinclair, Вы писали:
V>>А уже можно составить SQL-выражение, эквивалентное частично-рекурсивной ф-ии? S>Всякое SQL-выражение эквивалентно некоторой частично-рекурсивной функции.
Меня интересует та, которая имеет некий N, делающую ее невычислимой, простейший пример — бесконечная безусловная рекурсия (т.е. N=0). Как это выразить на SQL для любого удобного тебе N в рамках одного выражения?
V>>Давай определимся с твоим высказыванием сначала, что мой пример не делает функциональный подход императивным. Я предупреждал, что тема иммутабельности — скользкая. Мне любопытны аргументы. S>Я потерял нить вашей мысли. Свою мысль я высказал — императивность начинается там, где есть состояние вычислителя, а с ним и возможность побочных эффектов. Декларативность начинается там, где кончаются побочные эффекты.
Не так, ты упомянул функциональный. А инициализацию переменных я не могу считать за декларативность, сорри.
V>>>>Насчет порядка: если некая соединительная операция из 3-х (грубо) составляющий выполняется в 4 раза быстрее, что каждая в среднем стала выполняться быстрее в корень 3-й степени из 4. V>>Ну это если одна таблица хранится сортированной под внешнему ключу, а другая по первичному. S>Почему вы всё время скатываетесь на таблицы? Они участвуют только в примитивных запросах. В мало-мальски интересном случае аргументами операции являются не таблицы, а результаты других операций.
С результатами других операций все еще хуже, бо они получены в порядке индекса одного из исходных вариантов и могут не быть сортированы по отношению к требуемой следующей соединительной операции.
V>>А если это не так и обе сильно не влазят в память, то формула будет малость посложнее. А если происходит join по какой-либо формуле, которой нет в виде индекса, то ближе к O(N*M). S>Это опять если они сильно не влазят в память. Это я к тому, что не стоит делать утверждения вроде выделенного — это так только в экстремальном частном случае.
Это в случае для которого реляционная модель и разработана: для случая внешних хранилищ, на порядки больших размера ОП. Для данных, целиком помещающихся в ОП, реляционная модель не самый лучший вариант, гораздо эффективнее пространственные графы с непосредственными/физическими связями структур, а не ассоциативные связи реляционной модели.
S>(Интересно, умеет ли MS SQL решать уравнения, чтобы привести join по формуле к O(log(N) + log(M) + N + M)?) S>Нет. Внутрь формул SQL не лезет (по крайней мере вплоть до 2005). Эффективность join можно убить насмерть написав on a.bID = b.id+0.
V>>Ух, лихо. Т.е. движок базы данных и офисное приложение — это уже одно и то же? S>Нет. Но аксессовый движок — для настольного применения.
А десяток человек, работающих с неким сервером приложений, использующий in-proc движок — это настольное применение?
V>>Как ответный реверанс — я вижу ограниченность/замкнутость на MS SQL. А у себя не помню ни одного проекта, где бы делали только под MS SQL. Мимимум под 3 базы обычно, где MS SQL — одна из них. Наиболее весело, когда одновременно под MS SQL и под Oracle. S>Большая тройка — это MS SQL, Oracle, DB2. Их легко найти в результатах TPC-C.
Мы ищем у клиентов, а не у TPC.
V>>Дык, что разница есть — это говорилось. Так же как и то, что местами разницы нет. Например здесь: select * from X where X.x1 = 42. Для этого выражения есть только одно отображение в РА, поэтому и говорят, что в SQL присутствуют элементы РА, коль некоторые выражения будут взаимно-однозначны. S>Ну так я о том, чтобы подчеркнуть — даже в этом случае выражение не сведётся к одной сигме в РА, хотя на первый взгляд это так.
Если рассматривать X как неделимое целое — то сведется. Если же ты имел наличие индексов по X.x1, то можно начинать рассуждать о выборке над схемой (подсхемой?) X с учетом всей декомпозиции. Но только это уже не уровень SQL.
V>>Не меньшей! А тебя смущает, что SQL обладает бОльшей выразительностью. Дык, пусть себе... S>Меня смущает только перспектива склеить РА, РИ, и SQL в голове программиста в одно понятие.
Ах вон оно что... А чего же не боишься склеивания замыканий и циклов for в голове программиста в одно понятие (C)? Тоже ведь разные парадигмы внутри одного языка.
V>>Я понял рассуждения, но это рассуждения по аналогии. Например std::set прекрасно может обслужить задачи алгебры множеств в кач-ве контейнера, коль мн-ва будут заведомо конечны и влезут в память (пусть виртуальную). Т.е. я бы хотел таки услышать аргумент конкретно по РА. Бо в реальности мы тоже работаем с конечными мн-вами, и обратное не предполагается даже теорией РА, поэтому аналогия с конечностью разрядов малость хромает. S>Речь не о конечности чего-то, а о том, что математическая модель отличается от компьютерной.
Мм... но это хождение по кругу, делать утверждения, которые неспоримы т.е. банальны. Меня интересовали побочные эффекты конкретных перечисленных несоответствий. Вот я, как инженер, при решении использовать такую-то модель или нет ищу соответствия и несоответствия. Причем в виде конкретного списка и анализа каждого пункта этого списка, а не в виде абстрактного посыла, что "реализация может отличаться от модели". Конечно может... Что же теперь, изобретать велосипеды каждый раз?
V>>Когда речь идет о сценариях фактически read-only (крайне редкое обновление), и сами данные вменяемых размеров, то встраиваемые движки идут для "промышленного применения" аж бегом. Бо они резвые и эффективные в плане ресурсов. Это примерно как с микропроцессорами: на каждый центральный процессор компьютера есть около десятка суммарно в системнике и всей периферии, и еще больше в окружающих гаджетах... Сама MS использует движок Jet в нескольких приложениях для хранения реляционных данных (хотя файлы зачастую имеют другое расширение, не MDB), S>Это вы, наверное, про какой-то другой Jet. Вы же в курсе, что их два, да?
Я про тот, что используется для файлов формата MDB. Встречал иногда некие системные файлы в этом формате, которые прекрасно можно посмотреть после переименования. И где-то в офисных приложениях тоже натыкался на использование этого формата но под другим расширениемм файла.
Насчет 2 — не знаю... Я знаю 5 уровней драйверов: OLEDB, DAO, ADO, RDO, ODBC. Инсталляция MDAC ставила их все. Самые эффективные для Jet — это OLEDB и DAO. ADO — порой тормоз, но имеет кое-какие плюшки. RDO тоже имеет кое-какие уникальные операции, ради которых на однократных операциях юзают и его.
V>>а в некоторых других использует MS SQL CE для тех же целей. Именно поэтому мы и делали задачи под разные СУБД, дабы давать возможность масштабирования. И плюс есть такая фишка — не все клиенты согласны на Windows + MS SQL, поэтому приходилось делать и под Oracle, и под остальное юниховое. S>Ну вот наш продукт сейчас работает на MS SQL и PostreSQL
Отличный пример. Т.е. или таки у вас будет приличная разница в кодовой базе, или вы не особо сможете упражняться в TSQL и PL/PgSQL, выжимая всё из конкретной СУБД. Бо отрицать огромную разницу этих диалектов бессмысленно. Не говоря уже о разных типах поддерживаемых данных этими СУБД и самой философии этих СУБД относительно данных.
V>>Если неуникальный индекс некластерный, то все-равно в общем случае каждая запись будет доставаться из разных страниц. Сценарий уже был дан: это потребность в полях, помимо входящих в индекс. Тут рассматривать нечего: если записей этого "искусственного" индекса будет больше на каждой странице, то уже выигрыш на чтении есть. Вопрос, конечно, в том, насколько именно, тут зависит от физического размера искуственного индекса по отношению к размеру строки исходной таблицы и от кол-ва самих данных. Тут правильно делали замечание, что кеширование страниц со счетов сбрасывать не стоит, оно влияет оч. сильно на конечный результат. Ну и относительная частота записи-чтения играет роль, т.к. любой лишний индекс, даже искусственный — это лишняя нагрузка при обновлении. S>Ничего не понял. Где сравнение расходов на неуникальный некластерный индекс и расходов на внешнее отношение, играющее роль такого индекса?
Здравствуйте, vdimas, Вы писали:
V>Меня интересует та, которая имеет некий N, делающую ее невычислимой, простейший пример — бесконечная безусловная рекурсия (т.е. N=0). Как это выразить на SQL для любого удобного тебе N в рамках одного выражения?
Никак. Но ведь и не любую программу машины Тьюринга можно представить в виде SQL.
Декларативность начинается там, где кончаются побочные эффекты. V>Не так, ты упомянул функциональный. А инициализацию переменных я не могу считать за декларативность, сорри.
Я же вам дважды уже сказал отстать от функционального.
V>С результатами других операций все еще хуже, бо они получены в порядке индекса одного из исходных вариантов и могут не быть сортированы по отношению к требуемой следующей соединительной операции.
А могут и быть.
V>Это в случае для которого реляционная модель и разработана: для случая внешних хранилищ, на порядки больших размера ОП.
Нет. Реляционная модель была разработана не для джойнов по "произвольной формуле". А джойны по значению атрибута отлично работают и для больших внешних хранилищ.
V>А десяток человек, работающих с неким сервером приложений, использующий in-proc движок — это настольное применение?
В общем-то да. Вот когда ваш сервер приложений справится с нагрузкой хотя бы на уровне последних строчек TPC-C, можно будет говорить о промышленном применении.
V>Мы ищем у клиентов, а не у TPC.
Тогда всех порвёт мускул, широко распространённый по причине бесплатности.
V>>>Дык, что разница есть — это говорилось. Так же как и то, что местами разницы нет. Например здесь: select * from X where X.x1 = 42. Для этого выражения есть только одно отображение в РА, поэтому и говорят, что в SQL присутствуют элементы РА, коль некоторые выражения будут взаимно-однозначны. S>>Ну так я о том, чтобы подчеркнуть — даже в этом случае выражение не сведётся к одной сигме в РА, хотя на первый взгляд это так.
V>Если рассматривать X как неделимое целое — то сведется.
Не сведётся. Мы же это только что обсудили, зачем снова начинать?
V>Ах вон оно что... А чего же не боишься склеивания замыканий и циклов for в голове программиста в одно понятие (C)? Тоже ведь разные парадигмы внутри одного языка.
Я боюсь склеивания замыканий и их реализации в шарпе в одно понятие. Склеивания понятия цикла и оператора for в шарпе в одно понятие. А склеивания замыкания и циклов в одно понятие не боюсь, как и не боюсь склеивания понятий "таблица" и "хранимая процедура" в SQL в одно понятие.
V>Мм... но это хождение по кругу, делать утверждения, которые неспоримы т.е. банальны.
Но вы же постоянно пытаетесь с ними спорить V>Меня интересовали побочные эффекты конкретных перечисленных несоответствий. Вот я, как инженер, при решении использовать такую-то модель или нет ищу соответствия и несоответствия. Причем в виде конкретного списка и анализа каждого пункта этого списка, а не в виде абстрактного посыла, что "реализация может отличаться от модели". Конечно может... Что же теперь, изобретать велосипеды каждый раз?
При чём тут велосипеды? Вы опять спорите не со мной? А по поводу соответствия и несоответствия — хрен вы, а не ищете. Мне вас в несоответствия приходится носом тыкать, и вы даже после этого ухитряетесь их не видеть.
И это несмотря на то, что скажем, список несоответствий между SQL и реляционной моделью представлен в статье в википедии.
Да, для начала неплохо бы усвоить абстрактный посыл о том, что "реализация может отличаться от модели". Это чтобы в каждой новой области не приходилось вам мучительно доказывать, что эти различия существуют. После этого можно начинать тренироваться искать эти несоответствия самостоятельно, а не дожидаясь, пока вам Синклер на форуме не начнёт две недели подряд ежедневно про эти различия рассказывать.
Сначала будет тяжело. Зато потом будет масса позитивных результатов: например, можно будет не нести чушь про то, что ограничение длины записи продиктовано поддержкой кластерных индексов, или что требования порядка вычисления аргументов как-то связано с коммутативностью оператора.
V>Насчет 2 — не знаю... Я знаю 5 уровней драйверов: OLEDB, DAO, ADO, RDO, ODBC. Инсталляция MDAC ставила их все. Самые эффективные для Jet — это OLEDB и DAO. ADO — порой тормоз, но имеет кое-какие плюшки. RDO тоже имеет кое-какие уникальные операции, ради которых на однократных операциях юзают и его.
Понятно. Просто есть два движка с одинаковым названием: Jet Blue и Jet Red. Внутри они принципиально разные.
S>>Ничего не понял. Где сравнение расходов на неуникальный некластерный индекс и расходов на внешнее отношение, играющее роль такого индекса?
V>Тебе расходы по чтению нужны или по обновлению
Хоть какие. Лучше оба вида
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
V>>>>А как мы ее представим в SQL или РА? G>>>Функция, которая всегда возвращает пустую реляцию.
V>>Я таки настаиваю ее изобразить. Потому что если это именно ф-ия как "черный ящик", то аргументы будут для такой ф-ии вычислены, хоть и не будут использованы внутри самой ф-ии, а если не черный ящик, то таки хотелось посмотреть на примере SQL (откуда она пойдет в РА). G>SQL, в отличие от РА предполагает аппликативный порядок вычислений. Найдешь реализацию SQL где это не так — спокойно сделаю.
И где это ограничение явно указано?
Опять же, ты не забыл замечание про минимум 2 вида аналитических выражений в РА — это собственно выражения РА и выражения-ограничения в выборке или разновидностях соединений. Какой уровень ты имел ввиду?
G>Значит можно аналогичное. Сути не меняет.
Меняет. Ты же походя присвоил коммутативность некоей произвольной ф-ии, показав затем, что она нихрена не коммутативна из своего определения. Меня это улыбнуло, понятное дело, просто любопытно таки докопаться до всей цепочки рассуждений, которое могло ТАКОЕ породить.
V>>Речь о коммутативных операциях, а они даны были по ссылке. В остальном рассуждения такие же как для предыдущего примера, т.е. ты изобрел не операцию РА, а просто некую ф-ию и спекулируешь на порядке вычисления ее аргументов. Ты еще не забыл, ф-ии в РА применимы к каждому кортежу, а не ко всему отношению? G>А что мешает такую функцию представить как функцию отношения? Например t — отношение, s — органичение, f — функция. если рассмотреть композицию s(f(t)), то она не равна f(s(t)), но ведь никто не мешает построить ограничение s' такое что s(f(t)) = f(s'(t)), причем при некоторых условиях на для f получится s семантически эквивалентно s'. Причем эти условия элементарно можно проверить.
Мешает то, что ф-ии ограничения, где аргументами идут отношения — это уровень исчисления кортежей, но не уровень РА. Задача РА как раз преобразовать "структурные" формулы РИ в "плоские" операции РА, где ф-ии ограничения будут в терминах операций над атрибутами кортежей. Курить определение ограничения в РА.
Т.е. в терминах РА вот таких операций нет:
select * from X where X.x1 in (select y1 from Y)
Это будет эквивалент такой операции:
select X.* from X inner join Y on X.x1 = Y.y1
Что ближе к такой последовательности 3-х операций РА, являющихся решением обоих уравнений:
tmp1 = X x Y
tmp2 = ограничение(x1=y1) tmp1
result = проекция{x1, x2, .. xN} tmp2
Можно записать в виде одной формулы, не суть, все равно будет 3 примитивные операции РА в ней.
Попробуй кстате, "просто поменять вычисления местами" (С), мне любопытно. Замечания про ленивые vs энергичные я уже делал — ничего не меняется на уровне вычисления атрибутов кортежей.
G>При этом f(s'(t)) может вычисляться быстрее, чем s(f(t)). И конечно любой движок субд пытается по-максимуму такие преобразования делать.
Я это понимаю, и даже давал больше по этой теме, но ты невнимательно читал. Да, именно, уровень РА нужен для того, чтобы в его терминах породить ВСЕВОЗМОЖНЫЕ решения исходной формулы, потому что коль на уровне РА отсутствуют ф-ии над отношениями, т.е. отстуствует вложенность в ограничениях, т.е. отсутствует рекурсия формул, становится возможным произвести оценку сложности операций. Так вот, там, где некий автоматический движок, перечисляющий всевозможные решения в терминах РА знает об декомпозиции исходной схемы на отношения, он может не просто породить s'(t), он может породить s'(t'), где t' — другое отношение, но сохраняющее зависимости исходной схемы. Прочувствовал разницу?
G>Конечно движок субд опирается на семантику того что происходит и некоммутативность некоторых операций в общем случае ему не помеха.
Так вот, к большому пребольшому сожалению, движки СУБД не имеют понятия о семантике, т.к. обычно не реализовано одно из самых важных правил Кодда, позволяющее сохранять зависимости исходного прикладного отношения и проведенной конкретной декомпозиции. СУБД не делает никаких предположений относительно избыточности данных, принадлежащих одному домену и одному "логическому" атрибуту в рамках всей схемы.
V>>Да, именно. Утверждал что перестановку в общем случае проводить нельзя. Можно только для случаев, являющихся заведомо коммутативными. G>См выше. Некоммутативность не помеха перестановке вычислений. А если рассмотреть более общую картину, где могут быть сайд-эффекты, то и коммутативность не всегда дает возможность вычисления переставить.
Нету сайд-эффектов, а последовательность вычислений есть.
Понимаешь... злобные функциональщики малость лукавят. Ф-ий подход зиждется на процедурном, а тот не отрицает зависимость результата от порядка вычисления. Просто коль отсутствуют побочные эффекты, то аргументы ф-ий можно вычислять в произвольном порядке. Но это малость не то же самое, что зависимые вычисления делать в произвольном порядке. А я на этой зависимости настаивал изначально, мне случай независимых аргументов неинтересен, на то они и независимые.
V>>Для всех остальных это будут преобразования, с получением совсем других выражений, что совсем не есть тоже самое, что перестановка. G>Это будет перестановка вычислений. Просто у тебя в мозгу засело что "порядок вычислений" == "порядок аргументов", что как раз не верно в большинстве случаев.
Знаешь ли, если формулы ДРУГИЕ, то они просто ДРУГИЕ. Не надо ничего изобретать. А для ДУРГИХ формул может быть коль угодно другой порядок вычислений. Разумеется, что все варианты выражений РА, эквивалентных одному РИ, приводимы друг к другу. Но я утверждал, что это в общем случае не возможно на уровне РА, только через уровень РИ, т.е. через подстановку отношений, управляемую зависимостями конкретной схемы. Мы же, на самом деле, не рассмотрели целый большой класс преобразований, который делается НАД РА. А спор вообще возник вокруг случая применения РА уже на уровне выбора — какие индексы для сканирования таблицы использовать при составлении "физического плана запроса". Я наоборот вижу, что как раз здесь весь аппарат реляционной теории и может разгуляться, ведь у базы есть вся информация о декомпозиции таблицы и ее индексов.
V>>Это уже пошло жонглирование и уловки. G>Это правда жизни. Большинство оптимизации так выполняется.
Не совсем так. Я уже пояснял каждый пример, где речь действительно идет об оптимизации. Например, повторные ограничения никто не делает, они объдиняются по AND ф-ий ограничений. но это происходит еще до РА, еще во время автоматической генерации алгоритма запроса. По крайней мере в решениях задач мы всегда поступали так же. Это естественно как таблица умножения, как вывод аналитического вида результата перед вычислением ответа-числа в задачах по физике. Тоже самое относительно "оптимизации" продукций: сразу в РА получается правая часть. Поэтому основная нагрузка при оптимизации малость не на этом, а на том, чтобы породить всевозможные варианты (уже минимизированные, понятно) операций в примитивных терминах и оценить сложность каждой из них и затем всего алгоритма (коль он состоит из примитивных операций) из статистики, кол-ва данных, вида организации данных (упорядоченное или неупорядоченное размещение) и т.д.
S>А теперь empty и s1 разные? Или теперь они стали одним объектом? Если стали одним, куда делись empty и s1?
не определено.
у функции + есть два варианта: string = string + string-diff, и new-string = string1 + string2.
первый случай сохраняет идентити, второй — нет.
в .net оба типа string и string-diff выражаются одним типом System.String, поэтому выбор правильного варианта:
или выбирается автоматически на основе ряда соглашений (в частности на основе имен переменных),
или явно указывается при вызове.
S>Я вижу, что ты трактуешь определение идентичности как "существуют как минимум два объекта и момент времени t, в который идентичность позволяет их отличить". Так это лично твои тараканы, которые не имеют отношения к ООП. Хочешь — назови это "конструктивным ООП".
я предлагаю использовать понятие идентичности через способ конструирования, потому что это конструктивно
при таком подходе:
1. сначала всё что есть(весь мир) делится на элементы.
2. потом из элементов выделяются элементы, которые являются гранями одного и того же объекта, а остальные элементы считаются различными объектами
в ряде случаев, процесс 1 может быть итерационный
вместо пары терминов элементы/объекты также может использоваться пара терминов — объекты/идентичные объекты.
пример использования такого подхода:
сначала выделили ссылки (выделили элементы), потом ссылки через reference-equals проверили, что они являются одним и тем же объектом
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Меня интересует та, которая имеет некий N, делающую ее невычислимой, простейший пример — бесконечная безусловная рекурсия (т.е. N=0). Как это выразить на SQL для любого удобного тебе N в рамках одного выражения? S>Никак. Но ведь и не любую программу машины Тьюринга можно представить в виде SQL.
S>Декларативность начинается там, где кончаются побочные эффекты.
ЧТД. Наконец ты сознался. Не верно. Декларативность — это относительное понятие, ортогональное к побочным эффектам. Если есть неких два уровня абстракции, то один из них декларативен к другому, если примитивы более высокоуровневой абстракции выражаются в терминах операций над примитивами более низкоуровневой. Но! Эта более низкоуровневая абстракция, в свою очередь, может являться декларативной по отношению к следующей низлежащей абстракции (или некоего реального воплощения).
В рассматриваемом вопросе побочные эффекты отсутствуют потому что мы рассматривали выборку. А когда рассматривается обновление в реляционной теории, то считается, что мн-во кортежей для обновления и данные для обновления вычислены ДО операции обновления. Т.е. подразумевается некая точка в которой вычисления должны стать энергичными, предвычисленными. Т.е. даже если у нас ленивость внизу, она должна обеспечивать эту семантику. поэтому побочные эффекты есть, так как и правила их обслуживания.
V>>С результатами других операций все еще хуже, бо они получены в порядке индекса одного из исходных вариантов и могут не быть сортированы по отношению к требуемой следующей соединительной операции. S>А могут и быть.
Ну так вот тебе и умножение вместо сложения в том случае, где нет. Видел порой в плане запроса операцию сортировки промежуточных результатов перед join? А сложность алгоритмов внешней сортировки какова?
V>>Это в случае для которого реляционная модель и разработана: для случая внешних хранилищ, на порядки больших размера ОП. S>Нет. Реляционная модель была разработана не для джойнов по "произвольной формуле". А джойны по значению атрибута отлично работают и для больших внешних хранилищ.
Еще раз — только при упорядоченности внешнего ключа одной и основного ключа другой таблицы. Иначе как минимум по одной из этих таблиц будет произвольный доступ, т.е. количество чтений страниц будет стремиться к кол-ву записей, т.е. коэф К при формуле может случиться оч большой.
V>>А десяток человек, работающих с неким сервером приложений, использующий in-proc движок — это настольное применение? S>В общем-то да. Вот когда ваш сервер приложений справится с нагрузкой хотя бы на уровне последних строчек TPC-C, можно будет говорить о промышленном применении.
Ну речь-то шла о масштабировании. Это одна из первых причин делать кросс-СУБД проекты. Нафига десятку человек такое дорогостоящее решение? В тоже время, если надо — прыгайте на сервер без проблем. Ну и на самом деле, при размерах данных, подходящих под применение встроенных движков, эффективность получается порой выше твоих тестов TPC, именно поэтому in-proc базы так популярны. Особенно когда предварительную обработку осуществляет многопоточный сервер приложений на нейтивной платформе. Эта связка на своих задачах заруливает MySql, а тот на многих задачах легко заруливает MS SQL. Почитай полно обсуждений в вебе по эффективности. У меня тоже свой опыт... когда были пни-200, то нейтивный сервер, со складом-бухгалтерией, использующий DCOM для клиентов в одноранговой сети с низлежащей базой на JET просто летал как бабочка, а поставили выделенный MS SQL в кач-ве базы на втрое более мощный комп — и все стало гораздо печальнее минимум на год, пока еще вдвое характеристики компов не подросли. Это и спасло при росте базы, потому как пришлось уже делать меньше оперативный период, что не всегда удобно.
V>>Мы ищем у клиентов, а не у TPC. S>Тогда всех порвёт мускул, широко распространённый по причине бесплатности.
Вот именно! Но если использовать его как внешний процесс — порвет далеко не всех. Прямо на сегодня ОЧЕНЬ неплохо выглядит in-proc MS SQL Compact Edition. Просто бомба по эффективности с таким богатым SQL. Все-таки Jet имеет бедный диалект SQL, и эффективен далеко не во всех сценариях. Только нельзя этот MS SQL CE его юзать из дотнета — дотнетный парсер потока весь цимус убивает да еще содержит ошибки при парсинге стримов к блобам (я им рапортовал тот баг, вроде не исправили еще в 4-й версии).
V>>Если рассматривать X как неделимое целое — то сведется. S>Не сведётся. Мы же это только что обсудили, зачем снова начинать?
Затем, что ты лихо скачешь по уровням абстракций, думая, что эта скачка уже аргумент сам по себе. Дудки. На любом уровне есть свои задачи, доступные инструменту РА. Такова особенность понятия "абстракция".
V>>Ах вон оно что... А чего же не боишься склеивания замыканий и циклов for в голове программиста в одно понятие (C)? Тоже ведь разные парадигмы внутри одного языка. S>Я боюсь склеивания замыканий и их реализации в шарпе в одно понятие. Склеивания понятия цикла и оператора for в шарпе в одно понятие. А склеивания замыкания и циклов в одно понятие не боюсь, как и не боюсь склеивания понятий "таблица" и "хранимая процедура" в SQL в одно понятие.
Тогда твоя боязнь очень избирательна, на примере разницы логического и физического плана запроса. Ты взял, да и привязался к конкретной реализации конкретной СУБД.
Да и вообще, сия боязнь странная. Ведь о чем мы там изначально? Я считал, что надо знать хотя бы самые популярные техники исполнения абстракций, чтобы писать адекватные современной аппаратуре программы. Поэтому знания техник исполнения замыканий в используемом инструменте всяко на пользу. Особенно если это замыкания дотнета, приводимые тут же к делегатам. Ты же считаешь, что эти знания во вред по приписываемой оппонентам несуразной причине "монолитности в голове". Демагогия как она есть.
V>>Меня интересовали побочные эффекты конкретных перечисленных несоответствий. Вот я, как инженер, при решении использовать такую-то модель или нет ищу соответствия и несоответствия. Причем в виде конкретного списка и анализа каждого пункта этого списка, а не в виде абстрактного посыла, что "реализация может отличаться от модели". Конечно может... Что же теперь, изобретать велосипеды каждый раз? S>При чём тут велосипеды? Вы опять спорите не со мной? А по поводу соответствия и несоответствия — хрен вы, а не ищете. Мне вас в несоответствия приходится носом тыкать, и вы даже после этого ухитряетесь их не видеть.
Ты ткнул несоответствием в плане возможной неуникальности промежуточных и даже итоговых данных. Я попросил на уровне РА показать, что это приведет к невалидности формул и преобразований РА. Давай уж, назвался груздем — полезай в кузов.
S>И это несмотря на то, что скажем, список несоответствий между SQL и реляционной моделью представлен в статье в википедии.
Ооо, повтор старой шарманки. Мне ссылку на мой предыдущий пост давать или копипастой заниматься?
основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
Не меньшей! А тебя смущает, что SQL обладает бОльшей выразительностью. Дык, пусть себе...
Давай уже ближе к телу. Обоснуй, как более широкие возможности SQL мешают использовать наработки более узкой модели? Я бы еще понял когда наоборот, возможностей не хватает, тогда мы бы говорили лишь о части покрытия возможностей, но тут же ровно наоборот. В общем, за гранью здравого смысла уже.
S>Да, для начала неплохо бы усвоить абстрактный посыл о том, что "реализация может отличаться от модели". Это чтобы в каждой новой области не приходилось вам мучительно доказывать, что эти различия существуют. После этого можно начинать тренироваться искать эти несоответствия самостоятельно, а не дожидаясь, пока вам Синклер на форуме не начнёт две недели подряд ежедневно про эти различия рассказывать.
Таки придется, иначе просто заумная балаболка. Реализация всегда отличается от модели, на то она и модель, я не понимаю, почему у тебя проблема конкретно в СУБД. Ведь обыгрывают переполнения целых чисел в программах? И даже ограничения по точности чисел в плавающей. Однако же не мешает пользоваться всем аппаратом математики в вычислениях. Точно так же показал обыгрывание несчастного null. Неужели это и было предметом всего спора?
Понимаешь, твое отрицание применимости инструментов теории реляционных БД к реально существующим СУБД — это один из самых вредительских советов, который я тут видел за последнее время. Что-то вроде призывов к инженерному идиотизму. Поэтому таки я готов рассмотреть и показать обыгрывание отличий модели от реализации для всего твоего списка несоответствия. Попунктно.
S>Сначала будет тяжело. Зато потом будет масса позитивных результатов: например, можно будет не нести чушь про то, что ограничение длины записи продиктовано поддержкой кластерных индексов,
Улыбнуло, я думал ты уже понял, что тебе говорили.
Покажи-ка мне стоимость нахождения записи в случае кластерного индекса внутри страницы, если размер самой записи нефиксированный?
S>или что требования порядка вычисления аргументов как-то связано с коммутативностью оператора.
Э нет, аргументами для рассмотренного случая являются атрибуты и скалярные выражения, т.е. заведомо уже вычисленные вещи, а вот декомпозиция самих ограничений и возможность смены их порядка при повторных "накатываниях" ограничений действительно управляется коммутативностью операций составляющих аналитический вид ф-ии ограничения. Ты путаешь применение произвольной ф-ии к отношению (чего НЕТ в реляционной алгебре по определению, все операции над отношениями перечисленны), и собственно ф-ию ограничения, которая всегда над атрибутами.
V>>Насчет 2 — не знаю... Я знаю 5 уровней драйверов: OLEDB, DAO, ADO, RDO, ODBC. Инсталляция MDAC ставила их все. Самые эффективные для Jet — это OLEDB и DAO. ADO — порой тормоз, но имеет кое-какие плюшки. RDO тоже имеет кое-какие уникальные операции, ради которых на однократных операциях юзают и его. S>Понятно. Просто есть два движка с одинаковым названием: Jet Blue и Jet Red. Внутри они принципиально разные.
Ну, в VB тоже была своя встроенная ADO, так же была либа для С и ADO-обертка над ней в MFC.
То, что многие продукты MS используют формат MDB — это я за много лет видел невооруженным взглядом просто просматривая навскидку форматы их файлов. Но нам доступна только та, что устанавливалась раньше через MDAC, а сейчас через автообновления виндов, если создавать Engine через CreateObject. Хотя, надо ткнуть вот ту ESENT.DLL. Последние годы я за Jet не слежу, и ты дал интересную инфу, этот движок используется даже шире, чем я предполагал. А вот то, что забили на MS Access (это было понятно еще при переходе от 97-го офиса к 2000-му), — конечно жаль, похоже, это и породило новую ветку. Просто с офиса 2000 они стали продвигать MS Access больше как клиента к MS SQL, что сместило приоритеты. А зря. Нет ничего проще, чем породить в MS VC в визарде OLEDB интерфейс-провайдер к своему нейтивному серваку и прицепить MS Access как клиента — неимоверно эффективно и удобно, с учетом их потрясающего конструктора отчетов, в сравнении с полностью ручным GUI, каким-нить CORBA как протокол, и убогим Crystal Report. Я иногда использовал MS Access как внешнюю утилиту, вызываемую через автоматизацию, исключительно для формирования отчетов, бо оч удобно. (для не столь регуляных данных использовался MS Word точно так же): http://files.rsdn.ru/21096/ss1.PNG
S>>>Ничего не понял. Где сравнение расходов на неуникальный некластерный индекс и расходов на внешнее отношение, играющее роль такого индекса?
V>>Тебе расходы по чтению нужны или по обновлению S>Хоть какие. Лучше оба вида
Коль индекс неуникальный и мы договорились, что в отличие от основной таблицы этот индекс может быть кластерным, то по основной таблице для выборки M неуникальных записей по одному ключу из таблицы размером N понадобится O(log N)+O(M) чтений.
Для случая кластерного индекса по нашей искусственной избыточной таблицы порядок будет O(log N) — это время на поиск первого значения, остальные достаются за O(1) или даже за трудоемкость равную 0, т.к. преполагаются повторные чтения с той же страницы.
Для случая вставки в кластерный индекс всегда трудоемкость минимум O(n), помимо операции обновления дерева индекса, которая будет одинаковой стоимости что для исходной таблицы, что для избыточной. Но с этой сложностью борются, оставляя "зазоры" после удаления, чтобы свести ее ближе к логарифму.
S>>А теперь empty и s1 разные? Или теперь они стали одним объектом? Если стали одним, куда делись empty и s1?
DG>не определено.
Вот на этом и заканчивается разговор об ООП идентичности.
S>>Я вижу, что ты трактуешь определение идентичности как "существуют как минимум два объекта и момент времени t, в который идентичность позволяет их отличить". Так это лично твои тараканы, которые не имеют отношения к ООП. Хочешь — назови это "конструктивным ООП".
DG>я предлагаю использовать понятие идентичности через способ конструирования, потому что это конструктивно
Вот и предлагай, но это не ООП идентичность. DG>при таком подходе: DG>1. сначала всё что есть(весь мир) делится на элементы. DG>2. потом из элементов выделяются элементы, которые являются гранями одного и того же объекта, а остальные элементы считаются различными объектами DG>в ряде случаев, процесс 1 может быть итерационный DG>вместо пары терминов элементы/объекты также может использоваться пара терминов — объекты/идентичные объекты.
Я не вижу ничего конструктивного в этом подходе. Термин "идентичные объекты" уже использован в ООП. Выбери другой, что бы не вносить путаницу.
DG>пример использования такого подхода: DG>сначала выделили ссылки (выделили элементы), потом ссылки через reference-equals проверили, что они являются одним и тем же объектом
Если ссылка является объектом, то ты должен указать способ отличать ссылку-объект от объекта не ссылки.
DG>>не определено. S>Вот на этом и заканчивается разговор об ООП идентичности.
только для данного кода
DG>>я предлагаю использовать понятие идентичности через способ конструирования, потому что это конструктивно S>Вот и предлагай, но это не ООП идентичность.
определению удовлетворяет, а остальное это всё религия
DG>>вместо пары терминов элементы/объекты также может использоваться пара терминов — объекты/идентичные объекты. S>Я не вижу ничего конструктивного в этом подходе. Термин "идентичные объекты" уже использован в ООП. Выбери другой, что бы не вносить путаницу.
под определение "идентичные объекты" подходит, остальное — поиски еретиков.
DG>>пример использования такого подхода: DG>>сначала выделили ссылки (выделили элементы), потом ссылки через reference-equals проверили, что они являются одним и тем же объектом S>Если ссылка является объектом, то ты должен указать способ отличать ссылку-объект от объекта не ссылки.
нет, же конечно.
потому что с точки зрения данного построения, ни понятия ссылка-объект, ни понятия "объект не ссылка" — не существует.
DG>>пример использования такого подхода: DG>>сначала выделили ссылки (выделили элементы), потом ссылки через reference-equals проверили, что они являются одним и тем же объектом S>Если ссылка является объектом, то ты должен указать способ отличать ссылку-объект от объекта не ссылки.
вернемся к математике:
поверх булевой логике можно построить поле 1 со следующими правилами(допущениями):
операция + поля: xor
операция * поля: and
нулевой элемент поля: false
единичный элемент поля: true
поверх поля 1 можно построить поле 2 со следующими допущениями:
операция + поля: and
операция * поля: or
нулевой элемент поля: единичный элемент поля 1
единичный элемент поля: нулевой элемент поля 1
и в рамках таких построений бессмысленно требовать: чтобы операция * из поля 2 была согласована с нулем из поля 1.
при этом все выводы сделанные в рамках поля 2 справедливы для поля 1 и справедливы для самой булевой логике, пока эти выводы обратимы для использованных правил построения
соответственно:
если введено, что под объектом из построения 1 понимается ссылка из построения 0 на объект из построения 0, то бессмысленно требовать, чтобы был способ отличать "ссылку из построения 0 на объект из построения 1" от "объекта из построения 1 не ссылки из построения 0".
вообще, чтобы фраза "ты должен указать способ отличать ссылку-объект от объекта не ссылки" имела хоть какой-то смысл, для начала необходимо ввести, что такое ссылка в ООП вообще, и что такое ссылка в построении 1, при этом что такое ссылка в построении 0 было понятно, потому что использование понятие ссылка из .net-ных понятий, а не из понятий ООП.
DG>>>я предлагаю использовать понятие идентичности через способ конструирования, потому что это конструктивно S>>Вот и предлагай, но это не ООП идентичность.
DG>определению удовлетворяет, а остальное это всё религия
Не удовлетворяет.
S>>Я не вижу ничего конструктивного в этом подходе. Термин "идентичные объекты" уже использован в ООП. Выбери другой, что бы не вносить путаницу.
DG>под определение "идентичные объекты" подходит, остальное — поиски еретиков.
Не подходит.
DG>>>сначала выделили ссылки (выделили элементы), потом ссылки через reference-equals проверили, что они являются одним и тем же объектом S>>Если ссылка является объектом, то ты должен указать способ отличать ссылку-объект от объекта не ссылки.
DG>нет, же конечно. DG>потому что с точки зрения данного построения, ни понятия ссылка-объект, ни понятия "объект не ссылка" — не существует.
Ты что-то называешь ссылками, что-то называешь объектами, явно их различаешь, а потом утверждаешь косвенно что ссылки являются объектами. Ты уж определись, существуют ли они.
DG>>>пример использования такого подхода: DG>>>сначала выделили ссылки (выделили элементы), потом ссылки через reference-equals проверили, что они являются одним и тем же объектом S>>Если ссылка является объектом, то ты должен указать способ отличать ссылку-объект от объекта не ссылки.
DG>вернемся к математике: DG>поверх булевой логике можно построить поле 1 со следующими правилами(допущениями): DG>операция + поля: xor DG>операция * поля: and DG>нулевой элемент поля: false DG>единичный элемент поля: true DG>поверх поля 1 можно построить поле 2 со следующими допущениями: DG>операция + поля: and DG>операция * поля: or DG>нулевой элемент поля: единичный элемент поля 1 DG>единичный элемент поля: нулевой элемент поля 1
С математикой ты не дружишь. В "поле 2" нет нейтрального элемента для (+).
DG>и в рамках таких построений бессмысленно требовать: чтобы операция * из поля 2 была согласована с нулем из поля 1. DG>при этом все выводы сделанные в рамках поля 2 справедливы для поля 1 и справедливы для самой булевой логике, пока эти выводы обратимы для использованных правил построения
DG>соответственно: DG>если введено, что под объектом из построения 1 понимается ссылка из построения 0 на объект из построения 0, то бессмысленно требовать, чтобы был способ отличать "ссылку из построения 0 на объект из построения 1" от "объекта из построения 1 не ссылки из построения 0". DG>вообще, чтобы фраза "ты должен указать способ отличать ссылку-объект от объекта не ссылки" имела хоть какой-то смысл, для начала необходимо ввести, что такое ссылка в ООП вообще, и что такое ссылка в построении 1, при этом что такое ссылка в построении 0 было понятно, потому что использование понятие ссылка из .net-ных понятий, а не из понятий ООП.
А ты давал определение ссылки? Если нет, почему я не могу использовать понятие из .net? Ты ведь упоминаешь ссылки в своих тезисах...
DG>>вернемся к математике: DG>>поверх булевой логике можно построить поле 1 со следующими правилами(допущениями): DG>>операция + поля: xor DG>>операция * поля: and DG>>нулевой элемент поля: false DG>>единичный элемент поля: true DG>>поверх поля 1 можно построить поле 2 со следующими допущениями: DG>>операция + поля: and DG>>операция * поля: or DG>>нулевой элемент поля: единичный элемент поля 1 DG>>единичный элемент поля: нулевой элемент поля 1
S>С математикой ты не дружишь. В "поле 2" нет нейтрального элемента для (+).
не тормози.
true (он же единичный элемент поля 1) является нейтральным элементом для and с точки зрения операции +.
false(1) and(+) true(0) = false(1)
true(0) and(+) true(0) = true(0)
DG>>>вернемся к математике: DG>>>поверх булевой логике можно построить поле 1 со следующими правилами(допущениями): DG>>>операция + поля: xor DG>>>операция * поля: and DG>>>нулевой элемент поля: false DG>>>единичный элемент поля: true DG>>>поверх поля 1 можно построить поле 2 со следующими допущениями: DG>>>операция + поля: and DG>>>операция * поля: or DG>>>нулевой элемент поля: единичный элемент поля 1 DG>>>единичный элемент поля: нулевой элемент поля 1
S>>С математикой ты не дружишь. В "поле 2" нет нейтрального элемента для (+).
DG>не тормози.
Да, с этим я тормознул.
А покажи мне существование обратного элемента для false относительно сложения (and) для поля 2. Напомню, что сложение с обратным элементом должно дать ноль, т.е. true.
