Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, gandjustas, Вы писали:

ГВ>>>А тебе ключи от сейфа не надо? Упрись, там и разберёшься, что на что влияет. Просто прими как факт, что есть такие предметные области, где 30 микросекунд latency — "слив зощитан", а 1,5 микросекунды — топ продаж. Но вообще, тебе о том знать не надобно, так оно проще: я ничего не имею против того, чтобы абсолютное большинство озабочивалось latency, когда оно превысит сотни миллисекунд.

G>>Не думаю что слово "коробочный" к такому ПО применимо.

ГВ>Что тут сказать? Нельзя спорить с негативно сформулированными тезисами, тем более, если они оформлены как личное мнение.

У тебя другое мнение? Озвучивай его? Или ты споришь для того чтобы спорить?

ГВ>Молодцы. Только это никак не отменяет того, что приведённая цитата содержит банальность.
Именно, но даже эту банальность не все знают и понимают.


ГВ>>>Замеры замерам рознь. Я тебя уверяю, цифры, которые выдаёт профайлер в синтетических тестах, далеко не всегда подходят для выводов о производительности в реальных условиях.
G>>Отсутствие каких-либо цифр не лучше. Попытка делать хоть какие-то выводы в таком случае — шаманство.

ГВ>Никто не спорит с тем, что цифры полезны. Вопрос в том, как их получить и как потом применить. В случае серьёзных требований к производительности и то, и другое может оказаться весьма нетривиальными задачами.

"Серьезные требования к производительности" лежит за пределами коробочного ПО. А значит там можно говорить только о достаточно производительности.
Да и есть сомнения что в коробочном ПО имеет значение любая другая производительность кроме "достаточной".

Здравствуйте, gandjustas, Вы писали:

ГВ>>Молодцы. Только это никак не отменяет того, что приведённая цитата содержит банальность.
G>Именно, но даже эту банальность не все знают и понимают.

А... Ну да, в общем. Извини, я не ожидал, что всё вокруг настолько плохо, что даже банальности не всем понятны, и эта непонятливость настолько велика, что ты её автоматически переносишь на любых оппонентов.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, gandjustas, Вы писали:

ГВ>>>Молодцы. Только это никак не отменяет того, что приведённая цитата содержит банальность.
G>>Именно, но даже эту банальность не все знают и понимают.

ГВ>А... Ну да, в общем. Извини, я не ожидал, что всё вокруг настолько плохо, что даже банальности не всем понятны, и эта непонятливость настолько велика, что ты её автоматически переносишь на любых оппонентов.

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

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

DG>>в первой строчке, ты говоришь что: челы не знали что делать, но ты им принес "тайные знания", и они сразу проблему решили.
DG>>во второй сторочке, ты говоришь, что "тайных знаний" не бывает.
G>То что надо мерить — не тайные знания. Тем не менее не всем они известны.

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

Здравствуйте, gandjustas, Вы писали:

V>>А где ты видел "отсутствие каких-либо цифр"? Речь шла зашла о сценариях применения профайлеров. В любом случае дотнетный профайлер не поможет, когда доходит до уровня игр с разной грануляцией блокировок, переделкой алгоритмов в многопоточные или обратно и т.д., борьбой с издержкой кешей, затрат на переключения контекстов и т.д. Тут уместны уже нейтивные от интел или амд для нейтивных же программ.

G>Не надо усложнять. Ты говорил что надо уметь "видеть" проблемы быстродействия в коде, тебе дали элементарный код, но ты в нем проблему не увидел.

Была указана проблема в линейном алгоритме, который предлагалось целиком заменить на другой, в терминах O(n). Я тебе это уже писал рядом, подзабыл?

ПЕРЕД началом оптимизаций, программу необходимо переписать. ... а вместо генерации всех вариантов ReplaceQuestionMarks написать алгоритм непосредственного сравнения паттернов с "??". Т.е. для начала сделать преобразования алгоритмов в терминах O(n). И только после доработки алгоритмов можно приступать шлифовать коэффициент K при O(n).

А ты сейчас встал в позицию Липперта, который там пошагово улучшает алгоритм, который всё-равно придется выкинуть целиком на очередной итерации. Это выглядит жалко.


G>Как ты собираешься в сложных случаях без измерений вообще что-то делать?

Коллега, результаты измерений еще уметь толковать надо, чтобы быть уверенным что ты замерил именно то и именно там. А для этого надо уметь оценивать вычислительную сложность алгоритмов.


G>Ты выдвигал тезис о том что априори важно понимать как работает тот или иной код с точки зрения быстродействия. Тебе уже не один человек говорит что это необязательное условие, что в первую очередь надо мерить.

Нет, я уже подробно свою мысль пояснял. В первую очередь — это подготовить адекватные тестовые сценарии, иначе результатами замеров можно будет подтереться. А чтобы подготовить адекватные тестовые сценарии для примера чуть сложнее чем по ссылке, таки придется разбирать код... А там как раз и увидишь те самые "узкие" места автоматически, если будешь этим заниматься регулярно. Об этом "побочном эффекте" я и говорил. Могу опять повторить, что совсем от профайлеров никто не отказывается, не идиоты же, просто бежать сломя голову с профайлером наперевес, как тут слишком часто стали рекомендовать — это вредный совет. Хотя, если for fun only — почему бы и нет...

Здравствуйте, Sinclair, Вы писали:

S>Я же ответил. У вас трудности с восприятием?
S>Повторю: Ну, как бы по определению:
S>

S>In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state

Хм, а после того, как современные императивные языки ввели объявление переменной вместе с ее инициализацией, парадигма сильно пострадала?

Ну вот в терминах С где-то так:
SomeType1 var1;
SomeType2 var2;
var1 = calculate1();
var2 = calculate2(var1);

В C++ это уже так:
SomeType1 var1 = calculate1();
SomeType2 var2 = calculate2(var1);

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


V>>Некоторые не совсем те, некоторые совсем те.
S>Даже если бы были те, которые "совсем те", важно то, что есть "совсем не те".

Дык, со вторым-то никто не спорит. Но ты на основании второго утверждаешь первое.


V>>В каком месте ты это увидел? Давай пошагово, как ты пришел к такому выводу.
S>Перечитайте текст, на который вы отвечаете, ещё раз. Есть три фразы:
S>

S>С точки зрения математики комплексных чисел, операция умножения a * b не имеет никакой "стоимости".
S>А вот если мы перейдём к некоторому представлению комплексных чисел в компьютере, то операция a * b будет иметь некоторую реализацию в этом представлении.
S>И вот уже у этой реализации будет некоторая стоимость, выраженная в терминах более низкоуровневых операций.

Для принятия решений оптимизатором достаточно некоей формулы от неких характеристик данных (я же упоминал К*O(n), под этим всегда есть некая формула f(n1, n2, ...)), а стоимость в терминах низкоуровневых операциях практически не интересует. Интересует просто стоимость операции f при таких-то входных n. Т.к. оптимизатор оперирует относительными величинами, я называю эту стоимость "в попугаях".

S>Вы в ответ на мою первую возражаете моей же третьей, а потом внезапно обнаруживаете "противоречие". Рекомендую прекратить принимать то, что вы принимаете, что бы это ни было.

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

V>>Обоснуй в терминах реляционной модели, плиз. Давай, отноешния, аттрибуты, вывод незначимости аттрибута из-за наличия таких-то зависимостей. Давай уже заканчивать разводить пустые ля-ля, ближе к телу.
S>А куда ближе? Возьмём ваш собственный пример (надеюсь, с его пониманием у вас проблем не будет?):
S>

S>Простейший пример: есть некая схема R {ABCD}, и заданы зависимости A->B, B->CD. Для этой схемы будет уместна декомпозиция {AB, BCD}, причем, в реальной СУБД мы во втором отношении можем создать индекс B, сугубо эффективности ради, но! это будет означать лишь еще раз произвести декомпозицию по всем правилам декомпозиций с вводом специального аттрибута-ключа B#, для требований сохранения исходной зависимости B->CD транзитивно через B->B#, B#->CD. В итоге получим декомпозицию заданной схемы в виде: {AB, BB#, B#CD}.

S>Вот вы ввели отношение BB#. Зачем оно? Оно не привносит никакой новой информации. Потому что у нас B<->B#.

Угу, т.е. закончили сугубо риторическим вопросом? Так это было возражение или просьба объяснить? ХЗ, что ты хотел этим показать... Встречный вопрос: для чего вообще существуют нормальные формы (аж пять популярных штук)? Ведь с т.з. реляционой теории декомозированная схема отношения абсолютно эквивалентна исходной? Это собственно то, отчего уже тяжко обсуждать сей предмет, бо ответы написаны во всех учебниках: исключительно ради эффективности реализации хранилища, более незачем. Вот тебе переход от теории к реализации, от заданной изначально недекомпозированной схемы к конкретной декомпозированной. И устройство индексов не исключение. Я думаю, что вместо риторических вопросов стоило проявить немного воображения, представить себя разработчиком СУБД. Характер значений B# должен быть таким, чтобы получать "остаток" отношения CD по B# за O(1). Это не обязательно хеш-таблица, это может быть какой-нить числовой адрес, даже многомерный, все-равно будет O(1).

Кстати, просматривая гугл по теме наткнулся на статью относительно индексов:

Кластерный индекс использует row locator и он является частью не кластерного индекса на leaf level. Этот факт приводит к важному правилу SQL Server: создавайте кластерные ключи как можно более короткими. Каждый некластерный индекс будет использовать значения кластерного индекса. Следовательно увеличение размера кластерного индекса приводит к многократному увеличению требований по памяти для всех не кластерных индексов. Последнее приводит к увеличению времени на процессы чтения, сканирования данных и, как следствие, к снижению общей производительности системы. Еще одно наблюдение – увеличение длины ключа приводит к снижению количества записей индекса, способных уместиться в пределах одной страницы, как следствие – к увеличению операций чтения-записи.

Полностью совпадает с моими наблюдениями, и никак не коррелирует с "превосходством кластерного индекса" в твоем видении происходящего. Рекомендацию относительно того, как правильно готовить кластерные индексы, я дал.. ключевое только размер данных таблицы, в которой определен кластерный индекс. Насчет блобов (чтобы уже поставить точку), они именно затем и не хранятся вместе с остальными данными таблицы, чтобы обеспечить адекватную работу технологии кластерных индексов. Которые таки отлично подходят для относительно небольших объемов данных. В общем, вот что я имел ввиду, говоря, что блобы в MS SQL еще как при чем относительно этой темы про индексы.

V>>Ну это ход конем, конечно, в реализации программы "оставаться в рамках неё"... Ничего, что у меня целые числа ограниченной разрядности, для начала?
S>Ну, вообще говоря, это надо учитывать. А вы не знали? Соотношения, справедливые для "абстрактной арифметики целых чисел" могут запросто потерять справедливость для "арифметики чисел по модулю 2^32". Если вам это не очевидно, то не стесняйтесь спрашивать.

Ну ок, надо было сразу перейти на простой и понятный обмен шпильками. Фигли нам...
Здесь я напомнил кое-что, хотя никто не потрудился обратить внимание, на что намекали... зато могу и впредь спрашивать? Как незамысловато протекает беседа... Ладно, давай завязывать, на что не лень здесь еще отвечу, бо ты уже потратил прилично времени, но потом не обещаю... Конкретно числа в компьютере были напоминанием обыденности ситуации неполного соответствия реализации и модели. Но это нам не мешает использовать матаппарат, до тех пор, пока мы будем находится в области ограничений реализации.


V>>По кластерному не всегда, зависит от размеров таблицы. При достаточно "широкой" таблице в несколько раз менее эффективен, чем некластерный.
S>Теперь пошла в ход "ширина" таблицы. Вы мне лучше расскажите, при чём тут вмещаемость таблицы в оперативную память, которую вы упоминали в прошлый раз.

С самого начала упоминалась. Насчет памяти в силе, но объяснять облом. Лучше возьми какую-нить машинку с не очень большим объемом памяти, чтобы не заморачиваться со сверхобъемами, потсавь туда MS SQL и поэкспериментируй с кластерными индексами. Потом с некластерными. И все это с учетом того, что вынес некластерного индекса должен давать приличный профит в плане уменьшения физического объема сканируемых данных. Вот при чем тут "ширина" таблицы. Интересует ее ширина в байтах... Ну и помним, блобы в записях таблиц занимают 16 байт (по состоянию на MS SQL 2005), так что, относительную ширину можно организовать многим кол-вом полей. Как раз это характер таблиц справочных данных — 3-4 десятка полей, половина из них varchar(>80) — вполне себе подходящий вариант для некластерного индекса.


V>>От себя добавлю, что для подавляющего большинства обычных запросов, "без выкрутасов" конкретной СУБД, никакого расширения не требуется.
S>А я от себя добавлю, что нет, для подавляющего большинства обычных запросов, "без выкрутасов", и без конкретной СУБД, таки требуется расширение.

Это как ты упоминал повторяющиеся записи в результатах? Мне даже трудно представить ход рассуждения, зачем это надо, т.е. почему в этом месте не идет какая-нить group by, чтобы привести результат к каноническому, годному для РА? Если у вас таких "подавляющее большинство", нахрена вам вообще MS SQL? Вместо файловой системы, что ле? По опыту организация магазинов, складов, бухгалтерий и т.д. — не помню ни разу, чтобы мне нужны были данные, не попадающие в ограничения реляционной модели.


V>>Таки над конкретной БД, чаще всего не предоставляя всех ср-в по оперированию ей, при этом.
S>Да? А ISO SQL — он над какой конкретной БД?

Над никакой. Что, все СУБД реализуют стандарт SQL-92 целиком и не расширяют своими подробностями?

V>>При чем, далеко не во всех субд. Правила приведения этого домена к значению предиката указан в справочнике конкретной СУБД, но не в справочнике к стандарту SQL.
S>Вы сами-то стандарт читали? http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
S>Курить раздел 8 до просветления. Подробнейшим образом изложены формальные правила исчисления предикатов в SQL. И таки да, предикат возвращает одно из трёх значений. Никакого приведения к двоичной логике нет — оно у вас в голове.

Читал, давно и многократно. Давай конкретную фразу/абзац/не_важно_что, которые должны что-то такое доказать. И причем тут моя голова, есть т.н. boolean test, для строки с where(predicate) если предикат is null должно приниматься какое-то решение, и решение это должно быть двоичное: включать эту строку в результат или нет. Другого не дано. (Справедливости ради есть тонкости для right/left join, да и то не на всех базах). Конкретно в твоем примере boolen test предиката, который null, означает false.

S>Вы бредите. Никакой ошибки не выдаётся (если, конечно, СУБД соответствует стандарту).

А какая СУБД целиком поддерживает стандарт? (уже спрашивал)

S>Выдаётся результат, который не соответствует результату в РА.

Почему? Если значение выражения по домену {true, false, null} приводимо к boolean (например через boolean test), то проблема явно надуманна. Тем более, что есть стандарт, где это прописано... В общем, мимо.

S>Я вам показал, какие проблемы возникают в реляционной модели.

Это у тебя в голове они возникают, а не в модели. Действительный пример был с повторяющимися записями в результате, но мне уже интересно, а смысл в них без агрегации? А с агрегацией — вот уже результат соответствует обсуждаемой теме.


S>Совершенно верно. И большая часть реальных баз данных "не подчиняется в дальнейшем реляционной теории".

Ты хотел сказать "большая часть реальных баз данных поддерживает возможность создания/оперирования данных, не подчиняющихся реляционной теории"? Ну пусть поддерживает, может кому-то и надо... Я за полтора десятка лет работы с SQL во всевозможнейших БД, начиная с самых экзотических еще с середины 90-х, эти возможности не использовал ни разу. Наверно, от недостатка образования.

S>Обсуждение выросло из способности программиста отличать особенности конкретной СУБД от ISO SQL, а его — от реляционной модели.

Повторюсь для невнимательных: стоит ровно противоположная задача: искать соответствия в аспектах своей частности к некоей известной модели, дабы не изобретать велосипеды. Поэтому искать отличия не надо, они получаются сами: это подмножество функциональности, которая выходит за рамки такого соответствия. А уж рассуждать о "способностях" для таких основополагающих примитивов деятельности программиста — ну это низкопробнейший обмен шпильками, что еще сказать... лучше бы опять послал почитать что-нить, иногда люди бывает подкидывают любопытные ссылки...

V>>Красиво ты поспешил с выводами... ведь это смотря какой результат будет формирован в конце, зачастую ровно наоборот: distinc "где-то в середине" способен поднять эффективность многократно.
S>Я не поспешил, это вы спешите с интерпретацией. Мало ли что "зачастую". Вопрос в том — сколько будет случаев, где производительность просядет? Именно из-за них выбор, работать ли с множествами или с мультимножествами, отдан программисту. "Чистая" РМ оказалась нежизнеспособной на практике.

То, что тебе дали дополнительный инструмент, разве означает, что первоначальный не нужен? Просто у тебя теперь более одного инструмента (или один, но расширенный). И таки мне было бы интересно посмотреть на пример, где данные заведомо будут повторяющиеся в промежуточных результатах, когда исходные хотя бы в 3-й НФ, и distinct по этим промежуточным снизил бы производительность... Это надо голову поломать, такой пример придумать...

Гораздо легче его придумать для базы, не находящейся в НФ >=3. Но сценарии использовании СУБД вместо файловой системы я обсуждать все равно не буду, сорри.

V>>А реляционного исчисления? А всех наработок реляционной теории БД?
S>Всех теоретических наработок — достаточно. Я просто настаиваю на том, чтобы отделять мух от котлет.

Ну вот отделил ты операцию "фактор" от остальной РА, например. Поделишься ощущениями? Я помню эту операцию в связке с операциями РА, просто достаточно отмечать её особенность, почему не включили в РА.

V>>Э, нет. Ты мне о том, что эти комплексные числа нужно изобрести каждый раз заново, а я тебе — так вот же, учебник по вышке.
S>Где вы нашли у меня такое утверждение?

Это отрицание возможности применения наработок и опыта по РА для реализации некластерных индексов, например. Твоя позиция "здесь всё по-другому"... Да ради бога, но для очень многого таки можно не изобретать ни велосипедов, ни терминологию, ни изучать св-в операций и т.д., а брать готовое (ведь есть понятия эквивалентность операций и отношений, пока в рамках РА можно пользоваться готовым аппараттом, не разрабатывая "на коленке" свой). Мне такой подход кажется очень удобным для практической работы.


V>>Тогда для чего оно надо? (есть тут смайлик печальной улыбки?)
S>Как основа для более реальных теорий. Релятивистская механика точнее ньютоновской, но это не означает, что ньютоновскую не нужно изучать.

Блин, сам же даешь неплохие аналогии, и сам же против них споришь... В 99% случаев ньютоновской за глаза в обычной жизни. А если по какой-то частности не хватает ньютоновской, то берут релятивистскую, но только по этой частности. Так же проще.

V>>Можно я избавлю себя от поиска соответствия "последовательного алгоритма" и "императивного программирования"?
S>Нет, нельзя. Это же вы пытаетесь применять их как синонимы:

Я уже раз 10 уточнил с тех пор, и задал вопрос в начале, сравнив С и С++. Где там большая императивность? Или лишь бы "прищучить" пофиг на чем? По этой теме не выйдет.

S>Нет, это не позволяет такого утверждать. Поймите, в РА нет никаких "вычислений". Есть декларации того, как "выход" операции связан со "входом". РА не обязывает исполнителя реально "просматривать" кортежи при выполнении этих операций. РА не обязывает исполнителя формировать промежуточные результаты в сколь бы то ни было воспринимаемом виде. Понимаете?

А какое нам дело до промежуточных результатов? Разве я хоть раз настаивал хоть на одной подробности реализации? Тем паче, что их много.

S>Я имею право как угодно переупорядочивать операции, если семантика сохраняется.

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

Если ты имеешь ввиду, что одну и ту же формулу реляционного исчисления можно решить несколькими способами, то это будут именно что разные способы. У тебя будет не просто разный порядок неких операций, но обязательно разные сами аргументы в операциях РА и в общем случае (кроме вырожденных) будут получаться разные типы промежуточных отношений. Да, коль SQL близок к исчислению кортежей, то для удовлетворения запроса может быть составлено много вариантов решений в терминах РА. Вот здесь уже ты путаешь РА и РИ.

S>И есть даже специальные соотношения эквивалентности, которые помогают мне это делать.

На уровне РА отношения эквивалентности есть только у тех операций, которые выразимы через другие... Т.е. реально базис мог бы быть составлен не из 7-ми, а из 5-ти операций, но ты ведь не это имел ввиду, надеюсь, а вообще любые операции? Так вот, эквивалентность только через РИ и работает. А когда расписали задачу в терминах РА, то уже можно идти писать программу, от самый физический уровень. Собственно, инструмент РА был придуман для того, чтобы обслуживать РИ, а ты утверждаешь, что он нужен сам по себе. Сам по себе РА крайне неудобен, т.к. навскидку сложно сказать, что будет являться результатом некоей последовательности операций, поэтому всегда РА используют как механизм для перехода из декларативного описания в терминах РИ к алгоритму в терминах РА.

А все рассуждения о "промежуточных результатах" — это в пользу бедных. Курсоры, итераторы и ленивость — чем не промежуточный результат? Это именно классика работы БД, бо они именно для такого сценария и были придуманы, т.е. для работы на очень ограниченном объеме оперативной памяти, в сравнении с объемом обрабатываемых данных. Сдается мне, что пытаясь рассуждать о промежуточных результатах, ты опять пытаешься мне что-то приписать. ИМХО, лучше напрямую спросить мое мнение, чем спорить с не моим в ответе мне.

Здравствуйте, gandjustas, Вы писали:

G>И дело даже не в том что люди умеют или не умеют оптимизировать, а в том что некоторые вместо инженерного подхода используют "шаманский", а потом сильно бравируют этим.

Нет никакого шаманства, ровно наоборот: сухое применение наработок, полученных в аналогичных условиях. В любом случае, все оптимизации идут под присмотром тестов на производительность (как минимум), я лишь сказал, что практически в 100% эти места видны и без профайлеров. Например, целиком алгоритм по ссылке. Читая по диагонали было видно, что генерируются всевозможные комбинации из букв, включая ?, затем полученное сравнивается со всем словарем. Как конкретно сравнивается — уже не важно, сам такой алгоритм уже не пойдет, о чем тут же и сказал.

Здравствуйте, vdimas, Вы писали:

V>Второй вариант уже перестал быть императивной последовательностью вычислений или еще нет?
Вариант — да. Язык — нет, т.к. он позволяет делать и другие "варианты".

V>Для принятия решений оптимизатором достаточно некоей формулы от неких характеристик данных (я же упоминал К*O(n), под этим всегда есть некая формула f(n1, n2, ...)), а стоимость в терминах низкоуровневых операциях практически не интересует.
Ок, хорошо.

V>Там уже было поскипано столько контекстов, что в другой раз желательно восстановить его целиком, чтобы я мог раскрыть рассуждения, т.е. дабы не вызвать такой реакции непонимания.
Вы просто читайте текст подряд и понимайте головой.
V>Угу, т.е. закончили сугубо риторическим вопросом? Так это было возражение или просьба объяснить? ХЗ, что ты хотел этим показать... Встречный вопрос: для чего вообще существуют нормальные формы (аж пять популярных штук)? Ведь с т.з. реляционой теории декомозированная схема отношения абсолютно эквивалентна исходной? Это собственно то, отчего уже тяжко обсуждать сей предмет, бо ответы написаны во всех учебниках: исключительно ради эффективности реализации хранилища, более незачем.

V>Полностью совпадает с моими наблюдениями, и никак не коррелирует с "превосходством кластерного индекса" в твоем видении происходящего.
Ну как это "не коррелирует". Цитирую:

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

V>Рекомендацию относительно того, как правильно готовить кластерные индексы, я дал.. ключевое только размер данных таблицы, в которой определен кластерный индекс.
Эта рекомендация — полный бред. Размер данных таблицы не играет никакой роли. Вы не понимаете разницы между размером ключа и размером таблицы, что бы вы этим "размером" ни называли? В прошлый раз вы упоминали, что таблица для кластерного индекса должна целиком влезать в ОП — это полный бред. Не должна. Сейчас, вроде бы, подразумеваете, что "размер таблицы" — это размер одного кортежа. Тоже мимо тазика — размер ключа кластерного индекса определяется независимо от размера индексируемых кортежей.

V>Насчет блобов (чтобы уже поставить точку), они именно затем и не хранятся вместе с остальными данными таблицы, чтобы обеспечить адекватную работу технологии кластерных индексов.
Вы по-прежнему бредите. Кластерным индексам всё равно, есть в таблице блобы, и где они хранятся.
V>Которые таки отлично подходят для относительно небольших объемов данных. В общем, вот что я имел ввиду, говоря, что блобы в MS SQL еще как при чем относительно этой темы про индексы.
У вас какое-то радикально неправильное понимание устройства кластерных индексов. Может, вам на примере объяснить?
Вот вам таблица

create table Person)
  id int identity primary key,
  passportNumber char(10) not null constraint passportNumber unique,
  firstName varchar(max) not null,
  lastName  varchar(max) not null,
  birthdate datetime not null,
  picture varbinary(max), 
  // ещё поля на 4 килобайта
)

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

V>Здесь я напомнил кое-что, хотя никто не потрудился обратить внимание, на что намекали... зато могу и впредь спрашивать? Как незамысловато протекает беседа... Ладно, давай завязывать, на что не лень здесь еще отвечу, бо ты уже потратил прилично времени, но потом не обещаю... Конкретно числа в компьютере были напоминанием обыденности ситуации неполного соответствия реализации и модели. Но это нам не мешает использовать матаппарат, до тех пор, пока мы будем находится в области ограничений реализации.
Ключевое выделено. У вас, к примеру, понимание области ограничений весьма размыто. Это видно по непониманию, скажем, отличия трёхзначной логики от двузначной, и от последствий этого.

V>С самого начала упоминалась. Насчет памяти в силе, но объяснять облом. Лучше возьми какую-нить машинку с не очень большим объемом памяти, чтобы не заморачиваться со сверхобъемами, потсавь туда MS SQL и поэкспериментируй с кластерными индексами. Потом с некластерными.
В ответ рекомендую открыть SQL Books Online и погрузиться в описание архитектуры кластерных индексов. Я кагбэ все эти вещи на пузе исползал крайне подробно — в том числе и базы больше размера ОП, и прочее.

V>И все это с учетом того, что вынес некластерного индекса должен давать приличный профит в плане уменьшения физического объема сканируемых данных.
Откуда возьмётся уменьшение физического объёма сканируемых данных? Вы вообще понимаете, как работают индексы?

Вот при чем тут "ширина" таблицы. Интересует ее ширина в байтах... Ну и помним, блобы в записях таблиц занимают 16 байт (по состоянию на MS SQL 2005), так что, относительную ширину можно организовать многим кол-вом полей. Как раз это характер таблиц справочных данных — 3-4 десятка полей, половина из них varchar(>80) — вполне себе подходящий вариант для некластерного индекса.
Да и для кластерного тоже — самое оно. Вы в качестве ключа для индекса что предполагаете выбирать?

V>Это как ты упоминал повторяющиеся записи в результатах? Мне даже трудно представить ход рассуждения, зачем это надо, т.е. почему в этом месте не идет какая-нить group by, чтобы привести результат к каноническому, годному для РА?
Потому что на практике каноничность не интересна. Откройте произвольное приложение, которое работает с базой данных, и поищите, сколько раз встречается select, а сколько раз distinct. Это даст вам примерное представление о доле "РА-совместимых" запросов в типичном SQL.
V>Если у вас таких "подавляющее большинство", нахрена вам вообще MS SQL? Вместо файловой системы, что ле? По опыту организация магазинов, складов, бухгалтерий и т.д. — не помню ни разу, чтобы мне нужны были данные, не попадающие в ограничения реляционной модели.
Это у вас оттого, что вы никогда не задумывались о том, что конкретно подразумевается под "ограничениями реляционной модели".

V>Над никакой. Что, все СУБД реализуют стандарт SQL-92 целиком и не расширяют своими подробностями?
Наоборот. Об этом я и говорю — есть уровень "ISO SQL" (в котором, к слову, даже индексов нет), а есть — уровень "конкретной субд".
V>>>При чем, далеко не во всех субд. Правила приведения этого домена к значению предиката указан в справочнике конкретной СУБД, но не в справочнике к стандарту SQL.
S>>Вы сами-то стандарт читали? http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
S>>Курить раздел 8 до просветления. Подробнейшим образом изложены формальные правила исчисления предикатов в SQL. И таки да, предикат возвращает одно из трёх значений. Никакого приведения к двоичной логике нет — оно у вас в голове.

V>Читал, давно и многократно. Давай конкретную фразу/абзац/не_важно_что, которые должны что-то такое доказать.

8.1  <predicate>

         Function

         Specify a condition that can be evaluated to give a truth value of
         true, false, or unknown.

V>И причем тут моя голова, есть т.н. boolean test, для строки с where(predicate) если предикат is null должно приниматься какое-то решение, и решение это должно быть двоичное: включать эту строку в результат или нет. Другого не дано.
И опять мы посмотрим в стандарт:

7.6  <where clause>

         Function

         Specify a table derived by the application of a <search condition>
         to the result of the preceding <from clause>.

         Format

         <where clause> ::= WHERE <search condition>
...
 General Rules

         1) The <search condition> is applied to each row of T. The result
            of the <where clause> is a table of those rows of T for which
            the result of the <search condition> is true.

и далее:

8.12  <search condition>

         Function

         Specify a condition that has the truth value true, false, or
         unknown, depending on the result of applying boolean operators
         to specified conditions.

V>(Справедливости ради есть тонкости для right/left join, да и то не на всех базах). Конкретно в твоем примере boolen test предиката, который null, означает false.
Нет. прочитайте стандарт. Если бы в этом случае "булевый тест" предиката означал false (а стандарт требует вовсе не этого), то NOT() от этого предиката означал бы true. Это называется "закон исключённого третьего", и он не работает в трёхзначной логике.

V>А какая СУБД целиком поддерживает стандарт? (уже спрашивал)
Зачем целиком? Достаточно поддерживать основные положения. Скажем, в трактовке NULL-ов у MS SQL даже есть опция SET ANSI_NULLS.

S>>Выдаётся результат, который не соответствует результату в РА.
V>Почему? Если значение выражения по домену {true, false, null} приводимо к boolean (например через boolean test), то проблема явно надуманна. Тем более, что есть стандарт, где это прописано... В общем, мимо.
Что "почему"? Почему результат не соответствует результату в РА? Потому что в РА должно вернуться три кортежа, а в SQL — два. Найдите одно различие.

V>Это у тебя в голове они возникают, а не в модели. Действительный пример был с повторяющимися записями в результате, но мне уже интересно, а смысл в них без агрегации? А с агрегацией — вот уже результат соответствует обсуждаемой теме.
Я начинаю уставать ходить по кругу. Смысл — в повышении производительности. Если бы этого не было, то никто бы не стал заморачиваться поддержкой мультисетов, и в стандарт бы сразу запихали принудительную агрегацию всех промежуточных результатов.

V>Ты хотел сказать "большая часть реальных баз данных поддерживает возможность создания/оперирования данных, не подчиняющихся реляционной теории"? Ну пусть поддерживает, может кому-то и надо... Я за полтора десятка лет работы с SQL во всевозможнейших БД, начиная с самых экзотических еще с середины 90-х, эти возможности не использовал ни разу. Наверно, от недостатка образования.
Вы эти возможности использовали постоянно. Просто в силу особенностей мышления (с обсуждения которых и начался этот тред) вы так и не осознали, где вы выходили за границы реляционной модели.

V>Повторюсь для невнимательных: стоит ровно противоположная задача: искать соответствия в аспектах своей частности к некоей известной модели, дабы не изобретать велосипеды.
Чтобы искать соответствия, нужно сначала овладеть навыками анализа, т.е. разложения комплексных понятий на элементарные "запчасти".
Потом уже можно искать соответствия между этими "запчастями" и "запчастями" из других моделей, а также заниматься "синтезом" — сборкой комплексных понятий из полученных "запчастей".

V>Поэтому искать отличия не надо, они получаются сами: это подмножество функциональности, которая выходит за рамки такого соответствия.
Для начала нужно вообще иметь понятие о том, что есть рамки такого соответствия. Я уже почти неделю объясняю вам рамки соответствия реальных промышленных СУБД чистой реляционной модели — и несмотря на предположительное наличие у вас опыта и в теории, и на практике, дело идёт со скрипом. Даже когда я вам эти рамки сую под нос в детальных примерах и цитатах, они оказываются трудновоспринимаемыми. А вы говорите — "получаются сами".

V>А уж рассуждать о "способностях" для таких основополагающих примитивов деятельности программиста — ну это низкопробнейший обмен шпильками, что еще сказать... лучше бы опять послал почитать что-нить, иногда люди бывает подкидывают любопытные ссылки...
Да без проблем: http://wikipedia.org
Ещё рекомендую в гугле делать поиск с define: — это каждый раз, когда вам хочется придумать новый термин.

V>То, что тебе дали дополнительный инструмент, разве означает, что первоначальный не нужен?
Я не говорю, что он не нужен. Вы спорите сами с собой. Я говорю о том, что существует разница между реляционной моделью у Кодда, расширенной реляционной моделью, и моделью устройства реальной промышленной СУБД.

V>Просто у тебя теперь более одного инструмента (или один, но расширенный). И таки мне было бы интересно посмотреть на пример, где данные заведомо будут повторяющиеся в промежуточных результатах, когда исходные хотя бы в 3-й НФ, и distinct по этим промежуточным снизил бы производительность... Это надо голову поломать, такой пример придумать...
Да что тут ломать-то? Независимо от НФ, любая проекция, не включающая в себя primary key, сразу даст вам потенциальные повторы. Дистинкт по этим данным конечно же снизит производительность — потому что это group by со всеми вытекающими. В частности, нельзя использовать стриминг и резко возрастает потребность в буферах для промежуточных результатов. При низком коэффициенте повторяемости гораздо эффективнее отложить этот group by до момента, когда он реально нужен.

V>Ну вот отделил ты операцию "фактор" от остальной РА, например. Поделишься ощущениями?
Прекрасные ощущения, а что?

V>Это отрицание возможности применения наработок и опыта по РА для реализации некластерных индексов, например.
Какие именно наработки РА вы хотите применить для реализации некластерных индексов?

V>Блин, сам же даешь неплохие аналогии, и сам же против них споришь... В 99% случаев ньютоновской за глаза в обычной жизни. А если по какой-то частности не хватает ньютоновской, то берут релятивистскую, но только по этой частности. Так же проще.
Не "по какой-то частности", а "для какой-то задачи". И если в задаче нужна релятивистская механика, то будь любезен всю её решать в ней. А не так, что, скажем, скорости ты считаешь релятивистски, а время принимаешь ньютоновским.

V>Я уже раз 10 уточнил с тех пор, и задал вопрос в начале, сравнив С и С++.
Не вижу никакого уточнения. Или вы там в оффлайне уточняли?
V>Где там большая императивность? Или лишь бы "прищучить" пофиг на чем? По этой теме не выйдет.
Да у вас куда ни ткни — везде непонимание и заблуждения.

V>А какое нам дело до промежуточных результатов? Разве я хоть раз настаивал хоть на одной подробности реализации? Тем паче, что их много.
Как какое? Вы же сами пишете, что результат операции зависит от результатов других операций. Это и есть промежуточные результаты, как бы по определению.

S>>Я имею право как угодно переупорядочивать операции, если семантика сохраняется.
V>Не можешь!
ОМГ. Ну откуда, откуда это упорство в заблуждениях? http://en.wikipedia.org/wiki/Relational_algebra#Use_of_algebraic_properties_for_query_optimization
Прочтите весь раздел. Если в нём что-то непонятно, задайте дополнительные вопросы.

S>>И есть даже специальные соотношения эквивалентности, которые помогают мне это делать.
V>На уровне РА отношения эквивалентности есть только у тех операций, которые выразимы через другие...
Повторюсь:
http://en.wikipedia.org/wiki/Relational_algebra#Use_of_algebraic_properties_for_query_optimization

Здравствуйте, DarkGray, Вы писали:

DG>как только в выделенном найдешь (или в другом месте текста про identity), что change объекта не имеет права создавать новые копии
объекта, тогда продолжим разговор.
Это, простите, чушь. change объекта и создание нового объекта — разные вещи. Они не являются взаимоисключающими, но в вашем примере никакого change нету. Есть только создание новых объектов.

S>Это, простите, чушь. change объекта и создание нового объекта — разные вещи. Они не являются взаимоисключающими, но в вашем примере никакого change нету. Есть только создание новых объектов.

ты постоянно скатываешься в область веры, и не можешь обосновать свои утверждения — это грустно...

Здравствуйте, DarkGray, Вы писали:
DG>ты постоянно скатываешься в область веры, и не можешь обосновать свои утверждения — это грустно...
При чём тут вера? Вы всерьёз полагаете, что в поведение класса string в нужноверить?
Ну так я вас разочарую — нет, не нужно. Он уже ведёт себя вполне определённым образом.

DG>>ты постоянно скатываешься в область веры, и не можешь обосновать свои утверждения — это грустно...
S>При чём тут вера?

каждый твой довод основан на вере. ты говоришь "я верю, что это не ООП".

вообще, в познании мира выделяют три этапа:
1. шаманский
2. религиозный
3. научный.

на уровне шамана "правильно — не правильно" определяется на основе традиций, если так делали — значит правильно, если так не делали — значит не правильно.
на уровне последователя/жреца "правильно — не правильно" определяется на основе писания. Правильно то, что записано в Единство Правильной Книжке, или что говорил Единственно Правильный Авторитет; всё остальное — не правильно.
на уровне научного подхода "правильно — не правильно" определяется на основе формулирования остенсивных терминов и логического вывода следствий. правильно — если выводится, неправильно — если не выводится.

твое понимание программирования где-то между шаманским и религиозным: между "я так делал всегда и это есть правильно" и "так написано в Великом Писании ООП, поэтому это есть правильно".

Здравствуйте, DarkGray, Вы писали:

DG>>>ты постоянно скатываешься в область веры, и не можешь обосновать свои утверждения — это грустно...
S>>При чём тут вера?

DG>каждый твой довод основан на вере. ты говоришь "я верю, что это не ООП".

DG>вообще, в познании мира выделяют три этапа:
DG>1. шаманский
DG>2. религиозный
DG>3. научный.

DG>на уровне шамана "правильно — не правильно" определяется на основе традиций, если так делали — значит правильно, если так не делали — значит не правильно.
DG>на уровне последователя/жреца "правильно — не правильно" определяется на основе писания. Правильно то, что записано в Единство Правильной Книжке, или что говорил Единственно Правильный Авторитет; всё остальное — не правильно.
DG>на уровне научного подхода "правильно — не правильно" определяется на основе формулирования остенсивных терминов и логического вывода следствий. правильно — если выводится, неправильно — если не выводится.
Есть еще один этап, околонаучно-фантастический.

Кажется что это тянется отсюда

Автор: DarkGray
Дата: 09.12.11

.
Можно увидеть логический вывод того, что в коде

string y = "2";
Console.WriteLine(Object.ReferenceEquals(y, y));
Console.WriteLine(Object.ReferenceEquals(y + "1", y + "1"));

Происходит изменение объекта?

DG>твое понимание программирования где-то между шаманским и религиозным: между "я так делал всегда и это есть правильно" и "так написано в Великом Писании ООП, поэтому это есть правильно".

S>Есть еще один этап, околонаучно-фантастический.

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

S>Можно увидеть логический вывод того, что в коде
S>

S>string y = "2";
S>Console.WriteLine(Object.ReferenceEquals(y, y));
S>Console.WriteLine(Object.ReferenceEquals(y + "1", y + "1"));
S>

S>Происходит изменение объекта?

при следующих определениях:
состояние рассматривается только между строками
сигнатуры функции '+' рассматривается как: измененный_объект_x := объект_x + изменение, объект_х в следующий момент после '+' рассматривается как старая версия объекта_х
строка с одним и тем значением рассматривается как один и тот же объект

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

Здравствуйте, DarkGray, Вы писали:

DG>твое понимание программирования где-то между шаманским и религиозным: между "я так делал всегда и это есть правильно" и "так написано в Великом Писании ООП, поэтому это есть правильно".
Спасибо за подробный анализ устройства моего понимания программирования. К сожалению, он основан на заблуждениях.
Разубеждать вас я не собираюсь, т.к. не вижу смысла приводить какие-либо аргументы человеку, который то требует от меня доказать аксиому, то путает непрерывное отображение с непрерывным множеством.

Здравствуйте, DarkGray, Вы писали:

S>>Есть еще один этап, околонаучно-фантастический.

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

S>>Можно увидеть логический вывод того, что в коде
S>>

S>>string y = "2";
S>>Console.WriteLine(Object.ReferenceEquals(y, y));
S>>Console.WriteLine(Object.ReferenceEquals(y + "1", y + "1"));
S>>

S>>Происходит изменение объекта?

DG>при следующих определениях:
Что общего у этих определений с ООП, кроме слова "объект"?

DG>состояние рассматривается только между строками
Внутри строки оно неопределено? Какое отношение между строками и состоянием?

DG>сигнатуры функции '+' рассматривается как: измененный_объект_x := объект_x + изменение, объект_х в следующий момент после '+' рассматривается как старая версия объекта_х
Что такое версия, и чем она отличается от объекта?
Согласно этому определению функции '+' над строками, порождение чего-то таки случилось, т.к. после этой операции есть "измененный объект" и "старая версия". Идентичность указывает именно на то, что "старая версия" не была порождена в процессе такого изменения и сохранила свою идентичность с момента до изменения. Ты можешь рассматривать операцию "+" как угодно, но это не отменит того, что она что-то породила, и что-то оставила неизменным. Можешь называть порожденную сущность измененным объектом, если это обеспечивает тебе интересное времяпровождение в терминологических спорах. Замечу только, что изменение в ООП сохраняет идентичность измененного объекта.

DG>строка с одним и тем значением рассматривается как один и тот же объект
И это тоже определение? Чем строка отличается от например StringBuilder-а, что для нее особенное определение вводится?

DG>тогда между второй и третьей строкой происходит изменение объекта
DG>на окончании третьей строки есть один объект со значением "21", две ссылки на него, и старая версия объекта со значением "2".
Опираясь на вышеописанные определения, я бы предположил что изменений происходит 2. Сначала изменяется объект y, а потом изменяется старая версия y

Я не удовлетворен таким логическим выводом, т.к. он исходит из сомнительных определений, введенных ради самого вывода.

DG>>при следующих определениях:
S>Что общего у этих определений с ООП, кроме слова "объект"?

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

DG>>состояние рассматривается только между строками
S>Внутри строки оно неопределено? Какое отношение между строками и состоянием?

в данном случае, используется принцип инкапсуляции: строка рассматривается как черный ящик, и поведение строки фиксируется только на входе и выходе. с этой точки зрения, поведение внутри строки для наблюдателя неопределено.

DG>>сигнатуры функции '+' рассматривается как: измененный_объект_x := объект_x + изменение, объект_х в следующий момент после '+' рассматривается как старая версия объекта_х
S>Что такое версия, и чем она отличается от объекта?

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

S>Согласно этому определению функции '+' над строками, порождение чего-то таки случилось, т.к. после этой операции есть "измененный объект" и "старая версия". Идентичность указывает именно на то, что "старая версия" не была порождена в процессе такого изменения и сохранила свою идентичность с момента до изменения. Ты можешь рассматривать операцию "+" как угодно, но это не отменит того, что она что-то породила, и что-то оставила неизменным. Можешь называть порожденную сущность измененным объектом, если это обеспечивает тебе интересное времяпровождение в терминологических спорах. Замечу только, что изменение в ООП сохраняет идентичность измененного объекта.

софистика, или по русски словоблудие — из разряда "есть ли пуп у адама или нет?", данное занятия очень было распространено среди религиозных деятелей (и ты сейчас от них ни чем не отличаешься).
ты играешься словами, но при этом ты ни для одного слова не дал определения.

как только ты определишь понятия, все эти словеса рассыплятся в прах.
например, одна из формализаций термина "порождение": при рассмотрении двух моментов времени t и t1 порождением называется появление объекта в момент t1 с новым identity, которого не было в момент t.
при этом если функция "+" определена как указано выше, то появления нового identity нет, а значит и нет порождения.


DG>>строка с одним и тем значением рассматривается как один и тот же объект
S>И это тоже определение? Чем строка отличается от например StringBuilder-а, что для нее особенное определение вводится?

DG>>тогда между второй и третьей строкой происходит изменение объекта
DG>>на окончании третьей строки есть один объект со значением "21", две ссылки на него, и старая версия объекта со значением "2".
S>Опираясь на вышеописанные определения, я бы предположил что изменений происходит 2. Сначала изменяется объект y, а потом изменяется старая версия y

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

S>Я не удовлетворен таким логическим выводом, т.к. он исходит из сомнительных определений, введенных ради самого вывода.

у тебя есть сомнение. отлично! это значит ты пытаешься думать. Формализуй свое сомнение, введя термины и логическими выводами показав противоречие — тогда ты реально начнешь думать.

Здравствуйте, DarkGray, Вы писали:


DG>>>при следующих определениях:
S>>Что общего у этих определений с ООП, кроме слова "объект"?

DG>то что при этом сохраняются все следствия, которые сделаны в ООП. или другими словами — система построенная на этих определениях эквивалента системе рассматриваемой в рамках ООП
С идентичностью тут явный бардак.

DG>>>состояние рассматривается только между строками
S>>Внутри строки оно неопределено? Какое отношение между строками и состоянием?

DG>в данном случае, используется принцип инкапсуляции: строка рассматривается как черный ящик, и поведение строки фиксируется только на входе и выходе. с этой точки зрения, поведение внутри строки для наблюдателя неопределено.
Интересно, а для чего это не так?

DG>>>сигнатуры функции '+' рассматривается как: измененный_объект_x := объект_x + изменение, объект_х в следующий момент после '+' рассматривается как старая версия объекта_х
S>>Что такое версия, и чем она отличается от объекта?

DG>это состояние объекта в прошлом.
DG>используется на чтение для получения информации, какое состояние объекта было в прошлом.
DG>из всех версий объекта актуальной считается только последняя, и соответственно именно она образует реальный объект в настоящем, к которому применяются изменения.
Как может быть определена актуальность версии? Что из этого актуальнее, y1 или y2?

string y1 = y + "1";
string y2 = y + "2";

S>>Согласно этому определению функции '+' над строками, порождение чего-то таки случилось, т.к. после этой операции есть "измененный объект" и "старая версия". Идентичность указывает именно на то, что "старая версия" не была порождена в процессе такого изменения и сохранила свою идентичность с момента до изменения. Ты можешь рассматривать операцию "+" как угодно, но это не отменит того, что она что-то породила, и что-то оставила неизменным. Можешь называть порожденную сущность измененным объектом, если это обеспечивает тебе интересное времяпровождение в терминологических спорах. Замечу только, что изменение в ООП сохраняет идентичность измененного объекта.

DG>софистика, или по русски словоблудие — из разряда "есть ли пуп у адама или нет?", данное занятия очень было распространено среди религиозных деятелей (и ты сейчас от них ни чем не отличаешься).
DG>ты играешься словами, но при этом ты ни для одного слова не дал определения.
Я не даю определения тем вещам, которым они уже даны не мной.

DG>как только ты определишь понятия, все эти словеса рассыплятся в прах.
DG>например, одна из формализаций термина "порождение": при рассмотрении двух моментов времени t и t1 порождением называется появление объекта в момент t1 с новым identity, которого не было в момент t.
DG>при этом если функция "+" определена как указано выше, то появления нового identity нет, а значит и нет порождения.
Т.е. ты утверждаешь что у объектов y и (y + "1") same identity? Как ты отличишьь этот объект от (y + "2"), не зная, какая операция была выполнена вперед?
Если у тебя объект и версия имеют одну идентичность, то почему они различаются по значениям в один и тот же момент времени? Это противоречит определению идентичности.

DG>>>строка с одним и тем значением рассматривается как один и тот же объект
S>>И это тоже определение? Чем строка отличается от например StringBuilder-а, что для нее особенное определение вводится?
Ты не объяснил обособленность строки в твоей системе определений

DG>>>тогда между второй и третьей строкой происходит изменение объекта
DG>>>на окончании третьей строки есть один объект со значением "21", две ссылки на него, и старая версия объекта со значением "2".
S>>Опираясь на вышеописанные определения, я бы предположил что изменений происходит 2. Сначала изменяется объект y, а потом изменяется старая версия y

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

S>>Я не удовлетворен таким логическим выводом, т.к. он исходит из сомнительных определений, введенных ради самого вывода.

DG>у тебя есть сомнение. отлично! это значит ты пытаешься думать. Формализуй свое сомнение, введя термины и логическими выводами показав противоречие — тогда ты реально начнешь думать.
У меня нет сомнений. Я вижу что твои определения и примеры несовместимы с традиционным ООП.

DG>>в данном случае, используется принцип инкапсуляции: строка рассматривается как черный ящик, и поведение строки фиксируется только на входе и выходе. с этой точки зрения, поведение внутри строки для наблюдателя неопределено.
S>Интересно, а для чего это не так?

например, с точки зрения конкретного компилятора поведение внутри строки строго определенно, что куда и как преобразуется.

S>Как может быть определена актуальность версии? Что из этого актуальнее, y1 или y2?
S>

S>string y1 = y + "1";
S>string y2 = y + "2";
S>

на основе лишь этого куска все следующие рассмотрения будут верными:
y, y1, y2 — три разных объекта
y, y1 — один объект, y2 — другой объект
y, y2 — один объект, y1 — другой объект
y, y1, y2 — один и тот же объект, y1 и y2 — две разные ссылки на один и тот же объект

S>Я не даю определения тем вещам, которым они уже даны не мной.

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

DG>>как только ты определишь понятия, все эти словеса рассыплятся в прах.
DG>>например, одна из формализаций термина "порождение": при рассмотрении двух моментов времени t и t1 порождением называется появление объекта в момент t1 с новым identity, которого не было в момент t.
DG>>при этом если функция "+" определена как указано выше, то появления нового identity нет, а значит и нет порождения.
S>Т.е. ты утверждаешь что у объектов y и (y + "1") same identity? Как ты отличишьь этот объект от (y + "2"), не зная, какая операция была выполнена вперед?
S>Если у тебя объект и версия имеют одну идентичность, то почему они различаются по значениям в один и тот же момент времени? Это противоречит определению идентичности.

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

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


DG>>>>строка с одним и тем значением рассматривается как один и тот же объект
S>>>И это тоже определение? Чем строка отличается от например StringBuilder-а, что для нее особенное определение вводится?
S>Ты не объяснил обособленность строки в твоей системе определений

потому что string использует immutable-версионность (а не backup-версионность), в отличии от stringbuilder-а

S>У меня нет сомнений. Я вижу что твои определения и примеры несовместимы с традиционным ООП.

опять религиозный догматический вывод. для полного образа тебе еще не хватает криков "сжечь еретика на костре!.

Здравствуйте, DarkGray, Вы писали:


DG>>>в данном случае, используется принцип инкапсуляции: строка рассматривается как черный ящик, и поведение строки фиксируется только на входе и выходе. с этой точки зрения, поведение внутри строки для наблюдателя неопределено.
S>>Интересно, а для чего это не так?

DG>например, с точки зрения конкретного компилятора поведение внутри строки строго определенно, что куда и как преобразуется.

S>>Как может быть определена актуальность версии? Что из этого актуальнее, y1 или y2?
S>>

S>>string y1 = y + "1";
S>>string y2 = y + "2";
S>>

DG>на основе лишь этого куска все следующие рассмотрения будут верными:
DG>y, y1, y2 — три разных объекта
DG>y, y1 — один объект, y2 — другой объект
DG>y, y2 — один объект, y1 — другой объект
DG>y, y1, y2 — один и тот же объект, y1 и y2 — две разные ссылки на один и тот же объект
Можно продолжить, что всевозможные строки это один объект, т.к. могут быть получены из пустой строки путем добавления значения, равного заданной строке.

S>>Я не даю определения тем вещам, которым они уже даны не мной.

DG>в мире для одного и того же слова, есть сотни, а то и тысячи определений с разным уровнем точности, соответственно как минимум ты обязан зафиксировать какое именно определение используешь и на каком уровне точности.
Тут разве не было ссылки на определение ООП идентичности ?

S>>Т.е. ты утверждаешь что у объектов y и (y + "1") same identity? Как ты отличишьь этот объект от (y + "2"), не зная, какая операция была выполнена вперед?
S>>Если у тебя объект и версия имеют одну идентичность, то почему они различаются по значениям в один и тот же момент времени? Это противоречит определению идентичности.

DG>опять же как только выписываются все определения, то выясняется что никакого противоречия нет.
Никакого противоречия тому что всевозможные строки идентичны?
DG>здесь есть две плоскости (две модели) — версионная и не версионная.
DG>с точки зрения модели, которая не знает что такое версионность — функция идентичности считает объект одним и тем же, если совпадает идентичность объекта(из модели версионной) и версия объекта(из модели версионной), при этом эта модель считает две версии объекта совершенно разными объектами, которые никак между собой не связаны, что неудобно при рассмотрении многих сценариев.
Ты уже приводил определение идентичности версионной модели?

>> Если у тебя объект и версия имеют одну идентичность, то почему они различаются по значениям в один и тот же момент времени?
DG>соответственно, с точки зрения неверсионной модели никакого противоречия нет, потому что объекты разные.
DG>с точки зрения версионной модели противоречия тоже нет, потому что версионная модель допускает иметь одному и тому же объекту разные состояния для случая, когда это есть предыдущие состояния этого же объекта.
А ты можешь ответить на вопрос, является ли объект предыдущим состоянием некого объекта, или это самостоятельный объект?

DG>>>>>строка с одним и тем значением рассматривается как один и тот же объект
S>>>>И это тоже определение? Чем строка отличается от например StringBuilder-а, что для нее особенное определение вводится?
S>>Ты не объяснил обособленность строки в твоей системе определений

DG>потому что string использует immutable-версионность (а не backup-версионность), в отличии от stringbuilder-а
Это значит что никогда не ясно, является ли string объектом, или неактуальной версией какого-то объекта?

S>>У меня нет сомнений. Я вижу что твои определения и примеры несовместимы с традиционным ООП.

DG>опять религиозный догматический вывод. для полного образа тебе еще не хватает криков "сжечь еретика на костре!.
Почему догматический? Идентичность строк с одним значением + сохранение идентичности при операции "+" влечет идентичность всевозможных строк вне зависимости от их происхождения по твоим определениям. Очевидно, что это отличается от традиционного ООП, где две строки с разными значениями в некий момент времени являются различными объектами. Или проще, объект в ООП не может обладать двумя различными состояниями одновременно. Твои — могут обладать счетным числом состояний (без ограничений возможности платформы).