Здравствуйте, DarkGray, Вы писали:
S>>И снова я против того что бы рассматривать переменную как объект.
DG>есть глубокое непонимание, что такое модель.
Есть
DG>модель — это подобие исходной системы, причем выводы сделанные для модели — справедливы и для исходной системы.
Идеальный газ — модель. Но выводы, сделанные для этой модели справедливы для исходной системы лишь в весьма ограниченных условиях, и с весьма невысокой точностью. Блюдце на черепахе с китами — тоже модель. Она немного подальше от реальной системы, но тем не менее.
DG>модель устроена как набор допущений, набор следствий из этих допущений и доказательства, что любая система, которая соответствует данным допущениям будет иметь и соответствующие следствия.
Палка-палка-огуречик — это модель человечка. Где доказательства? DG>при этом модель к исходной системе можно "приложить" в любой момент, проверив что допущения выполняются, сделать выводы о исходной система на основе модели, и также в любой момент модель можно отложить. DG>из этого в частности следует, что к одной и тоже системе модель может быть "приложена" по разному в один и тот же момент времени.
Какое-то сомнительное следствие на счет "приложена по разному".
DG>ни ты, ни sinclair, ни gandjustas так до сих пор и не описали, какие допущения для ООП делаются, какие из этого следствия вытекают, и как это всё доказывается. хотя я неоднократно это просил.
Проблема в том, что ООП это не модель чего либо. Это инструмент, с помощью которого выполняют модель. И выводы относительно модели не делаются по инструменту безотносительно самой модели.
DG>допустим, что для ООП достаточно следующих допущений: DG>1. можно выделить объекты DG>2. для объектов есть функция идентичности, определяющую что такое один и тот же объект DG>3. взаимодействие представлено в виде обмена сообщений DG>следствие: DG>если вышеуказанные допущения выполняются, то применим ООП-аппарат.
Вообще говоря, эти допущения излишни. Мы можем построить модель солнечной системы из объектов, притом что в рамках этой модели небесные тела не будут получать друг от друга сообщений, да и вообще взаимодействовать не будут.
DG>из всего это следует, что как только для переменной все эти допущения выполняются, то она автоматически становится объектом в терминах ООП DG>Опишем эти допущения для переменной: DG>1. каждую переменную будем рассматривать как отдельный объект DG>2. в качестве функции идентичности возьмем имя переменной DG>3. взаимодействие с переменной представимо в виде двух сообщений getvalue/setvalue DG>вывод: DG>при данных условиях, переменная есть объект в терминах ООП, и для нее применим весь аппарат ООП.
она становится объектом, но лишь в модели АСТ ЯВУ для нужд компилятора... К объектам модели солнечной системы объект переменная никакого отношения не имеет, если конечно модель солнечной системы не предусматривает взаимодействие переменных.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Не написано что должен, следовательно не должен. Элементарная логика.
V>Ну а я напишу что "должен" и хана твоей "элементарной логике"
А ты причем? Ты же не липперт и не дейкстра. Ты даже близко не нашел место в коде, которое больше всего ресурсов потребляет
G>>Счегобы? Многие умеют писать программы используя ленивость и асинхронность. Далеко не все могут предположить по внешнему виду время работы. V>Почему? Стоимость переключений потоков — штука известная, стоимость "холостого" и "нехолостого" вызова примитивов синхронизации ОС — тоже. Один раз измерь на своей машине и положи себе на видное место.
А это тут при чем? Ты же понимаешь что async в C# 5 может завершиться в том же потоке, а может не завершиться вообще. Причем заранее об этом сказать почти нереально.
G>>Пример на форуме показал это очень явно. Даже местные гуры перформанса не смогли сходу обнаружить проблему. Так в коде не было ни ленивости, ни асинхронности, ни десятка уровней косвенности.
V>Мноею пример еще не разбирался подробно, как это происходит в случае с кодом во время оптимизации. Но пару слабых мест указал при даже при чтении по диагонали. Но DarkGray разобрал подробно и все выкладки дал, ты невнимателен.
DG>>>и на всякий случай напишу очевидные вещи: DG>>>1. через профайлер можно прогнать лишь ограниченное кол-во сценариев, которое много меньше, чем поддерживаемое программой кол-во сценариев DG>>>2. bottleneck необходимо уметь обнаруживать до того, как на него наткнутся в реальном применении (особенно это актуально для защиты от DDOS) G>>Еще раз читай то что я процитировал. Первый пункт.
V>Да подтереться им можно в среде с повышенными требованиями к надежности и отзывчивости. Увы и ах. Даже в разобранном примере рассматривался один и тот же сценарий, хотя там нужно было рассмотреть область как минимум по двум координатам. В общем случае показанный подход — это профанация, хотя потянет как вводный урок для новичков.
Который ты не прошел А пост был написан человеком поумнее тебя если что.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Причем достижение первой цели не требует дополнительных знаний, а только последовательных замеров и устранения ботнеков.
V>А если они неустранимы? Т.е. если самая затратная операция неоптимизируема никак? То уже всё или как?
Ну так устраняй вторую самую затратную операцию, потом третью итд.
А если самая затратная не устраняется, то скрой её "затратность" от пользователя.
Здравствуйте, gandjustas, Вы писали:
G>>>Причем достижение первой цели не требует дополнительных знаний, а только последовательных замеров и устранения ботнеков.
V>>А если они неустранимы? Т.е. если самая затратная операция неоптимизируема никак? То уже всё или как? G>Ну так устраняй вторую самую затратную операцию, потом третью итд.
Ну так вопрос на миллион $$, если мне и так придется устранить обычно около сотни узких мест, нахрена мне по ним прыгать в произвольном порядке и рассеивать своё внимание? Внимательный скан кода дает действительно очень много и хорошо себя зарекомендовал. Не боись, работают одновременно все подходы, я лишь возражаю против того нигилизма, что вот надо только так-то и так-то... Чушь. По моему опыту, подготовка адекватных данных для любого эксперимента обходится несоизмеримо дороже программирования сценария этого эксперимента. О чем это говорит? Что надо очень хорошо понимать, какой характер данных интересует, т.е. надо оч глубоко вникать в код, прежде чем браться за всякие профайлеры и оптимизаторы, чтобы не тратить бесполезно рабочее время на подготовку данных, которые потом будут выкинуты. Я за ту же трудоемкость провожу code-review и исправляю десятки узких мест (которые и так буду исправлять), т.е. за тоже время, которое потрачу на игры с профайлером "вслепую". Еще кое-какой момент, немаловажный для самых первых итераций: зачем мне подготавливать адекватный эксперимент, сфокусированный для проверки некоторого кода, если я и так вижу, что этот код будет выкинут, как ни крути? Это же идет вразрез с основным требованием минимизации трудозатрат. Поэтому подготовка сценариев, запуск профайлеров (совсем от них отказываться никто не собирался, разумеется, просто акцент совсем не тот, что здесь толкают) и тестов на производительность подчиняется не совсем тому алгоритму, что здесь пишут "теоретики" от оптимизации. В реальности примерно так: идет обязательный code-review, отмечаются потенциально-узкие места (на все сразу на них никто не набрасывается, можно писать TODO с краткими комментариями), идет подготовка тестов самого-самого верхнего уровня. Одновременно идет зачистка самых очевидных затратных мест, но относительно дешевых в исправлении, всё это под контролем разницы показаний самых высокоуровневых тестов на производительность. По мере зачистки кода, с одновременным его более лучшим пониманием, идет подготовка все более специализированных синтетических тестов. Профайлер имеет смысл запускать, когда самые откровенные ляпы будут удалены, чтобы эти ляпы не портили нам картинку. Ни о каком "месяце вылизывания незначащего куска" не может быть и речи, это всё эротические фантазии теоретиков от оптимизаций. Основная работа при оптимизациях — это накопление тестовых сценариев, то бишь в основном данных (в плане трудоемкости) и самих синтетических и полусинтетических тестов по этим данным. А потом, когда постепенно подходим к уровню, где счет идет на микро и наносекунды (угу, у меня улучшение операции на сотню-другу наносекунд — уже нехилый профит), то какой там в опу уже профайлер! Тупо комментирую некоторые строки кода или подменяю пустышками-заглушками и смотрю на влияние на общее время низкоуровневого синтетического теста. Отдельно эти закомментированные куски тестировать на таком уровне уже не имеет смысла (заранее готовятся несколько вариантов для экспериментов), бо это уже уровень, когда стоимость вызова + конкретная проведенная оптимизация компилятором в этом месте + особенности кеширования — всё вместе создают уникальный контекст для конкретного участка кода, т.е. выдергивать код из контекста становится бессмысленным, наоборот, имеющиеся идеи в этот контекст надо подставлять. В день таких мест чистится от единиц до более десятка... Это я опять припоминаю нелепый аргумент врагов premature-optimization насчет "потратили месяц не туда". Просто, читая подобные "перлы" с трудом сдерживаюсь, чтобы не высказать, всё, что думаю о таких горе-теоретиках... Ну и, если вернуться к примеру Синклера. Ок, самое затратное место я не указал, зато указал следующие 2. Т.е. те, которые будут исправлены через пол-часа после самого затратного. Начни я работать над кодом, я бы их просто сделал в другом порядке, делов-то. Ведь никто не бросается на происзвольные куски кода (уже говорил), сначала оценивают, хотя бы устно, как часто этот код вызывается. Те, которые увидел, просматривая по диагонали, вызываются достаточно часто, т.е. должны были бы быть переделаны в любом случае, коль стояла бы задача улучшения производительности. По мере работы над примером Синклера дошел бы до оценки и того самого узкого места тоже, просто на след. итерации. Надо просто малость этим делом позаниматься, и тогда предрассудки исчезнут, в принципе ничего сложного. В рамках некоей известной платформы и известных библиотек самые узкие места известны заранее, т.е. ты их уже просто заранее знаешь, поэтому review кода нужно исключительно для того, чтобы предварительно отсеять места, где эффективность непринципиальна. Если даже где-то упустил, то профайлером потом всё-равно будет видно. Но по факту, после первых нескольких дней работы, когда накапливается достаточно тестовых сценариев и уже проведено несколько итераций оптимизации, зачищенные места почти всегда совпадают на 100% с тем, что показал бы профайлер. Вот об этом и шла речь. Над кодом Синклера никто не работал и получаса еще, чтобы делать такие далекоидущие выводы, которые ты пытаешься делать. Но если дело принципа, можно устроить "шустрик", кто выкатит более шуструю версию исходного примера. Могу пообещать не пользоваться профайлером вообще, для чистоты эксперимента.
G>А если самая затратная не устраняется, то скрой её "затратность" от пользователя.
Не скроешь, но и не надо, есть некий стандарт в отрасли. На сегодня он опустился с ~10us до ~5us на полный цикл, кроме этого надо уметь насыщать десятигигабитную сетку пакетами по 100-300 байт без всяких нагилей и уметь выгребать аналогичный поток данных на ответной стороне.
На самом деле, ты не понял цимуса. Бывает так, что профайлер покажет тебе самые затратные операции, но ты только даром потеряешь время, если не удасться их улучшить. А еще бывает часто так, что просто вызов самых затратных операций очень дорог, и стоит поменять способ вызова этих операций. В общем, "просто" показания профайлера — это слишком мало, чтобы делать хоть какие-то выводы о том, что же делать дальше. Таки разбор кода первичен, чтобы суметь соединить в голове в одно целое: характер подаваемых данных, результаты прогона профайлера и представления о том, как же работает код, т.е. почему именно так.
DG>>есть глубокое непонимание, что такое модель. S>Есть
из последующих примеров видно, что никак нет. Это видно, как минимум из того, что ты приводишь однобокие модели с сильным понижением точности описания, и не приводишь ни одной точной модели.
например, если тебе нужно получить площадь прямоугольной комнаты со стенами 5x4 — ты же не начинаешь считать кол-во квадратиков, которые можно уложить на пол, а просто умножаешь 5 * 4 и получаешь ответ 20, который ты даже считаешь правильным.
на основании чего ты всё делаешь?
на основании того, что математики и геометры доказали, что если в реальном мире есть прямоугольная фигура, то можно построить ее абстрактную мат. модель, и посчитать площадь через умножение сторон, и ответ полученный для модели будет справедливый и для реального объекта.
и этот переход (прямоугольная штука -> прямоугольник -> формула расчета площади прямоугольника -> площать исходной прямоугольной штуки) верен для любой ситуации, если там удается ввести евклидовое пространство и выделить прямоугольную фигуру.
Здравствуйте, gandjustas, Вы писали:
G>>>Не написано что должен, следовательно не должен. Элементарная логика.
V>>Ну а я напишу что "должен" и хана твоей "элементарной логике"
G>А ты причем? Ты же не липперт и не дейкстра. Ты даже близко не нашел место в коде, которое больше всего ресурсов потребляет
Неeжели? Ты точно читал мой ответ и разобрался в исходном примере, чтобы мой ответ понять?
Было написано так:
... ПЕРЕД началом оптимизаций, программу необходимо переписать. ...вместо генерации всех вариантов ReplaceQuestionMarks написать алгоритм непосредственного сравнения паттернов с "??". Т.е. для начала сделать преобразования алгоритмов в терминах O(n)
Тот код, который самый ресурсоемкий, выкидывается на первой же итерации, причем целиком, включая вызваемый ReplaceQuestionMarks, из-за своей линейной пробежки затем по данным. Там оптимизировать начинать еще нечего... Ну это в моей колокольни представлений о том, что же есть оптимизация, а что профанация.
G>>>Счегобы? Многие умеют писать программы используя ленивость и асинхронность. Далеко не все могут предположить по внешнему виду время работы. V>>Почему? Стоимость переключений потоков — штука известная, стоимость "холостого" и "нехолостого" вызова примитивов синхронизации ОС — тоже. Один раз измерь на своей машине и положи себе на видное место. G>А это тут при чем? Ты же понимаешь что async в C# 5 может завершиться в том же потоке, а может не завершиться вообще. Причем заранее об этом сказать почти нереально.
Это гадания на кофейной гуще. Ты должен понимать общий характер сценария и суметь подготовить адекватные данные для него. "Реально/нереально" — разговоры для бедных, асинхронное ожидание на сокете тоже может завершиться синхронно, а может нет, с этим уже черти сколько лет работают и никаких проблем. Повторю для особо понятливых, что стоимость каждого из вариантов надо знать.
V>>Да подтереться им можно в среде с повышенными требованиями к надежности и отзывчивости. Увы и ах. Даже в разобранном примере рассматривался один и тот же сценарий, хотя там нужно было рассмотреть область как минимум по двум координатам. В общем случае показанный подход — это профанация, хотя потянет как вводный урок для новичков. G>Который ты не прошел
G>А пост был написан человеком поумнее тебя если что.
Ох и аргументики у нынешних "спецов" пошли... Хочешь от меня такого же уровня?
A: "Для людей, не умнее тебя, если что."
Такой ответный выпад пойдет?
Продолжим нападки?
Любопытна сама ситуация. Разработчик основного продукта для хомячков этими же хомячками превозносится сегодня на пъедестал. И не смей трогать "авторитета". Прямо-таки обратная связь в действии.
==========
Правда, в отличие от тебя он парень вполне адекватный:
Я являюсь экспертом в семантическом анализе языка C#, но не в эффективной генерации кода для процессоров...
Так что нападок не будет, он не подставляется как ты. Я и охотно верю, что в своем деле он лучше, чем я в его деле.
никакого подробного разбора там нет, есть лишь общие слова — которые правильные с точки зрения бизнеса, но имеют отдаленное отношение к задаче оптимизации (когда необходимость в ней действительно возникает).
Здравствуйте, vdimas, Вы писали:
V>Опять продемагогил... спасибо... ФП не означает отсутствие императивности, оно означает наличие ф-ий как первоклассных объектов языка, только и всего. И с чего бы императивному алгоритму оперировать обязательно иммутабельным состоянием? Чай не ООП...
Вы, наверное, хотели сказать мутабельным состоянием? Ну, как бы по определению:
In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state
V>Ниже уровня РА ничего нет, кроме исходного кода, имплементирующего эти самые операции (как раз на лабораторках по реляционным БД дают задание реализовать набор операций РА по заданному виду контейнера).
ОМГ. Я же подробно объяснил, что операции, выполняемые SQL сервером — совсем не те операции, которые описаны в РА.
S>>Попробую объяснить на более простом примере: возьмем, скажем, комплексные числа. С точки зрения математики комплексных чисел, операция умножения a * b не имеет никакой "стоимости". V>Это с т.з. какой матемитики-то? S>>А вот если мы перейдём к некоторому представлению комплексных чисел в компьютере, то операция a * b будет иметь некоторую реализацию в этом представлении. S>>И вот уже у этой реализации будет некоторая стоимость, выраженная в терминах более низкоуровневых операций.
V>Да, именно, удивительное противоречие самому себе.
Никакого противоречия нет. Вы по-прежнему не можете отличить абстрактную математику от её реализации? Печально.
Ваши идеи про "скрытые атрибуты" я понял. К сожалению, они вам не помогут. Для начала, ничего подобного в реляционной модели нет, и с точки зрения алгебры вы вводите просто тавтологии, т.е. отношения, не содержащие новой информации.
Во-вторых, в реляционной модели нет понятия порядка, поэтому вам не удастся, оставаясь в рамках неё, рассчитать стоимость операций над отношениями.
V>Ну так что первично, а что вторично? Мне как разработчику видно ровно обратное, фиксированные размеры страниц нужны исключительно для нужд кластерных индексов, которые принципиально живут только в контексте детерминированных размеров.
Вы делаете сразу несколько неверных утверждений.
1. Кластерному индексу всё равно, ограничен размер записи или нет.
2. Фиксированные размеры страниц нужны для унификации алгоритмов доступа и распределения памяти.
V>И полно было БД без кластерных индексов с совсем другой организацией памяти.
Это вы dBase имеете в виду? У всех остальных известных мне СУБД организация памяти по-прежнему страничная.
V>Ну это залет, это даже полный ппц, я бы сказал. V>Кластерный индекс хорош лишь там, где seek по всем данным в процессе двоичного поиска относительно дешев. Т.е. когда размеры таблицы заведомо меньше размера ОП.
Вы бредите? Seek по ключу индекса дёшев всегда, и никак не требует ограничения размеров таблицы. Я вам привёл подробные условия превосходства кластерного индекса над некластерным. Что именно вам непонятно?
V>Ну оставайся при своем.
Почему "при своём"? Я же давал ссылку:
The current ISO SQL standard doesn't mention the relational model or use relational terms or concepts.
V>Дык, пора бы знать уже, что в IT есть "физический уровень". ИМХО, прямо сейчас стоит закруглить насчет БД и сделать gosub на "абстракции". Иначе разговор ни о чем. V>>>Index scan — это по прежнему операция ограничения из РА, а bookmark lookup — один из видов того самого соединения. S>>Нет.
V>Достойный аргумент. Ничего если я предположу отсутствие навыков по операциям РА, бо эти вещи как бы аксиоматичны?
Какие вещи? Где аксиоматичны? Ну, продемонстрируйте мне, что является аргументом операции bookmark lookup, а что — её выходом. И попробуйте найти аналог этой операции
S>>Индексы не являются "декомпозицией" исходного отношения. Чтобы начать разговаривать об индексах, нам придётся перейти от абстрактного термина "отношение" к конкретному термину "таблица", и начать учитывать подробности хранения данных. Вы почитайте учебник по устройству СУБД — того же Гарсиа-Молина. Оптимизатор "видит" совсем другую модель, чем вы в ваших задачках по РИ.
V>Ес-но, только что мне мешает видеть ту же самую модель, что и оптимизатор? Как я тогда буду писать эффективные приложения для СУБД, если я не понимаю показания плана оптимизатора? Или вот я разработчик СУБД, с какой радости я не могу прикладывать РА к индексам? Это откуда такие запреты-то? Я не только могу, но я обязан использовать весь этот аппарат, чтобы не породить УГ.
Оттуда, что операции РА имеют ограничения. Читайте учебник по РА. Если вы разработчик СУБД, то вам придётся пользоваться несколько более другой моделью. Она будет отличаться от РА примерно так же, как ТФКП от школьной арифметики.
V>Ну ты бы по классике прошелся. Нет никаких прыжков, есть постановка задачи, анализ, и предложенная модель для решения этого класса задач. И оставь в покое несчастный SQL, это уже какое свербение в одном месте. Во многих учебниках никакого SQL нет, поэтому заканчивай делать вид, что ты видел учебники в глаза кроме руководств к конкретным СУБД.
Ну давайте, приведите мне ссылку на этот учебник, в котором никакого SQL нет.
Вот, смотрим на http://www.mstu.edu.ru/study/materials/zelenkov/toc.html. Что мы тут видим? Ога, в разделе 4 мы видим:
4.4. Реляционная алгебра
4.5. Реляционное исчисление
4.6. Язык SQL
Никакого рассказа про то, каким образом СУБД собирается исполнять SQL, который весьма отдалённо связан с РА и РИ нету.
Это я молчу про килотонны пособий вроде http://progbook.net/bd/
V>Да правильно представляю. Исходники смотрел в свое время. Более одной БД. Представляю как есть, хоть и похоже, не так, как это представляешь себе ты. V>Угу, 2, только не таких как у тебя. Ты статическое и динамическое описание модели разнес по разным уровням абстракций, мои поздравления.
Не понял, это вы кого комментируете? В моём посте не было ничего про разделение статики и динамики на 2 уровня.
V>Меня аж плющит, когда ты снова и снова сравниваешь SQL с реляционной моделью. Сравнивать язык и модель — ну это просто за рамками здравого смысла.
Это ничего, пробелы в вашем образовании можно восполнить. Вот у нас язык SQL. Он задаёт некоторые операции. Вопрос: операции над чем?
Очевидно, что существуют некоторые объекты (в смысле математики, а не ООП), которыми манипулирует SQL. Почитайте раздел 4 стандарта — там вводится довольно подробное и точное описание того, что такое "таблица", что такое "представление", что такое "процедура". И вот эта модель, что характерно, отличается от Реляционной Модели.
V>И? Реляционная модель никак не ограничивает область значений доменов. Она ими даже не интересуется. Если некая область хочет включить NULL, Nil, папу_римского — да ради бога. Насчет трехзначной логики аналогично — бредятина. По предикатам в в SQL (например в операции JOIN) всегда только два ветвления, т.е. предикаты приводимы булевскому значению, хоть и неявно.
Нет. Если бы "ветвлений" было только 2, как вы говорите, то вот такой запрос возвращал бы все строки из таблицы:
select id from a where id = 1
union all
select id from a where NOT (id = 1)
В реляционной алгебре — именно так. В SQL — хрен, простите, на воротник.
Иначе они не могли бы исопльзоваться как предикаты. Или ты имел ввиду, что есть операции сравнения в домене значений {true, false, NULL}? Ну и какие проблемы? Определи этот домен и операции по нему для конкретной схемы реляционной модели и вперед — конкретно реляционной модели, повторюсь, это по барабану.
Проблемы очень простые. В реляционной модели все предикаты выполняются в булевой логике.
V>Угу, в таблицах с отсутствующим первичным ключом. Разумеется, такие таблицы не могут иметь аналогов из реляционной модели, даже если в таблице нет дубликатов. И единственный доступ к данным — это тупой перебор. А раз так, т.е. раз аппарат реляционного исчисления к ним не применим, я бы эти "фишки" вообще не обсуждал... Ведь для подобных таблиц не требуются никакие теории.
При чём тут таблицы? И почему вы думаете, что для них не нужны никакие теории?
Поясняю на пальцах: Реляционная Модель замкнута относительно операций РА.
Это означает, что, скажем, оператор проекции всегда возвращает отношение.
Давайте возьмём примитивную таблицу — с первичным ключом, наличие которого вам кажется столь важным. В ней будут некоторые неключевые атрибуты (здесь и далее я пишу в терминах SQL):
create table Person(id int primary key, name varchar(max), cityId int foreign key references city(id))
Очевидно, эта таблица вполне себе укладывается в реляционную модель.
Возьмём от неё проекцию:
select cityId from Person
Чтобы эта проекция удовлетворяла требованиям реляционной модели, мы обязаны избавиться от дубликатов:
select distinct cityId from Person
Если бы SQL соответствовал РА и РМ, то distinct был бы принудительно приделан к каждому стейтменту.
А не сделано это оттого, что сие может оказаться крайне дорогостоящим удовольствием. Рассмотрим, скажем, вот такой запрос:
select cityName from city where cityId in (select cityId from Person where name like '%vdi%')
Здесь семантика запроса не зависит от того, возвращает ли вложенный запрос set или multiset. И в очень многих практических случаях — именно так. Если ограничиться проекциями, ограничениями, и соединениями, то появление дубликатов на промежуточных этапах несущественно, т.к. мы можем привести muliset к set на окончательном этапе. Форсирование ограничений на дубликаты на всех промежуточных этапах приведёт к падению производительности.
V>Тогда не существовало бы теории реляционных БД, коль она не нужна?
Я не говорю, что она не нужна. Существует же арифметика натуральных чисел, хотя реальные уравнения удобнее решать в комплексных числах. Нужно просто понимать, что чистая РА — это сознательное упрощение моделей, применяемых в реальных СУБД.
V>Я бы скорее сравнил Фурье и корреляцию по сетке частот.
А я бы не стал.
V>Для реляционной модели это неважно. Повторюсь, в РА важна последовательность операций, никакая конкуренция не рассматривается.
Поскольку в РА нет изменяемого состояния, конкуренция в ней вообще не интересна.
V>Я пока еще не вижу противоречий с примитивами РА.
А зачем вам противоречие? Мы же не опровергаем РА как таковую. Мы говорим о том, что РА недостаточно для описания реальных промышленных СУБД. Ситуация опять такая же, как в арифметике vs ТФКП. Я вам толкую о том, что уравнений типа f(x) = g^2(x) нужны комплексные числа, а вы мне "я не вижу противоречий c примитивами арифметики".
V>Да нету никаких индексов на физическом уровне просто. Индексы — это тоже логическая единица модели конкретной СУБД.
Вы просто не понимаете общепринятой терминологии. Есть устоявшееся сочетание "физический план выполнения запроса".
V>Ничего личного, но споры относительно РА я бы предпочел вести в терминах самой РА, взаимоотношения операций, разбора конкретных типовых задач из области РА и т.д., а не путем перестрелки с помощью выхваченных из контекста фраз "из интернета".
Непонятно, о чём именно вы хотите спорить. У нас относительно РА никакого спора нет. Весь спор — о том, что в реальных СУБД работает не РА, и что SQL — это не РА, и не РИ.
V>Я могу еще повторить больими буквами, если не понял — РА всегда оперирует неким последовательным алгоритмом.
Вы определение "императивного программирования" уже прочитали? Тогда осталось его понять. V>В общем, опять и снова могу лишь рекомендовать прорешать задачи по РА, с целью проникнуться проблематикой, и чтобы составить затем свое мнение не на вырезанных из контекста фразах, а на личном опыте.
Какие, например, задачи?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: V>Таки не надо смещать акценты, речь шла конкретно про профайлер. Даже если мы "тупо" замеряем "самый верхний цикл" и видим, что оптимизация некоего куска не приносит бенефитов, с чего бы тратить на него месяц?
Речь шла о том, что кое-кто тут считает, что без полного понимания внутреннего устройства потрошков машины, разработчик якобы обречён запускать профайлер каждые 10 строк.
Из этого подразумевается что
а) профайлер — это очень плохо
б) программист зачем-то заморочен задачами перформанса постоянно (а не в тот момент, когда есть что померить)
в) что программист должен быть способен решать проблемы производительности в уме
г) и вот что для этого необходимо знать матчасть назубок.
Самое смешное, что даже если удастся доказать универсальную истину пунктов а, б, и в (что, очевидно, бесперспективное занятие), и аргументировать таким образом г), ни к чему интересному мы не придём.
В том смысле, что я не делал утверждения, которое вы пытаетесь опровергнуть. Я совершенно не против знания программистом матчасти.
Я против того, чтобы программист слеплял в голове всё в сплошной монолит. Примеры приводить не буду, чтобы не спровоцировать ещё один поток "откровений" на общеизвестные темы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
V>>>>Это верно в той области ПО, для которой эффективность не является конкурентным преимуществом. Например, для заказного ПО, там же никакой конкуренции... Нужна лишь некая "достаточная" производительность. G>>>Да-да-да. Забавная байка. У тебя есть сведения о корреляции производительности и продаж для определенного класса программ? V>>Есть. G>Показывай.
А тебе ключи от сейфа не надо? Упрись, там и разберёшься, что на что влияет. Просто прими как факт, что есть такие предметные области, где 30 микросекунд latency — "слив зощитан", а 1,5 микросекунды — топ продаж. Но вообще, тебе о том знать не надобно, так оно проще: я ничего не имею против того, чтобы абсолютное большинство озабочивалось latency, когда оно превысит сотни миллисекунд.
V>>>>А в коробочном ПО в реальности бывает так, что профайлер показывает до 30% затрат на всего одну из самых затратных операций, но она никак не оптимизируема, всё, упёрлись в предел. Зато остальное можно подтянуть, то самое, которое 1-2% каждое в среднем, но примерно вдвое общую эффективность поднять, подняв каждую из мелочей многократно. Это из реальной практики... Для каждого такого случая нужны банально идеи, бо показания профайлера тебе код не напишут. G>>>А ты вообще прочитал то что я процитировал? В 5 пункте fixable слово видел? V>>И? G>Прочитай еще раз
If you did not meet your goal, use tools to discover what the worst-performing fixable thing is, and fix it.
"Если у вас что-то работает плохо — поправьте, что получится (именно так надо переводить fixable), используя подходящие средства." Бу-га-га! Офигительной глубины совет.
V>>>>Есть еще момент: эффективность не всегда определяется пропускной способностью, зачастую идет требования минимизации latency (у нас по работе, например), а в этом деле, когда речь идет о единицах микросекунд, профайлерами уже и близко не пахнет. G>>>А чем пахнет? ты ведь как-то меряешь этот самый latency или ты по коду пытаешься его угадать? V>>Специальные тесты на производительность нужны, с максимальной изоляцией, чтобы минимизировать паразитную постоянную составляющую измерений. G>То есть ты все равно меряешь.
Замеры замерам рознь. Я тебя уверяю, цифры, которые выдаёт профайлер в синтетических тестах, далеко не всегда подходят для выводов о производительности в реальных условиях.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, vdimas, Вы писали:
V>Да не мое, чего уж там... V>Меня тогда еще в проекте не было, когда это определение уже было, в Вики дается без изменений оригинала.
Блин, выражение "меня ещё в проекте не было" на программистском форуме читается весьма неоднозначно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
V>>>>>Это верно в той области ПО, для которой эффективность не является конкурентным преимуществом. Например, для заказного ПО, там же никакой конкуренции... Нужна лишь некая "достаточная" производительность. G>>>>Да-да-да. Забавная байка. У тебя есть сведения о корреляции производительности и продаж для определенного класса программ? V>>>Есть. G>>Показывай.
ГВ>А тебе ключи от сейфа не надо? Упрись, там и разберёшься, что на что влияет. Просто прими как факт, что есть такие предметные области, где 30 микросекунд latency — "слив зощитан", а 1,5 микросекунды — топ продаж. Но вообще, тебе о том знать не надобно, так оно проще: я ничего не имею против того, чтобы абсолютное большинство озабочивалось latency, когда оно превысит сотни миллисекунд.
Не думаю что слово "коробочный" к такому ПО применимо.
V>>>>>А в коробочном ПО в реальности бывает так, что профайлер показывает до 30% затрат на всего одну из самых затратных операций, но она никак не оптимизируема, всё, упёрлись в предел. Зато остальное можно подтянуть, то самое, которое 1-2% каждое в среднем, но примерно вдвое общую эффективность поднять, подняв каждую из мелочей многократно. Это из реальной практики... Для каждого такого случая нужны банально идеи, бо показания профайлера тебе код не напишут. G>>>>А ты вообще прочитал то что я процитировал? В 5 пункте fixable слово видел? V>>>И? G>>Прочитай еще раз
ГВ>
If you did not meet your goal, use tools to discover what the worst-performing fixable thing is, and fix it.
ГВ>"Если у вас что-то работает плохо — поправьте, что получится (именно так надо переводить fixable), используя подходящие средства." Бу-га-га! Офигительной глубины совет.
И он, сука, работает. Я тут недавно консультировал коллег по вопросам производительности. Они полмесяца тыкались не зная в чем проблема, потом я показал как в их случае надо мерить. Вот померили и сразу нашлись узкие места. Которые поправили за считанные дни.
Любая попытка улучшить производительность должна начинаться с замеров и устранения узких мест.
Тут же каждый второй гуру говорит что нужны тайные знания, а на практике 99% производительности вытягивается именно так. А только 1% требует "щаманства".
V>>>>>Есть еще момент: эффективность не всегда определяется пропускной способностью, зачастую идет требования минимизации latency (у нас по работе, например), а в этом деле, когда речь идет о единицах микросекунд, профайлерами уже и близко не пахнет. G>>>>А чем пахнет? ты ведь как-то меряешь этот самый latency или ты по коду пытаешься его угадать? V>>>Специальные тесты на производительность нужны, с максимальной изоляцией, чтобы минимизировать паразитную постоянную составляющую измерений. G>>То есть ты все равно меряешь.
ГВ>Замеры замерам рознь. Я тебя уверяю, цифры, которые выдаёт профайлер в синтетических тестах, далеко не всегда подходят для выводов о производительности в реальных условиях.
Отсутствие каких-либо цифр не лучше. Попытка делать хоть какие-то выводы в таком случае — шаманство.
G>потом я показал как в их случае надо мерить. Вот померили и сразу нашлись узкие места. G>Тут же каждый второй гуру говорит что нужны тайные знания,
в первой строчке, ты говоришь что: челы не знали что делать, но ты им принес "тайные знания", и они сразу проблему решили.
во второй сторочке, ты говоришь, что "тайных знаний" не бывает.
так ты определись:
либо это не тайные знания — и тогда их знают все, но тогда непонятно почему без тебя не смогли справиться,
либо эти знания имеют не все, тогда они тайные
G>Тут же каждый второй гуру говорит что нужны тайные знания, а на практике 99% производительности вытягивается именно так. А только 1% требует "щаманства".
Это если тыкать LINQ и линейные пробежки направо и налево, т.е. заведомо иметь потенциальный запас по увеличению эффективности на пару порядков, тоды да... а если прога уже довольно-таки неплоха, но надо еще в несколько раз быстрее... посмотрел бы я на то, как бы ты "толковал" показания профайлера. Без идей в плане того, куда двигать дальше, показания профайлера превращаются в бесполезный набор цифр. Это то, что я пытаюсь донести.
В приведенном Липпертом примере автор пошагово порет фигню, мягко говоря, порождая код, который все-равно надо будет выкинуть через несколько итераций. Почему нельзя рассмотреть алгоритм целиком? Зачем оптимизировать куски заведомо неэффективного алгоритма, коль можно сразу применить более эффективный алгоритм? Это же какой-то наёп, сорри, а не полезные советы. Они пойдут только какому-нить новичку, который будет раскидывать коровьи лепешки буквально везде по коду. Только тогда подобный алгоритм будет хоть как-то полезен для этого вырожденного случая, чтобы программа хоть как-то задышала, т.е. перешла из стадии макета в стадию чего-то полезного.
G>Отсутствие каких-либо цифр не лучше. Попытка делать хоть какие-то выводы в таком случае — шаманство.
А где ты видел "отсутствие каких-либо цифр"? Речь шла зашла о сценариях применения профайлеров. В любом случае дотнетный профайлер не поможет, когда доходит до уровня игр с разной грануляцией блокировок, переделкой алгоритмов в многопоточные или обратно и т.д., борьбой с издержкой кешей, затрат на переключения контекстов и т.д. Тут уместны уже нейтивные от интел или амд для нейтивных же программ.
Здравствуйте, gandjustas, Вы писали:
ГВ>>А тебе ключи от сейфа не надо? Упрись, там и разберёшься, что на что влияет. Просто прими как факт, что есть такие предметные области, где 30 микросекунд latency — "слив зощитан", а 1,5 микросекунды — топ продаж. Но вообще, тебе о том знать не надобно, так оно проще: я ничего не имею против того, чтобы абсолютное большинство озабочивалось latency, когда оно превысит сотни миллисекунд.
G>Не думаю что слово "коробочный" к такому ПО применимо.
Что тут сказать? Нельзя спорить с негативно сформулированными тезисами, тем более, если они оформлены как личное мнение.
G>>>>>А ты вообще прочитал то что я процитировал? В 5 пункте fixable слово видел? V>>>>И? G>>>Прочитай еще раз
ГВ>>
If you did not meet your goal, use tools to discover what the worst-performing fixable thing is, and fix it.
ГВ>>"Если у вас что-то работает плохо — поправьте, что получится (именно так надо переводить fixable), используя подходящие средства." Бу-га-га! Офигительной глубины совет. G>И он, сука, работает. Я тут недавно консультировал коллег по вопросам производительности. Они полмесяца тыкались не зная в чем проблема, потом я показал как в их случае надо мерить. Вот померили и сразу нашлись узкие места. Которые поправили за считанные дни.
Молодцы. Только это никак не отменяет того, что приведённая цитата содержит банальность.
G>Любая попытка улучшить производительность должна начинаться с замеров и устранения узких мест. G>Тут же каждый второй гуру говорит что нужны тайные знания, а на практике 99% производительности вытягивается именно так. А только 1% требует "щаманства".
Как ты, наверное, понимаешь, "99%" — это уже не усиление высказывания, а маркер. Сказать, маркер чего именно?
ГВ>>Замеры замерам рознь. Я тебя уверяю, цифры, которые выдаёт профайлер в синтетических тестах, далеко не всегда подходят для выводов о производительности в реальных условиях. G>Отсутствие каких-либо цифр не лучше. Попытка делать хоть какие-то выводы в таком случае — шаманство.
Никто не спорит с тем, что цифры полезны. Вопрос в том, как их получить и как потом применить. В случае серьёзных требований к производительности и то, и другое может оказаться весьма нетривиальными задачами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали: V>>Таки не надо смещать акценты, речь шла конкретно про профайлер. Даже если мы "тупо" замеряем "самый верхний цикл" и видим, что оптимизация некоего куска не приносит бенефитов, с чего бы тратить на него месяц? S>Речь шла о том, что кое-кто тут считает, что без полного понимания внутреннего устройства потрошков машины, разработчик якобы обречён запускать профайлер каждые 10 строк.
Что есть "потрошки машины"? Конкретная архитектура, что ли? Зачем? Достаточно владеть классом архитектур, например Гарвардской или Фон Неймана, знать про особенности: суперскаляр, явный параллелизм или еще какой-нить гипер-трединг. Такие вещи конечно знать стоит.
S>разработчик якобы обречён запускать профайлер каждые 10 строк.
Пример Липперта как раз взят из этой области. Был приведен код, который никогда не породит более-менее опытный разработчик. Показана "польза" профайлера на примере полнейшего УГ.
S>Из этого подразумевается что S>а) профайлер — это очень плохо
Каждые 10 строк? Хуже некуда. Все еще не согласен? Или будешь делать попытки обобщить на "плохо в любом случае"? Будет демагогия.
S>б) программист зачем-то заморочен задачами перформанса постоянно (а не в тот момент, когда есть что померить)
Я не понимаю степень негатива термина "заморочен"... Уметь делать хотя бы грубые прикидки характеристик собственных разрабатываемых алгоритмов разработчик обязан, разумеется. Если он этого не умеет и не хочет уметь, пусть развивается, например в специалиста некоей прикладной области или менеджмент.
S>в) что программист должен быть способен решать проблемы производительности в уме
В терминах O(n) — непременно. А так же иметь некий опыт прикидки коэф К при O(n) для самых частоиспользуемых конструкций.
S>г) и вот что для этого необходимо знать матчасть назубок.
S>Самое смешное, что даже если удастся доказать универсальную истину пунктов а, б, и в (что, очевидно, бесперспективное занятие), и аргументировать таким образом г), ни к чему интересному мы не придём.
А я его и не понял, пункта г. В дисциплине IT матчасть столь широка, что стоило бы сузить. Универсальный подход тут один — надо разбираться в том, над чем работаешь. Т.е. и в прикладной области и в областях общеайтишных, применяемых для решения прикладной задачи.
S>В том смысле, что я не делал утверждения, которое вы пытаетесь опровергнуть. Я совершенно не против знания программистом матчасти. S>Я против того, чтобы программист слеплял в голове всё в сплошной монолит.
Я понятия не имею, какие конкретно образы принимают разделы наук, инженерии и связей м/у ними в твоей голове. Боюсь, что это разговоры в пользу бедных.
S>Примеры приводить не буду, чтобы не спровоцировать ещё один поток "откровений" на общеизвестные темы.
А не уедешь далеко на примерах с манерой додумывать за оппонента. Ведь у тебя любой пример в стиле: "вы наверно считаете так-то, но вот вам пример, где вы ошибаетесь..." Такой стиль малость утомляет, когда уже не в первый раз. Я с самого начала предложил таки просто договориться о термине "абстракция", чтобы быть уверенным, что мы говорим об одном и том же. Заодно сэкономить массу времени. А не упражняться примерами на образное мышление. Хотя и это путь, хоть один из самых долгих... В итоге, я кажется понял, что для тебя есть абстракция, попытаюсь сформулировать, коль ты согласен обсуждать что угодно, кроме посылов, за которые зацепились. Из твоих постов во всей этой ветке мне начинает казаться, что абстракции для тебя — это нечто многослойное, навроде луковицы, типа внутренних и внешних интерфейсов какого-нить АПИ. Наверно отсюда эти попытки выстроить некую однонаправленную (подчиненную) зависимость м/у понятиями, так? Дык, можно было тогда бодаться столь же безрезультатно еще год...
Абстракция — это упрощение, модель, и ничего более. Упрощение в каждом конкретном случае должно быть максимальным, в этом суть абстракции. Это именно то, что я имел ввиду под "разные абстракции для разных по характеру работ над одним и тем же кодом". Еще раз, абстракция — это никакой не "слой" и не "уровень". Потому как "слой" и "уровень" в ПО обозначает именно эти слова, и служат для разграничения подсистем и определения интерфейса м/у подсистемами. Но сами интерфейсы — не есть абстракция, это надо понимать. Абстракцией будет некая вербальная (математическая, автоматная, еще какая-нить) модель подсистемы, доступная для оперирования через те самые интефейсы. Итого, "слой" и "уровень" могут иметь описывающую их работу абстрактную модель, но могут иметь и не абстрактную, а вполне конкретную/реальную. Поэтому это не одно и то же. Подсистемы (слои, уровни, интерфейсы ПО и т.д.) могут иметь связанную с ними абстракцию, но обратное неверно, "абстракция" не значит "слой" или "уровень". Мы вводим слои, чтобы ограничить оперирование конечным числом абстракций, чтобы договориться о терминах внутри системы, т.е. поиметь некие точки отсчета. Это именно то, что я имел ввиду, под "разработчик выбирает уровни абстракции произвольно". Ты мне привел "уже заданные" уровни абстракции дотнета? Гы... разработчики в MS выбрали такие уровни в процессе разработки, сверху они ни разу не заданы.
Твой любимый пример с языком SQL — показателен. Язык — не есть сама модель СУБД, это языковое ср-во оперирования НАД моделью СУБД, считай публичный интерфейс модели. И то, далеко не полный обычно, бо многие вещи в том же MS SQL идут не в языковом, а в "библиотечном" виде через специальные системные ф-ии или запросы к системным таблицам. Т.е. не получилось выразить в конструкциях языка операции над моделью, приходится "доэмулировать" части модели уже имеющимися ср-вами языка. В дотнете, кстати, аналогично: в C# не доступны все возможности CLI, хотя такие возможности, задействованные в других языках, вполне можно раскрутить через рефлексию, т.е. через библиотечные ср-ва, но не языковые.
Здравствуйте, Sinclair, Вы писали:
V>>Опять продемагогил... спасибо... ФП не означает отсутствие императивности, оно означает наличие ф-ий как первоклассных объектов языка, только и всего. И с чего бы императивному алгоритму оперировать обязательно иммутабельным состоянием? Чай не ООП... S>Вы, наверное, хотели сказать мутабельным состоянием?
Ну да, я же возражал. Ответишь или как?
S>ОМГ. Я же подробно объяснил, что операции, выполняемые SQL сервером — совсем не те операции, которые описаны в РА.
Некоторые не совсем те, некоторые совсем те.
V>>Да, именно, удивительное противоречие самому себе. S>Никакого противоречия нет. Вы по-прежнему не можете отличить абстрактную математику от её реализации? Печально.
В каком месте ты это увидел? Давай пошагово, как ты пришел к такому выводу. Я уже плохо понимаю, что именно ты пытаешься доказать. Сорри, выглядит как потеря нити беседы... Мне немного сложно уловить саму постановку вопроса в плане "отличить". IMHO в IT всегда стоит задача ровно наоборот — найти связь некоей частной задачи с неким прикладным или фундаментальным матаппаратом, чтобы не изобретать велосипеды при решении этой задачи.
S>Ваши идеи про "скрытые атрибуты" я понял. К сожалению, они вам не помогут.
Они помогают всем, и мне и разработчикам СУБД. Оставь сожаления себе.
S>Для начала, ничего подобного в реляционной модели нет, и с точки зрения алгебры вы вводите просто тавтологии, т.е. отношения, не содержащие новой информации.
Обоснуй в терминах реляционной модели, плиз. Давай, отноешния, аттрибуты, вывод незначимости аттрибута из-за наличия таких-то зависимостей. Давай уже заканчивать разводить пустые ля-ля, ближе к телу.
S>Во-вторых, в реляционной модели нет понятия порядка, поэтому вам не удастся, оставаясь в рамках неё, рассчитать стоимость операций над отношениями.
Ну это ход конем, конечно, в реализации программы "оставаться в рамках неё"... Ничего, что у меня целые числа ограниченной разрядности, для начала?
Короче, задачи реализации примитивов РА над различными популярными видами структур идут как лабораторки у студентов, справлялись даже девочки. Тебе лично я писал о готовых формулах
вычисления стоимости для пар {объект, операция}.
Итого, есть некая операция из РА, и есть ее некая реализация некоторым объектом, к этой паре привязана стоимость операции. Буду повторять, пока не поймешь.
V>>Ну так что первично, а что вторично? Мне как разработчику видно ровно обратное, фиксированные размеры страниц нужны исключительно для нужд кластерных индексов, которые принципиально живут только в контексте детерминированных размеров. S>Вы делаете сразу несколько неверных утверждений. S>1. Кластерному индексу всё равно, ограничен размер записи или нет.
Не все равно, в БД с неизвестными размерами записей нет кластерных индексов.
S>2. Фиксированные размеры страниц нужны для унификации алгоритмов доступа и распределения памяти.
Таки речь была не о страницах. Покажи мне двоичный поиск в данных неизвестной длины.
S>Вы бредите? Seek по ключу индекса дёшев всегда, и никак не требует ограничения размеров таблицы.
По кластерному не всегда, зависит от размеров таблицы. При достаточно "широкой" таблице в несколько раз менее эффективен, чем некластерный. Я получал в 4 раза увеличение общего быстродействия. Это потому что некоторые операции стали быстрее на порядок после выноса индекса как некластерного. И про монотонность ты тоже правильно говорил, кстати, проблема с кластерными.
S>Я вам привёл подробные условия превосходства кластерного индекса над некластерным. Что именно вам непонятно?
Я не понял, где "превосходство"? Описанные признаки идут за превосходство только в ограниченных условиях.
V>>Ну оставайся при своем. S>Почему "при своём"? Я же давал ссылку: S>
S>The current ISO SQL standard doesn't mention the relational model or use relational terms or concepts.
Ну так, чтобы путанницы не возникло, непосредственного маппинга нет. Есть частично, во всех тех самых учебниках говорится. Но это частично — это те самые 99% всех операций, выборка, пеерименование, объединение, произведение/join и т.д.
V>>Достойный аргумент. Ничего если я предположу отсутствие навыков по операциям РА, бо эти вещи как бы аксиоматичны? S>Какие вещи? Где аксиоматичны? Ну, продемонстрируйте мне, что является аргументом операции bookmark lookup, а что — её выходом. И попробуйте найти аналог этой операции
Пересечение, если для мн-ва букмарков или ограничение, если по 1-му.
V>>Ес-но, только что мне мешает видеть ту же самую модель, что и оптимизатор? Как я тогда буду писать эффективные приложения для СУБД, если я не понимаю показания плана оптимизатора? Или вот я разработчик СУБД, с какой радости я не могу прикладывать РА к индексам? Это откуда такие запреты-то? Я не только могу, но я обязан использовать весь этот аппарат, чтобы не породить УГ. S>Оттуда, что операции РА имеют ограничения. Читайте учебник по РА.
Какой именно? Давай, справедливости ради работу Кодда?
Объясни на пальцах, почему я не имею права реализовывать в коде некие операции из РА? Вот я принял некую модель хранения отношений в своей программе, вот хочу реализовать над отношениями операции из РА. Где ты взял запрет? Я уже который раз не могу добиться, обоснуй, почему нельзя.
Почему я целочисленные числа могу делить, например, хотя результат будет врать, согласно математике, а реализовать несчастные примитивы РА, причем именно так, чтобы они "не врали" — не могу? Это откуда такая трава-то?
S>Если вы разработчик СУБД, то вам придётся пользоваться несколько более другой моделью. Она будет отличаться от РА примерно так же, как ТФКП от школьной арифметики.
У тебя будут некие контейнеры, которые будут предоставлять операции над ними, например операции ограничения. Воможно, что помимо этих операций будут предоставлять еще некоторые, выходящие за рамки РА. Да ради бога. У меня в программе-примочке для гитары столько кода, никак не связанного непосредственно с теорией обработки сигналов, особенно в плане нелинейных преобразований... Однако же, там где применим существующий матаппарат, ему весь остальной код ничуть не мешает.
V>>Ну ты бы по классике прошелся. Нет никаких прыжков, есть постановка задачи, анализ, и предложенная модель для решения этого класса задач. И оставь в покое несчастный SQL, это уже какое свербение в одном месте. Во многих учебниках никакого SQL нет, поэтому заканчивай делать вид, что ты видел учебники в глаза кроме руководств к конкретным СУБД. S>Ну давайте, приведите мне ссылку на этот учебник, в котором никакого SQL нет.
Коль речь именно об учебнике, то исходная работа Кодда на учебник не тянет, угу, хотя крайне рекомендуется к прочтению хотя бы однократно. Популярен вот этот учебник по теории реляционых БД: http://www.twirpx.com/file/100951/ Многие "учебные пособия" по реляционным СУБД в наших ВУЗах идут как "творческая компиляция" именно этого учебника.
Рассматривается 5 языков запросов, и среди них SQL. Дается ему характеристика.
Синтаксически SQL близок к исчислению кортежей, но не более, так как он также использует и операции реляционной алгебры.
И я к этому вопросу возвращаться больше не буду, сорри, бо надоело 5-й пост спорить со слухами. Коль оппонент так настаивает на чем-то, может оно не спроста? Может пора было уже погуглить хотя бы треть того времени, что было затрачено на написание поста?
Другим примером ранней реляционной системы является Ingres [21-22], разработанный на рубеже 70 и 80-х годов в Беркли. Эта университетская система изначально была настроена на работу в UNIX'e и не ориентировалась на фиксированную аппаратную платформу. Каждому хранимому отношению соответствовал отдельный файл. Индексы являлись частным случаем отношений.
Как известно, двумя фундаментальными языками запросов к реляционным БД являютсяязыки реляционной алгебры и реляционного исчисления. При всей своей строгости итеоретической обоснованности эти языки редко используются в современных реляционных СУБД в качестве средств пользовательского интерфейса. Запросы на этихязыках трудно формулировать и понимать. SQL представляет собой некоторуюкомбинацию реляционного исчисления кортежей и реляционной алгебры, причем до сихпор нет общего согласия, к какому из классических языков он ближе. При этомвозможности SQL шире, чем у этих базовых реляционных языков, в частности, в общемслучае невозможна трансляция запроса, сформулированного на SQL, в выражение реляционной алгебры, требуется некоторое ее расширение.
От себя добавлю, что для подавляющего большинства обычных запросов, "без выкрутасов" конкретной СУБД, никакого расширения не требуется.
В общем, учебник дан, в конце каждого раздела задачи. Приятного времяпрепровождения. Особенно полезен обзор других языков, помимо SQL, чтобы убрать из головы на нем некий специальный фокус и навести порядок в плане понимания самой проблематики языков запросов.
Типа, SQL за 21 день? Или "самое полное руководство по MS SQL Server"? Спасибо за понимание.
V>>Меня аж плющит, когда ты снова и снова сравниваешь SQL с реляционной моделью. Сравнивать язык и модель — ну это просто за рамками здравого смысла. S>Это ничего, пробелы в вашем образовании можно восполнить. Вот у нас язык SQL. Он задаёт некоторые операции. Вопрос: операции над чем?
S>Очевидно, что существуют некоторые объекты (в смысле математики, а не ООП), которыми манипулирует SQL. Почитайте раздел 4 стандарта — там вводится довольно подробное и точное описание того, что такое "таблица", что такое "представление", что такое "процедура". И вот эта модель, что характерно, отличается от Реляционной Модели.
Таки общепринято считать за соответствие таблицы и отношения, например. А уж представления — тем более.
S>В реляционной алгебре — именно так. В SQL — хрен, простите, на воротник.
Т.е. что есть "домен" мы тоже в упор не понимаем? Тогда на пальцах: ты показал домен {true, false, null}, с некоторыми правилами/формулами над значениями доменов, например not(null)=null. Значение из этого домена при использовании в кач-ве предиката неявно приводится к двоичной логике. При чем, далеко не во всех субд. Правила приведения этого домена к значению предиката указан в справочнике конкретной СУБД, но не в справочнике к стандарту SQL. Поэтому грамотно было бы сказать не в SQL, а в MS Transact SQL. Даже в этом случае нет проблем. А у тебя проблема от того, что ты предполагаешь, будто предикат может иметь более двух значений. Не может по определению. Если значение выражения не приводимо к булевскому, выдается ошибка. В твоем примере на null некоторые базы ругнуться в рантайм, и тебе потребуется привести преобразование null к boolean явно через конструкции is null, is not null.
S>Иначе они не могли бы исопльзоваться как предикаты. Или ты имел ввиду, что есть операции сравнения в домене значений {true, false, NULL}? Ну и какие проблемы? Определи этот домен и операции по нему для конкретной схемы реляционной модели и вперед — конкретно реляционной модели, повторюсь, это по барабану.
S>Проблемы очень простые. В реляционной модели все предикаты выполняются в булевой логике.
Выделенное — несвязанный набор слов.
S>Это означает, что, скажем, оператор проекции всегда возвращает отношение. S>Давайте возьмём примитивную таблицу — с первичным ключом, наличие которого вам кажется столь важным. В ней будут некоторые неключевые атрибуты (здесь и далее я пишу в терминах SQL): S>
S>create table Person(id int primary key, name varchar(max), cityId int foreign key references city(id))
S>
S>Очевидно, эта таблица вполне себе укладывается в реляционную модель. S>Возьмём от неё проекцию: S>
S>select cityId from Person
S>
S>Чтобы эта проекция удовлетворяла требованиям реляционной модели, мы обязаны избавиться от дубликатов: S>
S>select distinct cityId from Person
S>
S>Если бы SQL соответствовал РА и РМ, то distinct был бы принудительно приделан к каждому стейтменту.
Боже, какие спекуляции. А для операции объединения наоборот, чтобы не было distinct надо специально указать ALL. Я лишь вижу, что для обоих случаев существует языковый способ выполнить строгую операцию РА, либо с практически тем же синтаксисом рассматривать набор данных, который не подчиняется в дальнейшем реляционной теории. То, что SQL позволяет больше, чем РА, никто и не пытался оспаривать.
Характерно, что обсуждение это (ты просто забыл уже) выросло из обсуждения операций над букмарками индексов, которые таки именно что уникальны и полностью удовлетворяют матаппарату РА. А вопрос вообще изначально стоял так: если в каком-то месте матаппарат подходящ, почему он не должен использоваться?
S>А не сделано это оттого, что сие может оказаться крайне дорогостоящим удовольствием.
Красиво ты поспешил с выводами... ведь это смотря какой результат будет формирован в конце, зачастую ровно наоборот: distinc "где-то в середине" способен поднять эффективность многократно.
S>
S>select cityName from city where cityId in (select cityId from Person where name like '%vdi%')
S>
S>Здесь семантика запроса не зависит от того, возвращает ли вложенный запрос set или multiset. И в очень многих практических случаях — именно так. Если ограничиться проекциями, ограничениями, и соединениями, то появление дубликатов на промежуточных этапах несущественно, т.к. мы можем привести muliset к set на окончательном этапе. Форсирование ограничений на дубликаты на всех промежуточных этапах приведёт к падению производительности.
Настаиваю, что ты поторопился с выводами. По моему опыту "вылизывания" быстродействия запросов, ровно наоборот — приходится расставлять disctinct направо и налево, и чем раньше в "сложной" формуле, тем заметнее эффект.
V>>Тогда не существовало бы теории реляционных БД, коль она не нужна? S>Я не говорю, что она не нужна. Существует же арифметика натуральных чисел, хотя реальные уравнения удобнее решать в комплексных числах. Нужно просто понимать, что чистая РА — это сознательное упрощение моделей, применяемых в реальных СУБД.
Тогда для чего оно надо? (есть тут смайлик печальной улыбки?)
V>>Я бы скорее сравнил Фурье и корреляцию по сетке частот. S>А я бы не стал.
Почему?
V>>Для реляционной модели это неважно. Повторюсь, в РА важна последовательность операций, никакая конкуренция не рассматривается. S>Поскольку в РА нет изменяемого состояния, конкуренция в ней вообще не интересна.
Операции обновления отношений относятся к операциям над кортежами, а все вместе входит в теорию реляционных СУБД, матаппарат которой мы и рассматриваем. Например, декомпозиция отношений называется "оператор фактор" и не входит в РА, хоть в ходит все в тот же аппарат теории реляционных БД. Я даже скажу, что без этого оператора в реляционной теории просто жизни нет, ведь мы даже не сможем привести исходную схему к нормальным формам. Эта операция не входит в РА потому, что результатом операции является множество отношений, а не одно, как приняно для всех остальных операций из РА. Но, тем не менее эта операция входит в теорию реляционных БД и
используется как концептуальное ср-во для поиска эффективных путей хранения отношения
Помнишь, что я тебе про индексы и декомпозицию отношений говорил? Это все не с потолка берется и не из головы каждого нового разработчика, а давно пережеванные в рамках реляционой теории вещи. Избыточность, покрытие, ограничения целостности, нормальные формы, — вот пример целей, задаваемых реляционной теории, а РА — лишь один из инструментов.
S>А зачем вам противоречие? Мы же не опровергаем РА как таковую. Мы говорим о том, что РА недостаточно для описания реальных промышленных СУБД.
А реляционного исчисления? А всех наработок реляционной теории БД?
Это уже похоже на метания.
S>Ситуация опять такая же, как в арифметике vs ТФКП. Я вам толкую о том, что уравнений типа f(x) = g^2(x) нужны комплексные числа, а вы мне "я не вижу противоречий c примитивами арифметики".
Э, нет. Ты мне о том, что эти комплексные числа нужно изобрести каждый раз заново, а я тебе — так вот же, учебник по вышке.
V>>Да нету никаких индексов на физическом уровне просто. Индексы — это тоже логическая единица модели конкретной СУБД. S>Вы просто не понимаете общепринятой терминологии. Есть устоявшееся сочетание "физический план выполнения запроса".
Вот этот термин и надо было применять.
V>>Я могу еще повторить больими буквами, если не понял — РА всегда оперирует неким последовательным алгоритмом. S>Вы определение "императивного программирования" уже прочитали? Тогда осталось его понять.
Можно я избавлю себя от поиска соответствия "последовательного алгоритма" и "императивного программирования"? Важно только одно — аргументами последующих операций являются результаты предыдущих. Это позволяет утверждать, что порядок вычислений важен.
V>>В общем, опять и снова могу лишь рекомендовать прорешать задачи по РА, с целью проникнуться проблематикой, и чтобы составить затем свое мнение не на вырезанных из контекста фразах, а на личном опыте. S>Какие, например, задачи?
Здравствуйте, DarkGray, Вы писали:
G>>потом я показал как в их случае надо мерить. Вот померили и сразу нашлись узкие места. G>>Тут же каждый второй гуру говорит что нужны тайные знания,
DG>в первой строчке, ты говоришь что: челы не знали что делать, но ты им принес "тайные знания", и они сразу проблему решили. DG>во второй сторочке, ты говоришь, что "тайных знаний" не бывает.
То что надо мерить — не тайные знания. Тем не менее не всем они известны.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Отсутствие каких-либо цифр не лучше. Попытка делать хоть какие-то выводы в таком случае — шаманство.
V>А где ты видел "отсутствие каких-либо цифр"? Речь шла зашла о сценариях применения профайлеров. В любом случае дотнетный профайлер не поможет, когда доходит до уровня игр с разной грануляцией блокировок, переделкой алгоритмов в многопоточные или обратно и т.д., борьбой с издержкой кешей, затрат на переключения контекстов и т.д. Тут уместны уже нейтивные от интел или амд для нейтивных же программ.
Не надо усложнять. Ты говорил что надо уметь "видеть" проблемы быстродействия в коде, тебе дали элементарный код, но ты в нем проблему не увидел.
Как ты собираешься в сложных случаях без измерений вообще что-то делать?
Ты выдвигал тезис о том что априори важно понимать как работает тот или иной код с точки зрения быстродействия. Тебе уже не один человек говорит что это необязательное условие, что в первую очередь надо мерить.
Здравствуйте, vdimas, Вы писали: V>Ну да, я же возражал. Ответишь или как?
Я же ответил. У вас трудности с восприятием?
Повторю: Ну, как бы по определению:
In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state
V>Некоторые не совсем те, некоторые совсем те.
Даже если бы были те, которые "совсем те", важно то, что есть "совсем не те".
V>В каком месте ты это увидел? Давай пошагово, как ты пришел к такому выводу.
Перечитайте текст, на который вы отвечаете, ещё раз. Есть три фразы:
С точки зрения математики комплексных чисел, операция умножения a * b не имеет никакой "стоимости".
А вот если мы перейдём к некоторому представлению комплексных чисел в компьютере, то операция a * b будет иметь некоторую реализацию в этом представлении.
И вот уже у этой реализации будет некоторая стоимость, выраженная в терминах более низкоуровневых операций.
Вы в ответ на мою первую возражаете моей же третьей, а потом внезапно обнаруживаете "противоречие". Рекомендую прекратить принимать то, что вы принимаете, что бы это ни было.
V>Обоснуй в терминах реляционной модели, плиз. Давай, отноешния, аттрибуты, вывод незначимости аттрибута из-за наличия таких-то зависимостей. Давай уже заканчивать разводить пустые ля-ля, ближе к телу.
А куда ближе? Возьмём ваш собственный пример (надеюсь, с его пониманием у вас проблем не будет?):
Простейший пример: есть некая схема R {ABCD}, и заданы зависимости A->B, B->CD. Для этой схемы будет уместна декомпозиция {AB, BCD}, причем, в реальной СУБД мы во втором отношении можем создать индекс B, сугубо эффективности ради, но! это будет означать лишь еще раз произвести декомпозицию по всем правилам декомпозиций с вводом специального аттрибута-ключа B#, для требований сохранения исходной зависимости B->CD транзитивно через B->B#, B#->CD. В итоге получим декомпозицию заданной схемы в виде: {AB, BB#, B#CD}.
Вот вы ввели отношение BB#. Зачем оно? Оно не привносит никакой новой информации. Потому что у нас B<->B#.
V>Ну это ход конем, конечно, в реализации программы "оставаться в рамках неё"... Ничего, что у меня целые числа ограниченной разрядности, для начала?
Ну, вообще говоря, это надо учитывать. А вы не знали? Соотношения, справедливые для "абстрактной арифметики целых чисел" могут запросто потерять справедливость для "арифметики чисел по модулю 2^32". Если вам это не очевидно, то не стесняйтесь спрашивать.
V>Итого, есть некая операция из РА, и есть ее некая реализация некоторым объектом, к этой паре привязана стоимость операции. Буду повторять, пока не поймешь.
Вы продолжаете меня развлекать. Можно привести пример такой "пары"? Ну, чисто чтобы я понял, что вы считаете стоимостью, а что — операцией.
V>Не все равно, в БД с неизвестными размерами записей нет кластерных индексов.
Скажите, где вы это вычитали? Вот, например, в MS SQL 2008 ограничение на размер записей снято. Кластерные индексы, тем не менее, существуют. V>Таки речь была не о страницах.
А о чём? Я же вам пишу: ограничения на размер записи (8060 байт) были связаны с ограниченностью размера страницы (8192 байта). Наличие либо отстутсвие кластерного индекса никак не влияет на это ограничение. V>Покажи мне двоичный поиск в данных неизвестной длины.
Ничего не понимаю. В чём ваша проблема? Вы считаете, что невозможно построить индекс по ключу неограниченной длины?
Во-первых, это не так. Во-вторых, если бы даже это было так, то какая разница, кластерный индекс или нет?
В-третьих, мы обсуждали размер данных, а не размер ключа.
V>По кластерному не всегда, зависит от размеров таблицы. При достаточно "широкой" таблице в несколько раз менее эффективен, чем некластерный.
Теперь пошла в ход "ширина" таблицы. Вы мне лучше расскажите, при чём тут вмещаемость таблицы в оперативную память, которую вы упоминали в прошлый раз.
V>Я не понял, где "превосходство"? Описанные признаки идут за превосходство только в ограниченных условиях.
Совершенно верно. А вы как ожидали? Что кластерный индекс будет панацеей?
S>>Какие вещи? Где аксиоматичны? Ну, продемонстрируйте мне, что является аргументом операции bookmark lookup, а что — её выходом. И попробуйте найти аналог этой операции V>Пересечение, если для мн-ва букмарков или ограничение, если по 1-му.
Перечитайте вопрос ещё раз и постарайтесь ответить на него полностью.
V>Какой именно? Давай, справедливости ради работу Кодда? V>Объясни на пальцах, почему я не имею права реализовывать в коде некие операции из РА? Вот я принял некую модель хранения отношений в своей программе, вот хочу реализовать над отношениями операции из РА. Где ты взял запрет? Я уже который раз не могу добиться, обоснуй, почему нельзя.
Да лично вам-то я не запрещаю. Были, были попытки построить СУБД на основе "чистой" реляционной модели. В промышленность не пошли. Читайте RTFM. А реальные СУБД уже реализованы так, как они реализованы. А не так, как вы себе представляете.
V>
V>Как известно, двумя фундаментальными языками запросов к реляционным БД являютсяязыки реляционной алгебры и реляционного исчисления. При всей своей строгости итеоретической обоснованности эти языки редко используются в современных реляционных СУБД в качестве средств пользовательского интерфейса. Запросы на этихязыках трудно формулировать и понимать. SQL представляет собой некоторуюкомбинацию реляционного исчисления кортежей и реляционной алгебры, причем до сихпор нет общего согласия, к какому из классических языков он ближе. При этомвозможности SQL шире, чем у этих базовых реляционных языков, в частности, в общемслучае невозможна трансляция запроса, сформулированного на SQL, в выражение реляционной алгебры, требуется некоторое ее расширение.
Прекрасно. Вы нашли-таки аргумент в пользу моей правоты.
V>От себя добавлю, что для подавляющего большинства обычных запросов, "без выкрутасов" конкретной СУБД, никакого расширения не требуется.
А я от себя добавлю, что нет, для подавляющего большинства обычных запросов, "без выкрутасов", и без конкретной СУБД, таки требуется расширение.
V>Таки над конкретной БД, чаще всего не предоставляя всех ср-в по оперированию ей, при этом.
Да? А ISO SQL — он над какой конкретной БД?
V>Таки общепринято считать за соответствие таблицы и отношения, например.
Таки это распространённое заблуждение. Я же вам подробно объяснил, почему.
V>Т.е. что есть "домен" мы тоже в упор не понимаем? Тогда на пальцах: ты показал домен {true, false, null}, с некоторыми правилами/формулами над значениями доменов, например not(null)=null. Значение из этого домена при использовании в кач-ве предиката неявно приводится к двоичной логике.
Нет. С чего это вы взяли? V>При чем, далеко не во всех субд. Правила приведения этого домена к значению предиката указан в справочнике конкретной СУБД, но не в справочнике к стандарту SQL.
Вы сами-то стандарт читали? http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
Курить раздел 8 до просветления. Подробнейшим образом изложены формальные правила исчисления предикатов в SQL. И таки да, предикат возвращает одно из трёх значений. Никакого приведения к двоичной логике нет — оно у вас в голове.
V>Поэтому грамотно было бы сказать не в SQL, а в MS Transact SQL. Даже в этом случае нет проблем. А у тебя проблема от того, что ты предполагаешь, будто предикат может иметь более двух значений. Не может по определению. Если значение выражения не приводимо к булевскому, выдается ошибка. В твоем примере на null некоторые базы ругнуться в рантайм, и тебе потребуется привести преобразование null к boolean явно через конструкции is null, is not null.
Вы бредите. Никакой ошибки не выдаётся (если, конечно, СУБД соответствует стандарту). Выдаётся результат, который не соответствует результату в РА.
S>>Иначе они не могли бы исопльзоваться как предикаты. Или ты имел ввиду, что есть операции сравнения в домене значений {true, false, NULL}? Ну и какие проблемы? Определи этот домен и операции по нему для конкретной схемы реляционной модели и вперед — конкретно реляционной модели, повторюсь, это по барабану.
Я вам показал, какие проблемы возникают в реляционной модели.
V>Боже, какие спекуляции. А для операции объединения наоборот, чтобы не было distinct надо специально указать ALL. Я лишь вижу, что для обоих случаев существует языковый способ выполнить строгую операцию РА, либо с практически тем же синтаксисом рассматривать набор данных, который не подчиняется в дальнейшем реляционной теории.
Совершенно верно. И большая часть реальных баз данных "не подчиняется в дальнейшем реляционной теории". V>То, что SQL позволяет больше, чем РА, никто и не пытался оспаривать.
А, ну уже некий прогресс. Пару постов назад вы просто рубаху на груди рвали по поводу того, что ничего кроме РА в SQL нету.
V>Характерно, что обсуждение это (ты просто забыл уже) выросло из обсуждения операций над букмарками индексов, которые таки именно что уникальны и полностью удовлетворяют матаппарату РА.
Обсуждение выросло из способности программиста отличать особенности конкретной СУБД от ISO SQL, а его — от реляционной модели.
V>Красиво ты поспешил с выводами... ведь это смотря какой результат будет формирован в конце, зачастую ровно наоборот: distinc "где-то в середине" способен поднять эффективность многократно.
Я не поспешил, это вы спешите с интерпретацией. Мало ли что "зачастую". Вопрос в том — сколько будет случаев, где производительность просядет? Именно из-за них выбор, работать ли с множествами или с мультимножествами, отдан программисту. "Чистая" РМ оказалась нежизнеспособной на практике.
V>Настаиваю, что ты поторопился с выводами. По моему опыту "вылизывания" быстродействия запросов, ровно наоборот — приходится расставлять disctinct направо и налево, и чем раньше в "сложной" формуле, тем заметнее эффект.
С учётом ваших перлов относительно кластерных индексов, я не стану принимать вашу настойчивость во внимание.
V>Тогда для чего оно надо? (есть тут смайлик печальной улыбки?)
Как основа для более реальных теорий. Релятивистская механика точнее ньютоновской, но это не означает, что ньютоновскую не нужно изучать.
V>Операции обновления отношений относятся к операциям над кортежами, а все вместе входит в теорию реляционных СУБД, матаппарат которой мы и рассматриваем. Например, декомпозиция отношений называется "оператор фактор" и не входит в РА, хоть в ходит все в тот же аппарат теории реляционных БД. Я даже скажу, что без этого оператора в реляционной теории просто жизни нет, ведь мы даже не сможем привести исходную схему к нормальным формам.
Эта операция не входит в РА потому, что результатом операции является множество отношений, а не одно, как приняно для всех остальных операций из РА. Но, тем не менее эта операция входит в теорию реляционных БД и V>
V>используется как концептуальное ср-во для поиска эффективных путей хранения отношения
Я не очень понимаю, о какой именно реляционной теории вы ведёте речь. Вы не могли бы дать какую-нибудь ссылку на эту теорию?
Впрочем, у меня складывается впечатление, что оператор, о котором вы говорите, можно формально определить через те же операторы РА, которые ввёл Кодд.
V>Помнишь, что я тебе про индексы и декомпозицию отношений говорил? Это все не с потолка берется и не из головы каждого нового разработчика, а давно пережеванные в рамках реляционой теории вещи. Избыточность, покрытие, ограничения целостности, нормальные формы, — вот пример целей, задаваемых реляционной теории, а РА — лишь один из инструментов.
Ок, очень хорошо. Дайте, пожалуйста, ссылку на определение термина "реляционная теория", чтобы мы говорили об одном и том же.
V>А реляционного исчисления? А всех наработок реляционной теории БД? Всех теоретических наработок — достаточно. Я просто настаиваю на том, чтобы отделять мух от котлет.
А то у вас в голове, скажем, понятие "кластерный индекс" неразрывно связано с какими-то идиотскими ограничениями (которые, если и имели место, то в какой-то конкретной реализации этого понятия).
V>Э, нет. Ты мне о том, что эти комплексные числа нужно изобрести каждый раз заново, а я тебе — так вот же, учебник по вышке.
Где вы нашли у меня такое утверждение?
V>Вот этот термин и надо было применять.
Я его и применяю.
V>Можно я избавлю себя от поиска соответствия "последовательного алгоритма" и "императивного программирования"?
Нет, нельзя. Это же вы пытаетесь применять их как синонимы:
Короче, преобразования данных, выполняемых в терминах РА — это ВСЕГДА императивный алгоритм
Так что будьте любезны применять термины в соответствии с их назначением.
V>Важно только одно — аргументами последующих операций являются результаты предыдущих. Это позволяет утверждать, что порядок вычислений важен.
Нет, это не позволяет такого утверждать. Поймите, в РА нет никаких "вычислений". Есть декларации того, как "выход" операции связан со "входом". РА не обязывает исполнителя реально "просматривать" кортежи при выполнении этих операций. РА не обязывает исполнителя формировать промежуточные результаты в сколь бы то ни было воспринимаемом виде. Понимаете?
Я имею право как угодно переупорядочивать операции, если семантика сохраняется. И есть даже специальные соотношения эквивалентности, которые помогают мне это делать. Похожие соотношения эквивалентности применяет оптимизатор запросов на этапе построение логического плана исполнения.
Граница между императивным и декларативным — она именно в наличии изменяемого состояния. Если вам это непонятно, не стесняйтесь спрашивать.
V>А в конце каждой главы по ссылке.
ОМГ. Знаете, я в аспирантуре занимался разработкой своей собственной СУБД. А "задачек из РА" в применении к реальным проектам выполнил столько, что дальнейшую тренировку можно считать избыточной. Вы вот сюда посмотрите, прежде чем предположения о моей квалификации делать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Автор(ы): Гектор Гарсиа-Молина, Джеффри Ульман, Дженнифер Уидом
