DG>>>откуда известно, что в данном месте происходит присвоение ссылок, а не что-то другое? G>>Из ecma-335, так как для ref-типов оператор "=" — присвоение ссылок. Мы ведь в рамках ecma-335 находимся, не так ли?
DG>>правильно я понял, что ты утверждаешь, что всегда когда в коде на c# мы видим операцию = и тип переменной reference, то всегда происходит лишь присваивание ссылки? DG>Именно так.
DG>[занудно] DG>из того, что для ref-типов оператор '=' используется для присвоение ссылок не следует, что каждое использование оператор '=' для ref-типов является лишь присвоением ссылок.
И? Что ты хочешь сказать? Главный вопрос меняется ли identity при присвоении ссылок? Ответ — нет. Остальное нерелевантно обсуждению.
А вообще приводи ссылки на ecma когда пишешь свои опусы.
DG>>>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию? S>>Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.
DG>я правильно понимаю, что фактически под идентичностью вы понимаете возможность определения, что объект является сам собой же?
Именно так. Причем отношение индентичности не должно опираться на состояние и поведение.
DG>для каких алгоритмов (ситуаций, задач и т.д.) это знание вообще требуется?
Это требуется в первую очередь для ООП. Читай кея.
Хочешь конкретный пример — Dictionary с mutable ключом.
Здравствуйте, Sinclair, Вы писали:
V>>Скажу так, что ПЕРЕД началом оптимизаций, программу необходимо переписать. S>Хм. Я-то ожидал 100% предсказания результатов профайлера. Ну уж если не прямо процентовки времени вызовов, то хотя бы порядок, в котором в выходе профайлера будут идти функции. Ну да ладно, замнём. Мне важно было понять, что вы считаете заменой профайлеру.
Повторю, профайлер врет, когда подходим уже к шлифовке кода, поэтому нужен лишь для того, чтобы составить общую картинку о происходящем, расставиьт приоритет при составлении плана итераций оптимизации (для примера, при работе над последним продуктом вышло 4 итерации оптимизаций). По крайней мере, когда речь идет об увеличении производительности на порядок, причем, не за счет замены алгоритмов в терминах O(n), а сугубо за счет технических деталей, т.е. когда речь идет лишь о коэф К при O(n), профайлер уже не так хорош и даже вреден. Так вот, в смысле обнаружения узких мест опытный взгляд ловит те самые места и так. Я имел ввиду 100% совпадения относительно самих этих узких мест. Разумеется, реальная картинка в каждом случае может быть выяснена лишь в тестах на производительность, другого адекватного пути нет.
Конкретно твой пример я даже толком не смотрел, тем более не компилировал и не запускал под профайлером. Просто загорелась "красная лампочка" на "стандартной" ситуации с рекурсивным созданием энумераторов, я вернулся чуть выше и грубо оценил, от чего зависит глубина рекурсии (единственное во что вник в том коде), ну и в следующем методе увидел открытие файла, разумеетсятут же проверил откуда это вызвано, и тут же увидел, что открытие в цикле с последующим линейным (!!!) сканированием результата. Кстати, на следующей итерации оптимизаций, я бы снипет кода, который предложил добавить для сортировки слов по длине, перенес бы в утилиту формирования этого файла данных.
S>Но, тут важно вот что: не слеплять в голове понятия "мьютекс" и "делегат" в одно понятие. Потому, что когда в версии фреймворка N+1 реализацию изменят, ваши интуитивные представления о том, что медленно, а что быстро, окажутся неверными.
Не спорю, но конкретный продукт обычно выкатывается под конкретный фрейморк, который указан в официальных требованиях продукта. На самом деле это всего лишь один из моментов, как пример. И да, разумеется, совсем от делегатов никто не отказывается, мы же не идиоты, ведь шла о нагрузочном сценарии создания их в цикле, который может быть вызван в многопоточном сценарии, т.е. когда другой кто-то конкурирует за ту же операцию с делегатами. Как с этим всем бороться — вроде и так понятно, оно на поверхности — не создавать их внутри нагрузочных сценариев, а подготавливать экземпляры делегатов "заранее". Это именно то, что я имел ввиду, говоря что не надо никакого rocket science, достаточно лишь чуток здравого смысла и немного ответственности за свой код.
V>>А ты понял значение этих терминов? Bookmark Lookup — это восстановление соответствия м/у выделенным индексом и индексируемыми строками. S>Я-то понял. Вы лучше откройте-ка учебник по реляционной алгебре, и попробуйте найти в нём операцию "восстановление соответствия м/у выделенным индексом и индексируемыми строками."
Реляционная алгебра оперирует понятием "кортеж однозначно определяется ...", посмотри задачки по реляционной алгебре: аттрибуты, однозначно определяющие кортеж, дополняют символом '#' в их названиях. Выделение индекса расписывают как декомпозицию отношения с вводом нового такого аттрибута с символом '#' в обоих отношениях. Можешь такой аттрибут для удобства понимания считать за кластерный индекс.
S>Они, конечно же, не сами по себе. Тем не менее, в РА нет и не может быть никаких индексов. Потому что индексы определяются в терминах подробностей хранения данных, а их в РА нету.
Еще раз, не существует РА в вакууме, это инструмент над реляционной моделью, которая оперирует отношениями, зависимостями и ограничениями целостности. Да, ограничения целостности делаются на индексах в реальности, а отношения представляют в виде таблиц..... Однако, у тебя же не вызывает сложности использования термина "таблица"? Почему с "индексом" проблемы?.. Ну и таки стоит прочесть работу, в которой Кодд ввел само понятие реляционной модели, реляционной алгебры и реляционного исчисления. Он про индексы говорит уже в первых главах. Наверно поэтому я никогда не пытался отделять одно от другого, что это преподают совместно: реляционную модель данных, РА, реляционное исчисление и реляционные СУБД с их нормальными формами. Это общий курс изучения, где на каждый из разделов по паре лекций. Ты мне предлагаешь эту каждую лекцию ни в коем случае "не смешивать" с остальными? Это можно делать только не понимая взаимосвязи разделов внутри области "реляционные СУБД", ведь каждая из них не живет сама по себе, а оперирует понятиями смежных областей.
DG>>>соответственно, когда я вижу код: DG>>>x += "1"; DG>>>и для описания использую вышепревиденные понятия, то у меня получается следующее: DG>>>x — это ссылка, потому что обладает ссылочным контрактом (объект, конечно, тоже — потому что в ООП: всё есть объект) S>>Все есть объект — это не про понятия ЯВУ. Это про моделирование.
DG>бездоказательно.
DG>>>+= dx — это полиморфная операция обладающая контрактом: изменение объекта на величину dx S>>А откуда ты взял что это изменение объекта? DG>>>(и этим она отличается от операции +, у которой в контракте зафиксировано, что она создает новый объект) S>>В C# += это сахар для + с последующим присваиванием.
DG>согласен. был не прав, использовал контракт для += из C++.
DG>>>при этом с помощью функции referenceequals я могу сравнить ссылки на этот объект с чем-нибудь, а с помощью equals(или ==) сравнить состояние этого объекта с чем-нибудь. S>>Вот сравни ссылки, и пойми, что ты получил не изменение объекта, а новый объект.
DG>я уже давал ссылку на определение, в котором явно сказано, что разницы ссылок не следует, что объект не тот же самый
Я давал ссылку на ECMA, из которой ясно что из разницы ссылок следует что объект не тот же самый. Мы о дотнете, или о сферической ОО системе?
DG>>>если ReferenceEquals есть та самая Единая функция для проверки идентичности объектов, то почему тогда, например, Dictionary (и Hashtable) ее не использует для проверки объектов на равенство, а использует другую функцию? S>>Потому что эти классы работают на более общем отношении эквивалентности, чем идентичность.
DG>я правильно понимаю, что фактически под идентичностью вы понимаете возможность определения, что объект является сам собой же?
Нет, идентичность — это то что отличает объект от других объектов. Сама возможность определять где один объект, а где другой нужна далеко не всем программам. Если вспомнить о примере str+="dx", то возможность определять, остался ли объект сам собой, дает нам возможность разобраться в происходящем, а после мы можем написать программу без использования ReferenceEquals.
DG>для каких алгоритмов (ситуаций, задач и т.д.) это знание вообще требуется?
Умение отличать объекты — да оно не особо и требуется для программы. А вот понимание, где один объект, где другой, какому из них послалось сообщение, какой из них изменил состояние, какой породил новый и т.п. — это важно.
DG>>для каких алгоритмов (ситуаций, задач и т.д.) это знание вообще требуется? S>Умение отличать объекты — да оно не особо и требуется для программы. А вот понимание, где один объект, где другой, какому из них послалось сообщение, какой из них изменил состояние, какой породил новый и т.п. — это важно.
можно ли это сформулировать как:
в некоторых сценариях требуется понимать: где начинается один объект, заканчивается другой, и какой объект кому послал сообщение?
G>>Хочешь конкретный пример — Dictionary с mutable ключом.
DG>и что здесь не так? проблема имеет даже лобовое решение, сделать чтобы dictionary подписывался на изменение ключа
Это как минимум потребует ручного определения equals для каждого класса и реализацию INotifyPropertyChanged.
И это только один пример, таким можно тысячи придумать.
S>Я давал ссылку на ECMA, из которой ясно что из разницы ссылок следует что объект не тот же самый. Мы о дотнете, или о сферической ОО системе?
я о реальной ОО-системе, в которой есть .net, база, remoting (тот, или иной), клиентский javascript и т.д.
и в целом, для такой системы — по барабану, что там написано в ecma, потому что это никак не помогает ответить на вопрос, что есть объект, когда он размазан по трем серверам, баре базе и тысяче клиентов.
и уж точно для сравнения таких объектов будет использовать не referenceequals.
Здравствуйте, DarkGray, Вы писали:
S>>Я давал ссылку на ECMA, из которой ясно что из разницы ссылок следует что объект не тот же самый. Мы о дотнете, или о сферической ОО системе?
DG>я о реальной ОО-системе, в которой есть .net, база, remoting (тот, или иной), клиентский javascript и т.д. DG>и в целом, для такой системы — по барабану, что там написано в ecma, потому что это никак не помогает ответить на вопрос, что есть объект, когда он размазан по трем серверам, баре базе и тысяче клиентов. DG>и уж точно для сравнения таких объектов будет использовать не referenceequals.
Вопрос, что же делает такую реальную систему ОО-системой? Может быть то, что она собрана из объектов ECMA-ОО-системы, а не то, что мы не можем ответить на вопрос, что есть объект, когда он размазан по трем серверам, базе и тысяче клиентов? И уж совершенно очевидно что referenceequals не сможет ответить на вопрос, что есть объект, т.к. в "реальной ОО-системе" даже авторы не могут ответить на вопрос, что есть объект. Вроде как от ECMA идентити ушли, а к своей не пришли. Так вот, согласно ECMA, эта реальная identity будет всего лишь эквивалентностью, и то лишь при условии выполнения ряда условий из определения эквивалентности.
Ничего общего у реальной айдентити с ОО-айдентити наблюдаться не может. Вот послал я объекту сообщение, изменяющее состояние, а почему-то объект с той же "реальной" identity на тысяче остальных клиентов, на это не среагировал. Ну и причем тут ООП?
S> Так вот, согласно ECMA, эта реальная identity будет всего лишь эквивалентностью, и то лишь при условии выполнения ряда условий из определения эквивалентности.
и фиг с ним. в каких сценариях это будет аукаться?
мы вон уже выяснили, что даже double полностью не поддерживает идентичность (рефлексивность сооблюдается только на подмножестве всех значений)
и когда это последний раз аукалось? и в каких сценариях нельзя рассматривать double (переменную типа double) как объект?
или возьмем реальный пример: версионный объект (двух типов). версионный объект при определенных изменениях создает версии своего состояния.
объект с версионностью первого типа: создает версию, если явно его об это попросить
var xv = x.FixVersion();
var y = x;
y.Change1();
во втором сценарии, версия объекта создается автоматически при изменении объекта
var y = x.Change1();
в обоих этих сценариях появляется две плоскости:
ecma-объекты и логические объекты. (и те и другие удовлетворяют ОО-модели).
что здесь является функцией идентичности для логических объектов?
кстати, эти обе версионности являются эквивалентными: через адаптер можно одну версионность преобразовать к второй версионности, и наоборот.
первый вариант версионности назовем backup-версионность
второй вариант версионности назовем immutable-версионность
immutable-версионность обладает интересным свойством: ссылка x всегда ссылается на ту версию объекта, которой была проинициализирована, вне зависимости от того, в какой момент времени был произведен реальный вызов.
и оказывается, что для сложного кода со сложными оптимизациями (lazy, создание по требованию и т.д.) удобнее работать с объектами с immutable-версионностью: потому что при lazy есть состояние неопределенности, когда произойдет реальный вызов, а immutable-версионность гарантирует, что даже несмотря на эту неопределенность поведение всегда будет одним и тем же.
соответственно, подбирая под каждую неопределенность объекты с определенным поведением(контрактом) можно последовательно сделать так, чтобы неопределенности не мешали выдавать определенное поведение.
S> Вот послал я объекту сообщение, изменяющее состояние, а почему-то объект с той же "реальной" identity на тысяче остальных клиентов, на это не среагировал. Ну и причем тут ООП?
отличное ООП, просто в контракте на такое сообщение написано, что сообщение может не дойти.
и отдельно оговаривается, что происходит если не дошел запрос к объекту, и отдельно, если не дошел ответ от объекта.
и при этом простую ООП-архитектуру можно строить даже поверх таких особенностей(ограничений).
тут, кстати, опять же помогают объекты с версионностью второго типа, когда мы четко знаем, какая ссылка на какую версию объекта ссылается. для таких объектов код для разрешения потери сообщения через несколько повторов сообщения пишется элементарно (делаем допущение, что потеря сообщения формирует исключение, в том числе и через клентский-timeout, если ответ не пришел через заданное время):
var y = x.Try(3, _=>_.Change1());
static T Try<T>(this T x, int count, Func<T, T> action)
{
for (int i = 0; i < count; ++i)
{
try
{
return Action(x);
}
catch (Exception exc)
{
if (i == count - 1)
throw;
}
}
throw new ArgumentException("count");
}
для объектов без версионности, или с backup-версионностью — рассмотрение всех вариантов (сообщение не дошло; сообщение дошло, но объект отказался его обрабатывать(вернул исключение); не дошел ответ и т.д.) и написание кода для корректной обработки всех вариантов — это очень сложная задача, чем обычно и пренебрегают, что видно на реальных программах.
Здравствуйте, DarkGray, Вы писали:
S>> Так вот, согласно ECMA, эта реальная identity будет всего лишь эквивалентностью, и то лишь при условии выполнения ряда условий из определения эквивалентности.
DG>и фиг с ним. в каких сценариях это будет аукаться?
Ты уже подменяешь тему разговора. Ведь изначально ты говорил о том что ReferenceEquals не является индентичностью в CLR. Но со спекой спорить бесполезно, теперь ты пытаешься выдумать свою ОО-систему, для которой выдумываешь идентичность, не совпадающую с ООП-идентичностью.
DG>мы вон уже выяснили, что даже double полностью не поддерживает идентичность (рефлексивность сооблюдается только на подмножестве всех значений) DG>и когда это последний раз аукалось? и в каких сценариях нельзя рассматривать double (переменную типа double) как объект?
В любых. Все value-типы не являются объектами в смысле ООП
DG>или возьмем реальный пример: версионный объект (двух типов). версионный объект при определенных изменениях создает версии своего состояния.
DG>объект с версионностью первого типа: создает версию, если явно его об это попросить DG>
DG>var xv = x.FixVersion();
DG>var y = x;
DG>y.Change1();
DG>
DG>во втором сценарии, версия объекта создается автоматически при изменении объекта DG>
DG>var y = x.Change1();
DG>
DG>в обоих этих сценариях появляется две плоскости: DG>ecma-объекты и логические объекты. (и те и другие удовлетворяют ОО-модели).
Вторые не удовлетворяют. Для объектов в ООП нужно: а) отношение идентичности б)если А иднетичен Б, то любое изменение А сразу отражается на Б. Это и есть определение ОО-идентичности. Вообще говоря идентичность в не-ОО среде является одним из отношений эквивалентности.
DG>immutable-версионность обладает интересным свойством: ссылка x всегда ссылается на ту версию объекта, которой была проинициализирована, вне зависимости от того, в какой момент времени был произведен реальный вызов.
Ты удивишься, но для immutable идентичность не нужна,она полностью изоморфна эквивалентности. В этом плане кстати ФП, которое опирается на immutable, не является в полной мере ОО. Но это уже философия.
S>> Вот послал я объекту сообщение, изменяющее состояние, а почему-то объект с той же "реальной" identity на тысяче остальных клиентов, на это не среагировал. Ну и причем тут ООП?
DG>отличное ООП, просто в контракте на такое сообщение написано, что сообщение может не дойти. DG>и отдельно оговаривается, что происходит если не дошел запрос к объекту, и отдельно, если не дошел ответ от объекта. DG>и при этом простую ООП-архитектуру можно строить даже поверх таких особенностей(ограничений).
Тут другой вопрос. Основное свойство identity: если А иднетичен Б, то любое изменение А сразу отражается на Б. В распределенной среде ты не сможешь этого гарантировать. Смотри CAP-теорему.
Если же рассматривать только immutable, то оно не является в полной мере ОО-системой.
Здравствуйте, Sinclair, Вы писали:
S>Я-то понял. Вы лучше откройте-ка учебник по реляционной алгебре, и попробуйте найти в нём операцию "восстановление соответствия м/у выделенным индексом и индексируемыми строками."
Кстати, прочел еще раз... выделенное любопытно. А что за учебник-то? В любом учебнике по реляционным СУБД предмету РА посвящается одна (практически самая маленькая) глава. А если ты пройдешься по задачам или обсуждениям по этой теме, то увидишь, что когда речь идет о РА, всегда подразумевают так же низлежащую реляционную модель, а задания по РА почти всегда идут в виде реляционного исчисления.
Сдается мне, что из плоскости обсуждения абстракций мы незаметно перескочили в плоскость обсуждения фундаментных наук vs прикладных. А там ведь обсуждать нечего. Фундаментальные науки от прикладных отличаются лишь универсальностью и более ничем. Например, теория матриц — раздел фундаментальной науки, и я могу навскидку назвать более десятка ее несвязанных приложений. В то время как законы Ома не живут вне Теории цепей, т.е. просто не имеют смысла. Поэтому, когда речь идет о законах Ома, то вся терия цепей автоматически подразумевается как контекст. Ну и в реляционных БД тоже, РА не является самостоятельной прикладной наукой, а является разделом и живет исключительно в контексте теории реляционных БД, вот которая уже и является самостоятельной прикладной наукой. Т.е. является некоей "единицей" знаний. Ну и насчет объемов "знаний" тоже любопытное вышло наблюдение. Если матричное исчисление — это нехилый объемный аппарат, то законы Ома или РА — это сравнительно малое кол-во примитивных формул/операций... в общем, это такой объем "знаний", которые на отдельный учебник претендовать никак не могут. В общем, в плане связи разделов наук друг с другом стоит понимать, что первично, а что вторично. Законы Ома — это инструмент для Теории цепей, которая сама обслуживает задачу вычисления параметров цепей. А в Теории реляционных БД первичная задача — это реляционное исчисление (для нее, родимой, это всё), а РА выступает как подчиненный инструмент для расчетов/реализации этой первичной задачи.
В общем, коль речь зашла о том, насколько "монолитно" у меня в голове это сидит, то скажу, что РА у меня не просто на "одной книжной полке" рядом с СУБД, а максимум одна из глав в одной и той же книге. Т.е. я не умею и не собираюсь оперировать сими понятиями в отрыве друг от друга, по той причине, что РА в отрыве от теории реляционных БД не имеет ни физического, ни математического смысла.
Здравствуйте, vdimas, Вы писали:
V>В общем, коль речь зашла о том, насколько "монолитно" у меня в голове это сидит, то скажу, что РА у меня не просто на "одной книжной полке" рядом с СУБД, а максимум одна из глав в одной и той же книге. Т.е. я не умею и не собираюсь оперировать сими понятиями в отрыве друг от друга, по той причине, что РА в отрыве от теории реляционных БД не имеет ни физического, ни математического смысла.
Ваша позиция понятна. Не вижу смысла продолжать дальнейшую дискуссию, т.к. мы расходимся по принципиальным вопросам. Вы не умеете и не хотите выделять отдельные "слои" понятий — это ваше право. Вы можете искренне считать, что SQL пользуется реляционной моделью, или что в реляционной алгебре есть место подробностям реализации вроде индексов, страниц, кластеризации и прочих потрошков СУБД. Совершенно не факт, что это будет лично вам мешать писать вполне успешные приложения.
Лично мне такое смешение сущностей кажется совершенно диким, но пусть это останется моей проблемой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
G> б)если А иднетичен Б, то любое изменение А сразу отражается на Б. Это и есть определение ОО-идентичности.
гон и провокация, и опять же нарушение инкапсуляции. мы не можем утверждать когда именно оно применится, мы можем лишь делать утверждения на основе наблюдамого поведения.
и правильная формулировка: в ООП объект А и объект Б считаются одним и тем же(идентичными), если конкретное поведение объекта А и конкретное поведение объекта Б не отличимо друг от друга.
и из этого следует, что:
во-первых: изменение примененное к объекту A _лишь_ должно быть учтено в объекте Б не позднее, чем объект Б сформирует ответ на функцию, которая могла бы выявить, что объект Б отличается от объекта А (ни о каком "сразу" речь не идет)
во-вторых: stateless-объекты вообще таким ограничением не обладают, потому что в контракте у них нет методов, меняющих их состояние, и из этого следует — что, например, два(и более) stateless-объекта, имеющие один и тот же автомат-поведения и созданные с одними и теми же настройками можно считать одним и тем же объектом (идентичными).
из первого пункта, например, следует что объект A и объект Б(который является транспарент-proxy над объектом A) есть один и тот же объект, при этом ни о какой "сразу"-применимости изменений объекта А к объекту Б говорить нельзя
S>Можете продемонстрировать на простом примере? Вот в этой несложной программе, где именно боттлнек (чур, профайлер не запускать):
для точного определения ботлнека не хватает статистики(или экспертных оценок):
как часто используется ?, какое распределение запросов по длине rack, какое распределение слов в словаре по длине,
насколько тормозит файловая система, и как часто файл словаря попадает в memory-кэш ос.
вычислительное узкое место в этом сравнении
return from line in FileLines(dictionary)
where line.Length == originalRack.Length
where racks.Contains(Canonicalize(line))
select line;
сложность: 27 вызовов * кол-во слов в словаре с заданной длиной * (sort слова + (1+26 * кол-во '?') сравнений слов)
И скорее всего именно поэтому его уже пытались оптимизировать (вынесен racks и добавлено сравнение длин).
racks стоит заменить на Set/Dictionary вместо массива
алгоритмический bottleneck в строках:
foreach (char c in "ABCDEFGHIJKLMNOPQRSTUVWXYZ")
Console.WriteLine("{0}+{1} : {2}", rack, c, SearchDictionary(rack + c).Join());
их стоит заменить на
SearchDictionary(rack + "?") с последующей группировкой ответов по добавленной букве
далее стоит сделать сравнение по образцу вместо перемножения
образец разбивается на две части: определенные отсортированные буквы и кол-во ?
на основе строки формируются последовательно отсортированные перестановки с длиной по кол-ву определенных букв в образце
оба этих изменения дадут уменьшение узкого места до:
кол-во слов в словаре с заданной длиной * (sort слова + С(n-1, 1 + кол-во '?') * сравнений букв)
дальше можно заниматься всякими доп. оптимизациями:
вынос построения словаря из под цикла
(при необходимости)замена array.sort на свою сортировку, заточенную под сортировку коротких массивов из небольшого набора символов
(при необходимости)чтение всего(или большими кусками) словаря в stringbuilder и там же его обработка в виде набора символов без создания отдельных экземпляров строк
(при необходимости) замена char-ов на байты
(при необходимости) четырех-символьное сравнение за раз (через представление строк через int)
Здравствуйте, DarkGray, Вы писали:
DG>для точного определения ботлнека не хватает статистики(или экспертных оценок): DG>как часто используется ?, какое распределение запросов по длине rack, какое распределение слов в словаре по длине, DG>насколько тормозит файловая система, и как часто файл словаря попадает в memory-кэш ос.
Правильно. Речь именно о том, что для оптимизации нужно применять сбор статистики, а не гадание в уме.
Ваше предсказание основных узких мест получилось лучше, чем у vdimas. Но запуск профайлера всё равно был бы дешевле и точнее.
V>>В общем, коль речь зашла о том, насколько "монолитно" у меня в голове это сидит, то скажу, что РА у меня не просто на "одной книжной полке" рядом с СУБД, а максимум одна из глав в одной и той же книге. Т.е. я не умею и не собираюсь оперировать сими понятиями в отрыве друг от друга, по той причине, что РА в отрыве от теории реляционных БД не имеет ни физического, ни математического смысла. S>Ваша позиция понятна. Не вижу смысла продолжать дальнейшую дискуссию, т.к. мы расходимся по принципиальным вопросам. Вы не умеете и не хотите выделять отдельные "слои" понятий — это ваше право. Вы можете искренне считать, что SQL пользуется реляционной моделью,
Синклер, ты демагог в запущенной стадии этого заболевания, сорри. При чем тут вообще SQL? В 10-й раз!
Ну это же нубство натуральное путать реляционное исчисление, реляционную алгебру и язык SQL. Тем более, что всю взаимосвязь м/у ними тебе оппонент уже дал.
S>или что в реляционной алгебре есть место подробностям реализации вроде индексов, страниц, кластеризации и прочих потрошков СУБД. Совершенно не факт, что это будет лично вам мешать писать вполне успешные приложения.
Я лишь вижу, что ты рассуждаешь о том, о чем на сегодня поленился пройтись хотя бы краем глаза. Вроде уже все входы и выходы я тебе показал, — конкретно, что что РА оперирует над реляционной моделью. Ну дык, стоило бы пройтись по реляционной модели или как? Или опять легче просто ответить "вы путаете SQL и РА". Это же все желание отпадает впредь что-то обсуждать на таком уровне. Смысл? Ты умудряешься повторяться относительно своих же нескольких постов назад, проявляя игнор к аргументам оппонента...
S>Лично мне такое смешение сущностей кажется совершенно диким, но пусть это останется моей проблемой.
Для начала надо понимать, откуда эти сущности берутся. Если пройтись только по несчастным 7-ми операциям, составляющим собственно реляционную алгебру, но пропустить реляционную модель и не прорешать хотя бы пару десятков задач по РА, то в голове может начать твориться что угодно. Я здесь при чем? ИМХО, это может происходить только от непонимания взаимосвязи разделов обсуждаемой прикладной науки — "теория реляционных БД". Крайне рекомендую к прочтению тот самый знаменитый труд Кодда, в которой он представил сию прикладную науку. Все-таки, у любой прикладной науки, в отличие от фундаментальной, обязательно "откуда-то растут ноги". Тем она от фундаментальной и отличается. Любая прикладная наука обязательно представлена как законченное инженерное решение: постановка задачи, анализ, пути решения, выводы. Нельзя понахвататься по верхам, по отдельным элементам некоей прикладной науки, потому как легко упустить взаимосвязь всех компонент этого "решения"... После ознакомления с рекомендованной работой можно было бы продолжить обсуждение, если еще останутся доводы и желание.
Ну и, раз тебя так влечет пример SQL... Не из SQL растут ноги, теории реляционных БД, конечно.
Наоборот, сам SQL растет из реляционного исчисления, но и это не принципиально, бо многие диалекты SQL включают непосредственно операции из РА. Языков, подобных SQL, могло бы гораздо более одного, даже странно, что в ходу разных диалектов очень похожий "общий корень", ну так уж случилось исторически. ИМХО от того, что сама теория реляционных СУБД появилась относительно поздно (я уже родился ), и стандартизация аспектов IT была уже в ходу.
Ну и тыкать в оппонента SQL-ем, это все равно что приписывать ему понимание императивного программирования исключительно в виде языка Паскаля, например... где-то так...
