Евгений Мирошниченко aka mir
Если попробовать взять уже существующие аксиоматические концепции, то объект -- переменная, а состояние -- значение этой переменной. ... т.к. переменная существует в пространстве и времени и отличается от других переменных.
Комментировать нечего. Полный бред. Сам то понял, что сказал?

Guest
Чем вам так дорога эта алгебра РМ ? Я ни разу не использовал ее в своей работе.
... В чем прелесть АЛГЕБРЫ ?
Непонятно почему именно наличие "реляционной алгебры" рассматривается как большое преимущество.
Каким образом этот математический формализм позволяем упростить получение результата?
Алгебра нужна для следующих целей: 1. как защитный политический механизм или крыша, 2. Это помогает выстроить более строгую цепочку рассуждений.
Но по большому счету, сама алгебра в мат. смысле конечно никому в моделированни данных не нужна - ни в теории, ни тем более на практике.

alexeyvg
join, where, exists - это и есть алгебра, т.е. так указываются операции над множествами.
Ну тогда выбор бананов домохозяйкой в супермаркете это тоже алгебра, и одновременно еще и квантовая механика, ведь бананы из квантов состоят и подчиняются ее законам.

_мод
Это вам так кажется - любой select это уже операция рел. алгебры. Без нее с таблицами нельзя работать.
Почему реляционной алгебры? До реляционной алгебры не было выборки из таблиц? Если уж говорить о характерный особенностях, то лучше начать с join (и на этом же закончить). Операция весьма неоднозначная и на данный момент очевидно вредная (хотя в свое время прорывная).

_модЭто не преимущество, а необходимость. Что-бы сложить 2+2 нужна операция +.
Это в математике - там свои законы, которые часто хотят использовать не по назначиению. А в информатике для нахождения 2+2 можно, например, использовать процедуру, или сообщения, или переход между состояниями.

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

Сахават"Верный" дизайн подразумевает бесконечное количество сущностей.
В информатике нет бесконечности (и потому это не математика). Наверное имелось в виде "неограниченное" (что впрочем, тоже сильное отверждение).

_мод
А вот в программном смысле в РМ событием является любые операции, что и используется в триггерах СУБД.
Ну так есть в РМ события или их нет? А то как-то некрасиво получается: в теории их нет, а вот когда рапортавать об успехаъх, то сразу появляются всякие интересные вещи.
_модПри использовании СУБД, в которых нет SQL приходится вручную моделировать (программировать) те же операции рел. алгебры.
Правильно. Но только надо договарить: при наличии SQL приходится на нем вручную моделировать (программировать) другие модели - но зачем такие мучения, никто не знает.

Guest
А вот создание и удаление объекта, на мой взгляд, является операцией.
Есть две совершенно разные операции: создание переменной и создание объекта. Но с алгеброй это почти никак не связано.

_мод
Экземпляр объекта - это и есть переменная.
Экземпляр объекта - это ссылка. А переманная - это где она хранится. Совершенно разные понятия.

U-gene
Преимущества рел алгебры еще более на виду. Берешь (одно, два...n) отношений (то есть множеств) и опана - получаешь новое отношение (множество). множество кортежей, записей если угодно.
А кто сказал, что представлять данные в виде отношений, это есть хорошо? В реальной жизни никто так не делает. Получается, что сами себе создаем проблемы, а потом хвастаемся, что нашли для них хитрое решение. И в этом ценность РМ? Проще говоря, а зачем нам сперва представлять данные в виде нескольких отношений (создать проблему), а потом заниматься нахождением того, что реально нужно через какие-то хитрые операции?
U-geneА нет такого формализма и приходится пользоваться циклами, вложенными. Вы сами прикиньте, что стоит в циклах сделать SELECT атрибутоа FROM две связанные таблицы WHERE какиенить условия да еще и ORDER BY впридачу (хотя ORDER by уже и не операция рел алгебры, ну да ладно :) ).
Не в циклах дело - даже если мы в какой-то ЯП введем что-то типа select, или даже join, то в рел.модель он не превратится. Я бы даже сказал, что можно вполне оставить циклы и получить очень приличную модель данных.

ой извините пьяный был не понял какую чушь писал

U-gene
(-).. ничего что я вас в перооде пишу? так быстрее :) навигация с использованием синтаксиса d.client.department.name и подавно удобней реляционных джойнов В общем да. Самое итересное, что одно другому не мешает. В смысле навигачия может быть реализована Join'ами, а Join'ы могут соединять навигационные выражения. Беда только, что это мало кто понимает.
Это уже более содержательное утверждение, но все-таки слишком поверхностное. Я бы сказал, что есть очень серьезные (глубинные) причины, почему это не сделано (не получается сделать). Объеденить РМ и join'ы конечно проблем нет, но никакого прорыва не будет - возможно несколько меньше писанины в запросах. Это примерно как попытки Дейта и Ко механически прикрутить к РМ теорию типов так, чтобы было два ортогональных направления моделирования - ничего не вышло, поскольку слишком наивно.