S>Какой вопрос, такой и ответ. Вы задаёте вопрос в стиле "почему бог создал адама из глины, а еву — из ребра". Что я могу вам ответить, кроме совета почитать что-нибудь о происхождении видов?
один из стандартных советов: отвечайте так, чтобы посторонний наблюдатель мог перепроверить чья позиция ближе к реальности, не смотря на то, что он не знает модели обоих (не знает ни что такое "креационизм", ни что такое "происхождение видов"), а имеет какую-то свою модель.
соответственно, с точки зрения постороннего наблюда ответ выше ни чем не отличается от обратного ответа вида:
Как происхождение видов объясняет что человек обладает тем или свойством? Да почитайте вы наконец библию, там же все написано.
S>Ты не въехал, что у меня не получилось. У меня не получилось сравнить побитово структуры в общем виде. S>А уж как сравнить побитово встроенные значимые типы я бы догадался без твоих подсказок.
т.е. ты не знаешь, как из побитового сравнения встроенных типов сконструировать функцию, которая сравнивает структуры?
также следует, что не знаешь как получить битовое представление структуры?
DG>>как только ты говоришь про совпадение с реальностью, для начала необходимо показать (или хотя бы задуматься) какое определение одного и того же лучше совпадает с реальностью. S>Твои определения не работают в рамках определений ООП. Потому связи с реальностью нет как раз у них. Я тебе показывал это на примере идентичности различных строк.
определений ООП много, тебе необходимо сначала показать какое из них ближе к реальности, и почему.
DG>>>>а наши кунфу, вы говорите, самое убойное, мы его подсмотрели у крутых авторитетов, мы, конечно, в нем ничего не понимаем — что откуда следует, но оно реально крутое, чувак. S>>>Мы тебе только показываем что твое кунгфу не имеет ничего общего с кунгфу авторитетов.
DG>>религия никакого отношения к реальности не имеет, а аппелирование к авторитету (а не к реальности) — это религия S>Я аппелировал к определению идентичности.
пока не показано, как это связано с реальностью, это религия.
DG>>и приведенное тобой определение намного хуже совпадает с реальностью, чем определение "странный — не соответствующий ожиданиям". S>А ты формулируешь через понятие "ожидание", которое еще более неопределенно, чем "норма".
норма — это "усредненние" ожиданий членов группы, и здесь еще добавляется неопределенность от того, что можно взять разный способ "усреднения", а так же можно по разному брать группу, и соответственно норма имеет более высокую неопределенность, чем ожидание
Здравствуйте, DarkGray, Вы писали:
DG>а то каждый дурак говорит, что он понимает как всё устроено, вот только применить свои знания хоть для какой-нибудь оценки могут уже единицы.
Отлично. Давайте возьмём ваше "первое приближение".
пропорционально отношению размера записи некластерного индекса к размеру записи в кластерном индексе
Зададимся параметрами:
1. Размер записи некластерного уникального индекса по not null полю у нас равен size(key)+size(PageID)+2 байта расходов на index row entry. Пусть ключ будет классическим 4хбайтным целым. PageID, как известно, занимает 6 байт. Итого — 12 байт.
2. Размер записи в кластерном индексе мы положим тем же, что и в примере, который я опубликовал. Это 7950байт на "большую" колонку+4 байта ключа. Итого 7954.
Итого, вы меня пытаетесь уверить, что некластерный индекс будет работать быстрее "в первом приближении" в 662.5 раз?
Давайте я скажу вам своё первое приближение, а вы своё второе.
Правильный ответ: в первом приближении потребуется ровно столько же чтений для кластерного и некластерного индексов. Потому, что их non-leaf pages устроены совершенно одинаково: в них хранятся такие же 12-байтные index row entries. Отличия — только в leaf pages. В некластерном индексе в leaf pages хранятся такие же index row entries, а в кластерном вместо них выступают сами страницы с данными.
У кластерного индекса количество leaf pages в нашем случае, конечно же, больше. Ажно в 662.5 раз.
Но поскольку мы говорим о B-tree, то количество чтений определяется не количеством страниц, а его логарифмом.
Причём логарифмом по очень-очень большому основанию. В данном случае это 8096/12 = 674.
Итого,
Понятное дело, что читаем мы всегда целое количество страниц. Так что для кластерного индекса нам нужно примерно на 1 чтение больше.
Это если мы обошлись полем из индекса — т.е. к примеру проверяем exists().
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>Так вот, истинность KI>NI не зависит от размера одной записи S. И от количества записей N она тоже не зависит.
DG>как только ты от словоблудия перейдешь к написанию формулы кол-ва логических чтений для B-tree для тех или иных запросов, то сразу увидешь, что зависит.
Волшебным образом в B-tree количество чтений определяется логарифмом количества занятых страниц, которое, в свою очередь, пропорционально N.
Логарифм — функция монотонная. Поэтому если при каком-то N у нас получилось так, что KI>=NI, то это соотношение сохранится и при любом другом N.
Поэтому прекратите паясничать и идите читать букварь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>соответственно, с точки зрения постороннего наблюда ответ выше ни чем не отличается от обратного ответа вида
Встречный совет — изучите формальную логику.
В ней из ложного высказывания следует любое другое.
Поэтому независимо от наличия постороннего наблюдателя имеет смысл избегать вопросов типа
если <заведомо ложный предикат> то <некий другой предикат>; объясните почему?
Не нравится вам библия — давайте я так спрошу: "если кирпич — жидкость, то почему мы строим стены из бетона"?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>Ты не въехал, что у меня не получилось. У меня не получилось сравнить побитово структуры в общем виде. S>>А уж как сравнить побитово встроенные значимые типы я бы догадался без твоих подсказок.
DG>т.е. ты не знаешь, как из побитового сравнения встроенных типов сконструировать функцию, которая сравнивает структуры?
Сравнить структуры я смогу с помощью побитового сравнения значений встроенных типов, а так же с помощью сравнения ссылок. Но сравнить побитово структуры и сравнить побитово значения примитивных типов полей структуры — это не одно и то же. Результат может совпадать, а сам процесс — будет отличаться. DG>также следует, что не знаешь как получить битовое представление структуры?
Те методы, что ты демонстрировал я знаю. И еще маршаллинг. Но не для любых структур они подходят. Уверен, что легально или нет, я битовое представление любой структуры в дотнете получу. Но не собираюсь этим заниматься только что бы доказать тебе что-то.
S>>Твои определения не работают в рамках определений ООП. Потому связи с реальностью нет как раз у них. Я тебе показывал это на примере идентичности различных строк.
DG>определений ООП много, тебе необходимо сначала показать какое из них ближе к реальности, и почему.
Мне это не нужно.
DG>>>религия никакого отношения к реальности не имеет, а аппелирование к авторитету (а не к реальности) — это религия S>>Я аппелировал к определению идентичности.
DG>пока не показано, как это связано с реальностью, это религия.
Пусть для тебя это религия. Для меня идентичность связана с программами, которые я (и не только) пишу. А они реальны.
DG>>>и приведенное тобой определение намного хуже совпадает с реальностью, чем определение "странный — не соответствующий ожиданиям". S>>А ты формулируешь через понятие "ожидание", которое еще более неопределенно, чем "норма".
DG>норма — это "усредненние" ожиданий членов группы, и здесь еще добавляется неопределенность от того, что можно взять разный способ "усреднения", а так же можно по разному брать группу, и соответственно норма имеет более высокую неопределенность, чем ожидание
Ожидание члена группы — без указания конкретного индивидума еще более неопределено чем усреднение ожиданий членов группы, т.е. норма.
Здравствуйте, DarkGray, Вы писали: DG>пока не показано, как это связано с реальностью, это религия.
Я вам советую по возможности избегать математики. Там везде сплошная религия. Берут, скажем, набор требований, и называют конструкцию, которая этим требованиям удовлетворяет, полем.
Ни тебе связи с реальностью; ни тебе доказательства того, что без дистрибутивности поле не работает. Нет чтобы ввести понятие "частичной дистрибутивности", применимой не во все моменты времени.
А то и вообще — как начнут выписывать аксиомы типа "через точку можно провести ровно одну прямую, параллельную данной", опираясь на понятие прямой, которого в реальности не существует. Мы же хорошо знаем, что реальные прямые всегда хоть чуточку, но кривые.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Гы, ты опять пытаешься спор со мной увести на спор с самим собой... Было возражение насчет императивности? Я согласился, что подразумевал лишь то, что порядок вычисления важен, но коль тебе этого было мало, то давай уж добъем тему. Был дан конкретный пример инициализации переменных в С++, который остается корректным даже если в объявлении переменных поставить const (специально не поставил, было интересно спровоцировать и порассуждать о принципах иммутабельности, декларатиивной и фактической, по сути алгоритма, например). И был поставлен вопрос — это какое программирование? Ты же придрался, что не императивное, вот и расскажи, какое. Я вижу, что не функциональное ни разу, т.к. не присутствуют ф-ии как первокласссные объекты или операции над ними. А потом вернемся к РА, попробуем определить, под какое программирование оно подходит. S>Оставьте функциональное программирование в покое. Речь идёт об императивном vs декларативном.
Ну тогда можно сразу завязывать с ничьей, т.к. математическая нотация изначально слабо относится к парадигмам программирования, если быть строгим, т.е. обсуждение ни о чем. А насчет декларативного уже говорил, коль вместо описания св-в результата задается способ его получения, то тут декларативностью не пахнет.
S>Цитирую опять: S>
S>На уровне РА отношения эквивалентности есть только у тех операций, которые выразимы через другие...
S>Оба утверждения, мягко говоря, далеки от истины. Я ткнул носом в отношения эквивалентности, которые применимы к невыразимым через другие операциям (например, к операции выбора), и которые, собственно, и задают границы "сохранения семантики".
Уже показал на примере Cross production selection, где аналитический вид ф-ии ограничения считается известным, поэтому всё преобразование свелось к декомпозиции самой ф-ии ограничения и применения разных ее частей на разных этапах. Так вот, РА не занимается исследованием декомпозиций аналитических ф-ий, поэтому, хоть и показаны преобразования формул РА, это происходит не на уровне РА, а над ним. Вот тебе дадут ф-ию ограничения как черный ящик f(x), и ты "изнутри" самого инструментария РА ничего для случая Cross production selection сделать не сможешь.
V>>Заметь, в этой формуле показано, коль анлитически из A удалось выделить B, C и D, то B и C могли быть применены к каждому из отношений предварительно, а D — нет. В общем, случае B и C могут быть пусты, там об этом тоже сказано. Т.е. их невозможно быдет выделить аналитически из А, например при обычном join по внешнему ключу. Надо просто читать внимательней. И самое главное, повторюсь — это не есть изменения порядка операций, даже если было что выделять, это выполнение ДРУГИХ операций после преобразования. S>Давайте начнём с простого. Вот, например, попробуйте доказать, что это — не изменение порядка операций: S>
Это как раз случай явной выразимости одних операций через другие, т.е. таких, где не требуется знание аналитического вида формул. К тому же, про этот случай сказал в предыдущем сообщении, и его физический смыл был раскрыт в следующих строчках по твоей же ссылке:
Операция AND в условиях выборки коммутативна, поэтому да. Даи это было лишнее для аргументации. Ведь часть операций РА, которые являются теоретико-множественными, коммутативны сами по себе, поэтому можно было просто привести вот так еще в самом начале:
A AND (B AND C) = (A AND B) AND C.
A OR (B OR C) = (A OR B) OR C.
Где A,B,C — совместимые отношения. Сразу бы и отделили коммутативные от некоммутативных, чтобы не обобщать огульно.
V>>Что совсем не соответствует твоему утверждению, что порядок вычислений не важен. В РА выражение f(g(x)) не эквивалентно в общем случае g(f(x)). S>Вы, по-видимому, неправильно понимаете утверждение, которое пытаетесь оспорить. Вы утверждаете, что в РА "порядок операций" задан всегда. S>А я утверждаю, что нет, не всегда. Есть масса ситуаций, когда порядок операций можно изменить. Именно потому, что нет понятия "состояние вычислителя", т.е. РА имеет декларативную природу.
Нет, не поэтому, а исключительно из-за коммутативности. Аналогично вычислениям над обычными числами даже в императивной программе, часть вычислений можно проводить в произвольном порядке, если речь идет о коммутативных равноприоритетных операцих. Каким тут боком ты постоянно приплетаешь декларативность — это полное ХЗ. По твоим рассуждениям, декларативным является любое решение любой математической задачи, например, решение квадратного уравнения. А я считаю, что декларативно условие задачи — само уравнение, а его способ решение через нахождение дискриминанта — это именно последовательность решения, где дискриминант надо найти прежде, чем мы сможем через него найти корни уравнения.
V>>Легко заметить, что из всех возможных перестановок правых частей допустима только перестановка первой и второй операции, т.е. одна из 5-ти возможных. S>Ну вот видите — возможна же? Это ровно совпадает с моим утверждением "возможна перестановка там, где не меняется семантика".
РА не занимается семантикой, это делается на уровне РИ и реляционной модели. Т.е., чтобы провести все те преобразования формул РА, помимо заведомо коммутативных преобразований (т.е. безусловным образом выразимых через друг друга), нам нужно иметь всю модель, со всем ее физическим смыслом и зависимостями (т.е. с семантикой). Это не уровень РА.
V>>Он важен точно так же, так же как для классичесского функционального программирования, где вышестоящие ф-ии используют результаты нижестоящих. S>Совершенно верно. Но ведь это не делает "классическое функциональное программирование" императивным.
Возможно, хотя может сделать его процедурным, если мы не используем первоклассные ф-ии, не?
А процедурный подход относится к императивному или нет? Мне таки интересно твое развернутое мнение. Таки машина Тьюринга описана как автомат с ленточной памятью. Я ведь не зря привел "иммутабельный" вид инициализации после твоего повторного акцента на "императивный", бо тема скользкая даже для философии. А особенно если учесть, что ФП запросто может являться инструментом императивного программирования (что мы наблюдаем в современных императивных языках), то вообще границы получаются условными... В отличие от декларативных vs явно заданных вычислений.
V>>Ок, на выходных проверю, бо тут надо на 3 порядка больше страниц для моей машины, чтобы делать выводы. S> Ну давайте хотя бы порядок разницы предскажем, ок?
Ну коль для кластерного индекса строится точно такое же дерево на уровне неличтовых страниц, то чем он отличается от некластерного, когда на странице будет всего одна запись?
Вообще, надо поднять тот проект, посмотреть, почему после отказа от кластерных индексов по primary_key резко возросло общее быстродействие... Возможно, что по коссвенным к обсуждаемому причинам, например доступности теперь кластерного для внешних ключей. Насчет порядка: если некая соединительная операция из 3-х (грубо) составляющий выполняется в 4 раза быстрее, что каждая в среднем стала выполняться быстрее в корень 3-й степени из 4.
V>>Лихо ты скачешь. Если вернуться чуть вверх, то спор зашел изначально об индексах, bookmark lookup и прочих низкоуровневых операциях, для которых я утверждал, что аппарат РА к ним применим. И ты правильную ссылку дал, кстати, что этот аппарат таки применим аж бегом. прямо по ссылке и написано, что используется для оптимизации запросов. S>Да нет же, не используется.
Врет ссылка?
V>>Если же "интеллектуальная нагрузка" на СУБД высока, то оценка в ~90% кода, требующего хотя бы косметических коррекций — вполне. S>Ну вот видите, уже начинаются "если", "то"...
Гы, это не мое "если", а твое, ты же настаиваешь на кросс-СУБД проектах. Это очередной спор сам с собой, бо наличие области пересечения диалектов не отрицалось, но ей была дана низкая оценка, коль взять сразу несколько популярных СУБД (больше 2-х, хотя бы). Ну разумеется, b]если[/b] ты используешь только часть от всего разнообразия синтаксиса SQL, то для тебя может случиться так, что 100% кода не будут требовать переделки. Это не есть достойный аргумент против. Коль речь шла о сравнении SQL, я дал грубую прикидку по диалектам целиком.
S>>>Ну, если вы мне покажете, где именно "в реальной работе СУБД" логическое выражение возвращает NULL, то на здоровье — используйте его.
V>>SELECT (TRUE AND (5 > NULL)) — покатит? S> Вот сразу и видно, у кого есть практика, а у кого её нету. S>MS SQL: Incorrect syntax near the keyword 'AND'. S>SQLite3: Error: no such column: TRUE S>Так что нет, не покатит. Приходите в другой раз.
Угу, повеселил. Попробовал в MS Access, Oracle, Postgre, MySQL, DB2, d-base, FoxPro?
Ах какая неожиданная демонстрация предмета спора по предыдущему абзацу. Это же классический упс, не правда ли?
Для удобства в MS Access после проверки этого выражения проверь вот это:
SELECT (TRUE AND (5 > NULL)) IS NULL
Увидишь кой-чего интересное, тоже в плане переносимости очередная не всегда переносимая фишка (автоматическое/неавтоматическое приведение чисел к булевскому значению и обратно).
V>>Тю, блин, какой конфуз. А как по-твоему выглядит в терминах РА вот это: V>>select * from X where X.x1 in (select y1 from Y) V>>? S>А это зависит от того, как определена табличка X. А то может и вовсе никак не выглядеть.
Определена как отношение, в котором присутствует атрибут x1 по тому же домену, что и атрибут y1 в отношении Y.
Это я про то, что порядок и вид выражений РА вовсе не обязан соответствовать "естественному" порядку исходного SQL. И еще про то, что SQL крайне избыточен, позволяя задавать одни и те же запросы очень многими способами. Так вот, из приведения всех вариантов запросов к одному (для данного случая) варианту в терминах РА следует, что вид операций РА слабо связан с видом выражения в SQL.
V>>Если речь о "простой арифметике", то бишь о числах, то можно два варианта: поменять местами x и y согласно условия задачи (сортировки в обратном порядке), либо воспользоваться св-вом коммутативности числовой алгебры и просто поменять знак результата исходного компаратора, коль будет известно, что результат сравнения чисел реализован через вычитание. Если характер сравниваемых величин неизвестен, то остается первый способ, согласно условию. S>Ок, пусть у нас результат сравнения чисел реализован через вычитание. Я правильно понял из выделенного, что вы считаете вот такую реализацию корректной для "обычных" int32?
До сегодняшнего дня да, коль (x-y)==-(y-x).
Но у тебя ошибка в коде, нет учета переполнения. Надо так:
public int IntCompare(int x, int y)
{
return new Int64(x)-y;
}
Или же расписать на if.
V>>Опять же ХЗ зачем ты делаешь очередные ответвления от и так раздутых постов... S>Минуточку. Скоро всё станет ясно.
Блин, что за детсад? Мог бы не растягивать итерации, ты уже получил что хотел от меня изначально. Все поняли из условия, что ты хотел услышать, тебе это уже дали (выделенное).
V>>Вводится ф-ия сравнения f для домена ID {MIN_INT..MAX_INT, null} возвращающая результат в домене SQL_PREDICATE {true, false, null}. Дальше продолжать или уже понятно, с учетом сказанного в пред. посте? S>Ок, я понял вашу идею. Она заслуживает рассмотрения, хотя, скажем, сам Кодд почему-то был другого мнения, и построил расширение своей РА вместо сведения к дополнительным Join+Selection.
Наверно, чтобы не париться в частовстречающихся сценариях?
Его расширение так и осталось его расширением, кстате, т.е. не было включено в саму РА. Есть же еще 12 правил Кодда, которые даже не изучают в ВУЗах (максимум просто упоминают, в экзаменах этого нет, по крайней мере у нас не было, т.к. это уже во-многом прикладной уровень, игнорируемый нашим образованием). ИМХО, еще от того, что эти правила так и не были реализованы полностью в никакой СУБД.
V>>Наверно потому, что современные СУБД — это "вещь в себе", с дорогостоящей связью с внешним миром, т.е. требуется предоставить максимум ср-в внутри СУБД, чтобы писать разносторонние приложения. S>Удивительно, как это авторы SQL предусмотрели вот эту возможность писать "разносторонние приложения" сразу же из коробки — не дожидаясь, когда появятся разносторнние приложения и начнут требовать поддержки нереляционных данных. И всё ещё в 80х. Зато вот производительность серверов их никак не интересовала — во-времена то, когда 16 мегабайт памяти на машине были большой редкостью, а гигабайтные базы — нет.
Базы существовали еще до появления SQL, поэтому требования к "из коробки" были известны, ничего удивительного. Первые SQL шли как препроцессоры к обычным языкам программирования, поэтому народ привык, что вперемешку с реляционными операциями над данными он может совершать над ними произвольные прикладные операции. В общем, вопрос языковых ср-в малость отдельный, бо это нормально, когда язык поддерживает более одной парадигмы. Это не мешает исследовать сии парадигмы независимо.
V>>Как мы еще не дошли до обсуждения временных таблиц и императивных алгоритмов на курсорах? Непорядок, непорядок... S>Вы не переживайте, если потребуется — дойдём. V>>Далеко не всех, а лишь где задекларирована поддержка SQL-99. MySQL, MS Access, MS ESQL и т.д. не понимают. Да и не такое уж это и небольшое расширение. Стало возможным задавать запросы, непредставимые в терминах РИ. S>MS Access, простите, это настольная СУБД. Для промышленного использования она никогда и не предназначалась.
Давай вот это оставим в пользу бедных. В случае многозвенки, коль есть еще один выделенный сервер, любые in-proc движки данных, и даже MSJet, вполне подходящи. Конечно, речь не о клиенте к MSJet, которым является офисное приложение MS Access, но так уж принято называть этот движок по имени использующего приложения, ради которого он был разработан. Считай, что я поправился, хотя мне этого глубоко не принципиально.
S>А в SQL Server (всех редакций, включая Express) — есть.
При чем тут Express? В экспрессе фактически та же кодовая база, просто вложены ограничения. Имелся ввиду MS SQL Everywhere, который доступен теперь на десктопе как MS SQL CE, и показал себя весьма эффективным для случая подключения движка базы в виде in-proc. Экпрессу во многих сценариях до него как до Китая раком, в плане эффективности.
Теоретики реляционных баз данных в процессе развития теории...
Считается, что вокруг реляционных баз таки теория, а не просто инженерия.
V>>Делаются конкретные приложения. Ты снова и снова путаешь св-ва инструментария и характера данных. Не нужна тебе целостность — да не поддерживай, какие проблемы? V>>Мне важно обратное, что СУБД предоставляет все ср-ва для построения реляционной модели данных. S>Задам вам ваш любимый вопрос: что первично?
Первично реализация требований. Фишка в том, что реализовать требования в общем случае можно более, чем одним способом. Поэтому можно спекулировать отсюда и до бесконечности.
V>>Ну это да... чтобы производительность получения промежуточных результатов не волновала особо, для исторических есть отдельно стоящий OLAP, а оперативные не особо велики, по меркам современных машин. S>Ага. То есть в 1986 году авторы стандарта SQL заранее знали, что в 2011 будет отдельно стоящий OLAP, а оперативные данные будут не особо велики, по меркам современных машин.
Так делали еще до появления SQL. Это вроде изобретение банковских систем.
S>И с дьявольской предусмотрительностью сделали основой модели SQL мультимножества для того, чтобы сразу же колбасить на SQL-совместимых СУБД постреляционные приложения и дать в полный рост развернуться системам ORM.
Для хранения объектов вообще реляционные субд не айс. Просто пользуют из-за надежной реализации транзакций... ИМХО, сугубо исторически.
И при чем тут мой анализ? Реляционная теория занимается вопросами эффективной реализации внешнего хранилища. И не особо твои мультимножества мешают, хорош рефлексировать. Возьми свою ссылку по правилам преобразованиям РА и попытайся доказать, что эти преобразования для случая мультимножеств станут невалидными. Ты же утверждаешь, что их нельзя использовать в процессе оптимизации "реальных запросов", вот докажи в верифицируемом виде. Как докажешь, продолжишь тыкать в меня своими мультимножествами, а пока сделай паузу... Меня эта тема вообще не волнует, бо в самых первых вариантах в реляционной модели предлагалось снабдить кортежи неким порядковым номером (т.е. обязательным суррогатным ключом), потом от этого отказались. В реальных СУБД обязательно есть некий RowID, т.е. записи в любом случае различимы для самой СУБД, хоть тебе эта информация на прикладном уровне и не дается, ее можно посмотреть в трейсе. Именно поэтому меня твой аргумент насчет мультимножеств не особо торкает, он малость надуман спора ради.
S>>>Серъёзно что ли? Мне нравятся кванторы типа "практически всегда". Это вы себе лазейку оставляете для того, чтобы когда я вас носом ткну в реалистичный пример применения неуникального индекса, вы начали юлить типа "ой, ну это же так редко нужно"? Давайте вы вместо "практически всегда" напишете, когда именно "обыгрывание ключа дополнительным отношением" будет приводить к росту эффективности по сравнению с банальным create index. А когда, соответственно, наоборот.
V>>Когда будет — уже привел, это для случая кластерного неуникального индекса. S>То есть для "кластерного неуникального индекса" ваше "обыгрывание ключа дополнительным отношением" будет приводить к росту эффективности, я вас правильно понял?
Неправильно, ты потерял контекст. Наоборот, для этого случая и предлагалось резервировать кластерный индекс, коль он всего один, но такой сценарий есть. А остальное ты зря так смело скипнул, в нем сама первоначальная суть индексов в ограничении объема обрабатываемых данных (хоть речь шла об "искусственном" индексе). Есть еще фишка: по таблице кластерный индекс может быть только один, а такие "искусственные" индексы в виде отдельного отношения для прикладных сценариев могут иметь каждый свой кластерный индекс.
Здравствуйте, gandjustas, Вы писали:
G>Порядок вычислений и порядок композиции не одно и то же. Композиция не коммутативна, но никто не говорит что функция справа должна быть вычислена раньше, чем функция слева оператора композиции.
Тем не менее, для коммутативных операций это так. Но они составляют лишь подмножество обсуждаемого предмета.
Причем, коммутативность в случае РА существует на 2-х уровнях: в самих некоторых операциях РА (теоретико-множественных) и потенциально в аналитическом виде в функциях-условиях ограничений и продукций. Так вот, если в плане коммутативности самих операций РА никто спекулировать не решился, из-за, прямо скажем, потенциальной слабости аргумента, т.к. на виду и те операции, что не коммутативны... то наличие возможной коммутативности в аналитическом виде функций-ограничений легко пошло как аргумент, почему-то. По мне, одного поля ягоды. И там и там возможны некоммутативные операции, поэтому в общем случае перестановки операций будут менять семантику.
S>Волшебным образом в B-tree количество чтений определяется логарифмом количества занятых страниц, которое, в свою очередь, пропорционально N.
покажи переход от кол-ва чтений записей к кол-ву чтений страниц и далее к кол-ву операций чтений с винта.
чтение записей действительно логарифм, и действительно не зависит от размера страниц.
зы
если человек не может внятно написать формулу как взаимосвязано кол-во чтений записей с кол-вом чтений с винта, то о каком умении разделения абстракций вообще можно говорить...
а теперь сделай переход к вероятностям: вероятность того, что та или иная страница уже лежит в кэше, а также как будет выражено время выполнения запроса через вероятность нахождения тех или иных страниц в кэше.
зы
например, если ОП хватает, чтобы non-leaf pages в основном лежали в кэше (а так обычно и бывает), то производительность будет определяться в первую очередь как много надо прочитать leaf-pages, чтобы получить ответ.
соответственно, чем меньше записей лежит на одной leaf-pages, то тем больше надо прочитать страниц всего, а также тем выше вероятность нарваться на фрагментацию.
S>Поэтому независимо от наличия постороннего наблюдателя имеет смысл избегать вопросов типа S>
S>если <заведомо ложный предикат> то <некий другой предикат>; объясните почему?
не перескакивай
обсуждалась тема "каким должен быть ответ"(а не каким должен быть вопрос), и была дана рекомендация: ответ должен быть таким, чтобы он мог быть перепроверен сторонним наблюдателем.
если ты утверждаешь, что вывод неверен, потому что неверна исходная посылка, значит ты должен в ответе(исходя из данной рекомандации) показать ложность вводного утверждения, а не посылать читать букварь (первое перепроверяемо сторонним наблюдателем, во втором случае — перепроверять нечего).
S>Не нравится вам библия — давайте я так спрошу: "если кирпич — жидкость, то почему мы строим стены из бетона"?
здесь как раз нет ложных посылок.
здесь вводится допущение, которое как раз может быть произвольным. и заключается в формулировании предположения(гипотезы), которое временно считается верным.
1. например, в математике — значительная часть доказательств начинается с допущений, в частности, все доказательства от противного делаются через предварительное допущение, которое считается верным.
2. также, например, стойкость значительной части криптографии доказывается через допущение, что NP != P (которое само по себе недоказано) и т.д.
3. допущение также может использоваться для упрощения формул. Например, используется допущение, что 0! = 1, это упрощает значительную часть формул комбинаторики.
4. частным случаем допущений являются аксиомы. например, евклидова геометрия отличается от геометрии лобачевского лишь допущением: параллельные прямые пересекаются или нет;
5. на допущениях строится значительная часть наук. геометрическая оптика использует допущение, что свет — это частица(луч);
большая часть физики использует допущение, что тело можно представить как материальную точку; и т.д.
и соответственно, нет разницы между допущениями:
допустим, что человек — точка
допустим, что кирпич — жидкость
они оба строго говоря не верные.
фраза "допустим, что A — X" означает, давайте временно наделим понятие A свойствами X, и сделаем выводы, которые из этого следует.
Первое допущение наделяет человека свойством, что его размеры равны 0,
второе допущение может, например, наделять кирпич свойствами что его можно передавать по трубам.
Готовые построенные выводы дадут понимание в реальной задаче, а что даст хорошего — если удастся человека посчитать точкой, или что будет хорошо, если кирпич удастся передавать по трубам? и соответственно дают ответ на вопрос — а нужно ли вообще стремиться считать человека точкой? или нужно ли стремиться передавать кирпичи по трубам?
допущения используются для разбиения задачи на части (что часто используется когда в задаче присутствует высокая вариативность, неопределенность, разнородность и т.д.).
решение задачи "верно ли, что из A следует Z" заменяется на ряд временных задач:
задача 1. верно ли что из A следует B? ;
задача 2. допустим, что верно B. верно ли что из B следует C?
..
вместо задачи "верно ли, что из A следует Z", может быть любой другой вид задач: можно ли из A построить Z; верно ли, что A меньше Z и т.д
при этом решение задачи может двигаться с наиболее определенных подзадач, или с подзадач, которые сильнее всего уменьшают вариативность и т.д.
S>Я вам советую по возможности избегать математики. Там везде сплошная религия. Берут, скажем, набор требований, и называют конструкцию, которая этим требованиям удовлетворяет, полем.
так в том-то и дело, что полем при этом будет являться произвольная штука, которая обладает данными требованиями.
в том числе и штука, для которой удалось доопределить, допустить и т.д. данные требования.
также при этом на само название всем пофигу, его можно называть хоть грядкой: главное, что если что-то удовлетворяет данным требованиям, то оно будет всегда обладать следующими свойствами:
Характеристика поля всегда 0 или простое число. Поле характеристики 0 содержит подполе, изоморфное полю рациональных чисел .
Поле простой характеристики p содержит подполе, изоморфное полю вычетов .
Количество элементов в конечном поле всегда равно pn — степени простого числа. При этом для любого числа вида pn существует единственное (с точностью до изоморфизма) поле из pn элементов, обычно обозначаемое .
Любой ненулевой гомоморфизм полей является вложением.
В поле нет делителей нуля.
при этом все эти свойства доказываются, и соответственно, можно показать, как будут меняться эти свойства, если меняются исходные требования.
другими словами: слово поле — это лишь синоним для "множество F с двумя бинарными операциями + (аддитивная операция, или сложение) и (мультипликативная операция, или умножение), если оно (вместе с этими операциями) образует коммутативное ассоциативное кольцо c единицей , все ненулевые элементы которого обратимы"
и само слово поле можно выкинуть
соответственно, математическое определение объекта — это, например:
объект — это штука которая обладает следующими требованиями: есть функция идентичности, есть посылка/прием сообщений.
именно такое математическое определение я и просил.
и исходя из определения выше, переменная является объектом — для случая, когда функцией идентичности является индентичность экземпляров переменной, а сообщениями является установка и получения значения из переменной.
S>Ни тебе связи с реальностью;
есть связь с реальностью: указано, что комплексные, вещественные, рациональные числа являются полем.
S> ни тебе доказательства того, что без дистрибутивности поле не работает.
если ты откроешь учебник, там будет это доказательство.
и будет доказано, что из требований "множество F с двумя бинарными операциями + (аддитивная операция, или сложение) и (мультипликативная операция, или умножение), если оно (вместе с этими операциями) образует коммутативное ассоциативное кольцо c единицей , все ненулевые элементы которого обратимы."
всегда следует, что "это есть коммутативная группа по сложению, а все его ненулевые элементы образуют коммутативную группу по умножению, и выполняется свойство дистрибутивности".
S>А то и вообще — как начнут выписывать аксиомы типа "через точку можно провести ровно одну прямую, параллельную данной", опираясь на понятие прямой, которого в реальности не существует.
вообще-то определения прямой действительно нету, это неопределяемое понятие. у неопределяемых понятий бывает лишь описание и свойства.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Порядок вычислений и порядок композиции не одно и то же. Композиция не коммутативна, но никто не говорит что функция справа должна быть вычислена раньше, чем функция слева оператора композиции.
V>Тем не менее, для коммутативных операций это так.
Тоже неверно. Представим коммутативную операцию a ~ b = b ~ a = 1. То есть всегда возвращающую одно значение. Для нее требуется вычислять аргументы? Вообще-то нет.
Представим другую, некоммутативную операцию, a | b = not a. Для вычисления требуется вычислять аргументы? Тоже нет.
Вообще если принять нормальный порядок вычислений, а не аппликативный, то порядок вычислений с порядком композиции почти никак не зависят друг от друга.
Так как нормальный порядок вычислений всегда дает результат если это возможно, то его можно принять за умолчание в любой выичслительной теории если явно не указано обратное.
И в РА кажись не предполагается энергичный порядок.
Здравствуйте, vdimas, Вы писали:
V>Ну тогда можно сразу завязывать с ничьей, т.к. математическая нотация изначально слабо относится к парадигмам программирования, если быть строгим, т.е. обсуждение ни о чем.
Согласен.
V>Уже показал на примере Cross production selection, где аналитический вид ф-ии ограничения считается известным, поэтому всё преобразование свелось к декомпозиции самой ф-ии ограничения и применения разных ее частей на разных этапах. Так вот, РА не занимается исследованием декомпозиций аналитических ф-ий, поэтому, хоть и показаны преобразования формул РА, это происходит не на уровне РА, а над ним.
Ну то есть мы начинаем постепенно понимать, что оптимизатор запросов в СУБД работает не на уровне РА. Это хорошо.
V>Это как раз случай явной выразимости одних операций через другие, т.е. таких, где не требуется знание аналитического вида формул.
Каких одних через какие другие?
V>К тому же, про этот случай сказал в предыдущем сообщении, и его физический смыл был раскрыт в следующих строчках по твоей же ссылке: V> V>Операция AND в условиях выборки коммутативна, поэтому да. Даи это было лишнее для аргументации. Ведь часть операций РА, которые являются теоретико-множественными, коммутативны сами по себе, поэтому можно было просто привести вот так еще в самом начале: V>A AND (B AND C) = (A AND B) AND C. V>A OR (B OR C) = (A OR B) OR C. V>Где A,B,C — совместимые отношения. Сразу бы и отделили коммутативные от некоммутативных, чтобы не обобщать огульно.
Вы путаете коммутативность с ассоциативностью.
V>Нет, не поэтому, а исключительно из-за коммутативности. Аналогично вычислениям над обычными числами даже в императивной программе, часть вычислений можно проводить в произвольном порядке, если речь идет о коммутативных равноприоритетных операцих.
Вы ошибаетесь. Возьмём, к примеру, коммутативную операцию над обычными числами:
int i = GetA()*GetB();
Если у GetA() или GetB() есть побочный эффект, то перестановка порядка вычислений запрещена. Несмотря на коммутативность умножения.
Другой пример — возьмём умножение матриц:
Matrix i = GetA()*GetB();
Если у GetA() и GetB() гарантированно нет побочных эффектов, то можно вычислять их в любом порядке. Несмотря на отстутствие коммутативности.
V>РА не занимается семантикой, это делается на уровне РИ и реляционной модели. Т.е., чтобы провести все те преобразования формул РА, помимо заведомо коммутативных преобразований (т.е. безусловным образом выразимых через друг друга),
Алиса, никогда не употребляй слова только за то, что они длинные и красивые. Погуглите определение термина "коммутативность".
V>>>Он важен точно так же, так же как для классичесского функционального программирования, где вышестоящие ф-ии используют результаты нижестоящих. S>>Совершенно верно. Но ведь это не делает "классическое функциональное программирование" императивным.
V>Возможно, хотя может сделать его процедурным, если мы не используем первоклассные ф-ии, не?
Не, не может. V>А процедурный подход относится к императивному или нет? Мне таки интересно твое развернутое мнение. Таки машина Тьюринга описана как автомат с ленточной памятью.
А частично рекурсивные функции — нет. Дальше что?
V>Ну коль для кластерного индекса строится точно такое же дерево на уровне неличтовых страниц, то чем он отличается от некластерного, когда на странице будет всего одна запись?
Тем, что для некластерного таки будет создана отдельная страница. Вы не стесняйтесь, читайте литературу. V>Вообще, надо поднять тот проект, посмотреть, почему после отказа от кластерных индексов по primary_key резко возросло общее быстродействие... Возможно, что по коссвенным к обсуждаемому причинам, например доступности теперь кластерного для внешних ключей.
Конечно по косвенным. Но вы поспешили сделать выводы. V>Насчет порядка: если некая соединительная операция из 3-х (грубо) составляющий выполняется в 4 раза быстрее, что каждая в среднем стала выполняться быстрее в корень 3-й степени из 4.
Простите, но зачем вы продолжаете это делать? Времена выполнения операции Join очень косвенно связаны с произведением кардинальностей аргументов.
Например, merge join вообще выполняется как O(N+M).
S>>Да нет же, не используется. V>Врет ссылка?
Скажем так: упрощает. V>Для удобства в MS Access после проверки этого выражения проверь вот это: V>SELECT (TRUE AND (5 > NULL)) IS NULL
Ок, я понял. Ваш опыт, которым вы так гордитесь, получен в основном на настольной СУБД.
V>Определена как отношение, в котором присутствует атрибут x1 по тому же домену, что и атрибут y1 в отношении Y. V>Это я про то, что порядок и вид выражений РА вовсе не обязан соответствовать "естественному" порядку исходного SQL. И еще про то, что SQL крайне избыточен, позволяя задавать одни и те же запросы очень многими способами. Так вот, из приведения всех вариантов запросов к одному (для данного случая) варианту в терминах РА следует, что вид операций РА слабо связан с видом выражения в SQL.
Ок, хорошо, разница между РА и SQL становится всё более явной.
V>>>Если речь о "простой арифметике", то бишь о числах, то можно два варианта: поменять местами x и y согласно условия задачи (сортировки в обратном порядке), либо воспользоваться св-вом коммутативности числовой алгебры и просто поменять знак результата исходного компаратора, коль будет известно, что результат сравнения чисел реализован через вычитание. Если характер сравниваемых величин неизвестен, то остается первый способ, согласно условию. S>>Ок, пусть у нас результат сравнения чисел реализован через вычитание. Я правильно понял из выделенного, что вы считаете вот такую реализацию корректной для "обычных" int32?
V>До сегодняшнего дня да, коль (x-y)==-(y-x). V>Но у тебя ошибка в коде, нет учета переполнения.
Воот. Эта ошибка связана с тем, что код предполагает такую же математику в компьютере, как и в учебнике. В учебнике у всех целых чисел есть их "антипод", -x = -1*x.
А в компьютере — не у всех, разрядность ограничена.
И можно действовать двумя способами:
а) привести задачу к "условиям теории", чтобы можно было использовать весь теоретический аппарат
б) привести решение к "специфике реализации", чтобы использовать тот аппарат, который есть на практике.
В первом варианте мы начинаем требовать от компьютера поддержки целых чисел произвольной разрядности; во втором — подпиливаем код так, чтобы он корректно работал с учётом ограничений, несмотря на то, что он выглядит не как "теоретическое" решение.
Вы пошли по второму варианту.
Но для реляционной модели и SQL вы продолжаете настаивать на первом варианте.
V>Его расширение так и осталось его расширением, кстате, т.е. не было включено в саму РА. Есть же еще 12 правил Кодда, которые даже не изучают в ВУЗах (максимум просто упоминают, в экзаменах этого нет, по крайней мере у нас не было, т.к. это уже во-многом прикладной уровень, игнорируемый нашим образованием). ИМХО, еще от того, что эти правила так и не были реализованы полностью в никакой СУБД.
V>>>Наверно потому, что современные СУБД — это "вещь в себе", с дорогостоящей связью с внешним миром, т.е. требуется предоставить максимум ср-в внутри СУБД, чтобы писать разносторонние приложения. S>>Удивительно, как это авторы SQL предусмотрели вот эту возможность писать "разносторонние приложения" сразу же из коробки — не дожидаясь, когда появятся разносторнние приложения и начнут требовать поддержки нереляционных данных. И всё ещё в 80х. Зато вот производительность серверов их никак не интересовала — во-времена то, когда 16 мегабайт памяти на машине были большой редкостью, а гигабайтные базы — нет.
V>Базы существовали еще до появления SQL, поэтому требования к "из коробки" были известны, ничего удивительного. Первые SQL шли как препроцессоры к обычным языкам программирования, поэтому народ привык, что вперемешку с реляционными операциями над данными он может совершать над ними произвольные прикладные операции. В общем, вопрос языковых ср-в малость отдельный, бо это нормально, когда язык поддерживает более одной парадигмы. Это не мешает исследовать сии парадигмы независимо.
V>>>Как мы еще не дошли до обсуждения временных таблиц и императивных алгоритмов на курсорах? Непорядок, непорядок... S>>Вы не переживайте, если потребуется — дойдём. V>>>Далеко не всех, а лишь где задекларирована поддержка SQL-99. MySQL, MS Access, MS ESQL и т.д. не понимают. Да и не такое уж это и небольшое расширение. Стало возможным задавать запросы, непредставимые в терминах РИ. S>>MS Access, простите, это настольная СУБД. Для промышленного использования она никогда и не предназначалась.
V>Давай вот это оставим в пользу бедных. В случае многозвенки, коль есть еще один выделенный сервер, любые in-proc движки данных, и даже MSJet, вполне подходящи. Конечно, речь не о клиенте к MSJet, которым является офисное приложение MS Access, но так уж принято называть этот движок по имени использующего приложения, ради которого он был разработан. Считай, что я поправился, хотя мне этого глубоко не принципиально.
S>>А в SQL Server (всех редакций, включая Express) — есть.
V>При чем тут Express? В экспрессе фактически та же кодовая база, просто вложены ограничения. Имелся ввиду MS SQL Everywhere, который доступен теперь на десктопе как MS SQL CE, и показал себя весьма эффективным для случая подключения движка базы в виде in-proc. Экпрессу во многих сценариях до него как до Китая раком, в плане эффективности.
V>MySQL? SQLite?
Мускул, простите, не показатель. В нём вообще много чего ещё нет. А встраиваемые и настольные базы данных я предлагаю не рассматривать — они не для промышленного применения, поэтому в них все новшества появляются с большим опозданием.
V>Считается, что вокруг реляционных баз таки теория, а не просто инженерия.
Да это-то я понимаю. Мне было интересно, что именно вы под этим словом понимаете. Потому что вы имеете трогательную привычку использовать термины неожиданным образом.
V>Первично реализация требований.
Ну вот видите. А теоретические модели — они появляются потом, когда мы анализируем решения, удовлетворяющие требованиям. S>>И с дьявольской предусмотрительностью сделали основой модели SQL мультимножества для того, чтобы сразу же колбасить на SQL-совместимых СУБД постреляционные приложения и дать в полный рост развернуться системам ORM. V>Для хранения объектов вообще реляционные субд не айс. Просто пользуют из-за надежной реализации транзакций... ИМХО, сугубо исторически.
Конечно исторически. Просто кроме RDBMS на рынке ничего промышленно-надёжного так и не появилось. Успели выдавить в своё время.
V>Неправильно, ты потерял контекст.
Тогда напишите, как правильно. Когда именно лучше обыгрывать неуникальный ключ дополнительным отношением, вместо банального создания индекса?
Первоначальная суть индексов — в уменьшении количества обращений к диску.
Ограничение объёма данных — это один из способов добиться этого уменьшения, причём не самый эффективный.
V>Есть еще фишка: по таблице кластерный индекс может быть только один, а такие "искусственные" индексы в виде отдельного отношения для прикладных сценариев могут иметь каждый свой кластерный индекс.
Вы рассматривайте всю картину в целом. Сравните накладные расходы на неуникальный индекс и на "отдельное отношение" — даже если в этом отдельном отношении есть кластерный индекс.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>Волшебным образом в B-tree количество чтений определяется логарифмом количества занятых страниц, которое, в свою очередь, пропорционально N.
DG>покажи переход от кол-ва чтений записей к кол-ву чтений страниц и далее к кол-ву операций чтений с винта.
1. Операции "чтение записей" нет. Читаются всегда цельные страницы.
2. Размер страниц — фикирован, и не зависит от размера записей.
Что именно вам непонятно?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>а теперь сделай переход к вероятностям: вероятность того, что та или иная страница уже лежит в кэше, а также как будет выражено время выполнения запроса через вероятность нахождения тех или иных страниц в кэше. DG>зы DG>например, если ОП хватает, чтобы non-leaf pages в основном лежали в кэше (а так обычно и бывает), то производительность будет определяться в первую очередь как много надо прочитать leaf-pages, чтобы получить ответ. DG>соответственно, чем меньше записей лежит на одной leaf-pages, то тем больше надо прочитать страниц всего, а также тем выше вероятность нарваться на фрагментацию.
B-tree устроено так, что для любого поиска одиночного элемента надо прочитать ровно одну leaf-страницу.
Вероятности нахождения страниц в кэше крайне плохо поддаются предсказанию — как я уже сказал, там есть очень много факторов, которые вы так просто не учтёте.
Поэтому при оптимизации запросов уменьшают количество логическихчтений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
DG>здесь как раз нет ложных посылок. DG>здесь вводится допущение, которое как раз может быть произвольным. и заключается в формулировании предположения(гипотезы), которое временно считается верным.
ОМГ. Вижу, аллегории плохо доходят.
Вы "временно допускаете верным" предположения типа "вот эта функция является корректным переводом функции из одной системы в другую".
При этом никаких критериев корректности вы не приводите.
Зато предлагаете объяснить, почему другая пара функций не является корректным переводом друг друга.
Чего вы ожидаете в ответ? Чего-то проверяемого сторонним наблюдателем?
Вот вам ответ, проверяемый сторонним наблюдателем: из вашего единичного примера корректного перевода невозможно однозначно определить систему критериев корректности перевода таким образом, чтобы второй пример перевода был заведомо некорректным.
Если бы вы взяли на себя труд подготовить другую структуру вопроса — например, привели бы доказательство (или хотя бы его схему) того, что перевод корректен, то сторонний наблюдатель мог бы вам ответить, применив те же правила проверки корректности, что и вы к первому переводу.
А так — разгадывать ваши головоломки мотивации нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DarkGray, Вы писали:
S>>Я вам советую по возможности избегать математики. Там везде сплошная религия. Берут, скажем, набор требований, и называют конструкцию, которая этим требованиям удовлетворяет, полем.
DG>так в том-то и дело, что полем при этом будет являться произвольная штука, которая обладает данными требованиями.
Правильно. Ну так вам и твердят: объектом называется сущность, которая обладает идентичностью, поведением, и состоянием. А вы зачем-то начинаете мучить мозг и спрашивать, почему нельзя называть объектом то, что этим требованиям не удовлетворяет. Ну не удовлетворяет — и слава байту; ООП — вовсе не единственная модель программирования.
На immutable-структурах без идентичности можно построить ничуть не менее выразительную и мощную модель. Можно вообще обойтись без каких-либо структур, одними только функциями.
Убирая те или иные свойства из модели ООП вы будете получать другие, несовместимые с ООП модели.
Добавляя свойства, вы можете построить развитую ООП-модель. Никто не против. Добавьте классы, наследование, понятие идемпотентных и безопасных методов, добавьте понятия негарантированной доставки и стоимости доставки сообщений. Всё — по вкусу. Но эти элементы не обязательны.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DG>>так в том-то и дело, что полем при этом будет являться произвольная штука, которая обладает данными требованиями. S>Правильно. Ну так вам и твердят: объектом называется сущность, которая обладает идентичностью, поведением, и состоянием. А вы зачем-то начинаете мучить мозг и спрашивать, почему нельзя называть объектом то, что этим требованиям не удовлетворяет.
так переменная объект или нет?
у нее есть идентичность, поведение и состояние.
Ну давайте хотя бы порядок разницы предскажем, ок?
