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

Д>>Потому что та вещь, которую ты понимаешь под "ООП вообще" — это всего лишь одна из реализаций оного, и далеко не самая "продвинутая"
M>С чего ты взял? Еще раз, я про реализацию не говорил ни слова.

потому что это видно из твоих слов. Динамически типизированные языки ты не рассматривал в контексте данного вопроса вообще, разве нет?

Д>>То есть ты считаешь что фундаментальные проблемы, присущие "ООП вообще", всё-таки есть. Осталось только понять, почему их нельзя решить никакими силами, и тогда мы наконец придем к консенсусу
M>Ну вот опять. Я говорил о задачах, которые неудобно решать с помощю ООП — ни больше не меньше. И ты согласился, что такие задачи есть, о чем спорим?

о том, что эти неудобности можно будет решить. Именно поэтому я пытался из тебя выбить более детальную информацию. Безуспешно пытался, надо признать — ты был стоек

M>Тебе напомнить сколько времени прошло после публикации первой статьи, до появления успешной реализации реляционной базы, которая далеко задвинула все альтернативные подходы?

ну напомни.

M>Зачем тебе детальный список, если ты сам признался, что проблемы есть?

затем, что если проблемы есть — значит, надо пытаться их решать. Логично?

M>Какие, конкретно идеи, которые не выходят?

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

Д>> Чем хранимые процедуры и триггеры принципиально отличаются от внедрения ООП в базу?
M>Тем, что они не закрывают доступ к данным.

ну вот, уже какая-то конкретика.

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

если считать под этим понятием "код вообще", то да, будет требовать. Если гранулировать код более мелкими деталями, например — методами, то ничего подобного не предвидится. Вообще говоря, необходимость добавлять методы, которые работают непосредственно с private данными, встречается довольно редко. Намного чаще добавляются методы, которые работают с данными объекта через публичные аксессоры. Вполне очевидно, что добавление такого метода в принципе не может ничего сломать.

M>В том то и дело, что изменится только код, а данные останутся теми же.

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

M>Это следует из того, что в ООДБ данные обернуты в код и получить доступ к данным помимо кода неполучится.

и не надо! Доступ ко всем данным уже открыт через методы чтения и модификаци.

M>То есть все-таки можно? Уже прогресс... Это во-первых. А во вторых, количество "чего менять" в существующем коде величина разная и когда доступны плоские данные, если придется менять, при изменении требований, то существенно меньше.

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

Д>>Инкапсуляция данных дает возможность гарантировать соблюдение этого правила, запрещая прямой доступ к данным, вместо того чтобы решать программные задачи административными средствами.
M>Только гарантированное соблюдение этого правила через логику прибитую гвоздями к данным — еше большее зло, чем кодер вася пупкин.

почему — зло?

Д>>теорию РБД придумали в 1970 году, если мне память не изменяет. Посчитать промежуток времени сам сможешь, или тебе помочь?
M>Вот и посчитай, промежуток времени между первой коммерческой реализацией и тем как такой подход вытеснил все альтернативные с рынка.
M>Попыткам же создать ООБД уже лет пятнадцать, можешь сравнить.

а какую первую реализацию РБД можно считать полноценной по современным меркам?

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

GZ>>2. Есть некоторая разница между Select(o).Including(o.Product) и Select(new {o, o.Product}). Первый возвращает дерево объектов, второй возвращает новый тип.
S>Не, никаких деревьев. Я вообще не понимаю, что должно вернуться в результате Select(o).Including(o.Product) и чем оно будет отличаться от Select(o).
В Select(o) будет возвращен только объекты o. В случае Select(o).Including(o.Product) возвращаем те же o, но только с инициализированным свойством Product. Если Product свойство, то свойство. Если Product коллекция — то коллекцию. Все просто, корректно и очень вкусно.
S>Я совершенно не против возвращения новых типов. Скорее даже за.
Для типов нужен адекватные анонимные типы. А судя по сообщению Андрея, в самом ближайшем будущем его ожидать не стоит. Поэтому данная функциональность пока будет достаточно неудобной.

S>Совершенно верно. Теперь это просто данные.
Если ты заметил, вначале вначале шел разговор об OODB.

S>Совершенно верно. Обновлять можно только сами объекты. Если мы в результате проекции вытащили, как я предлагал, o.Amount и o.Product.FullName, то никаких чудес не будет — это просто {decmial, string}. Нужно вытащить именно OrderItem, тогда можно будет попытаться его менять.
Ага.
S>А еще лучше делать так:
S>

S>DataBase.Extent<OrderItem>.Select(itemId).Apply(delegate(OrderItem item) { item.Amount *= 2; });
S>

S>Подразумевается, что это эквивалентно SQL^
S>

S>update OrderItems set _amount = _amount * 2 where _id = @itemId
S>

S>(в предположении, что геттер и сеттер для Amount тривиальны).
Ага. Эта штука, лично мне, нравится. Только надо делать несколько путей для апдейтности. Например бывает основной апдейт через коллекции. Дают коллекцию и говорят, валяй пиши в базу данных. Как в датасете. IMHO Это в принципе частый вариант использования.

S>Основная фишка — в правильном разруливании блокировок и прочей мути. Если мы загрузили объект в рамках одной транзакции, а меняем в другой — есть риск умножить на два совсем не то что нужно. Апдейт по предикату гораздо лучше поддается сериализации.
В данном случае ты сразу подразумеваешь пессимистический протокол транзакций на блокировках. Можно сделать пессимистически сериализуемой через блокировки только операции. В остальном работать по оптимистическому протоколу. Тогда удерживать блокировки между операциями не надо, и можно строить транзакции от read commited до serializable(если с предикатными блокировками).

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

S>Здравствуйте, GlebZ, Вы писали:
GZ>>Это весь набор низкоуровневых операций современной RDBMS?
S>А что, я что-то пропустил? Неужели bookmark lookup?
IMHO Фактически, минимальный набор джентельмена —
1. Сканирование таблицы,
2. Чтение кортежа
3. Сканирование индекса
4. Чтение значения индекса по ключу.
А фактически хрен его знает. Даже в этом минимальном наборе нет места index range search. Не попадалась документашка, в которой бы было описано какие операции делаются на уровне хранилища(ну пожалуй кроме SystemR, которую современной уже не назовешь). Возможно это можно узнать в Starburst. Там программируемый оптимизатор.

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

Д>>объект — это совокупность данных и методов, которые их обрабатывают в соответствии с требованиями. Если требования меняются, то меняются и методы. Тебя в этом что-то удивляет?
M>Меня это не удивляет, меня удивляет зачем при этом методы хранить вместе с данными, таким образом, чтобы до данных в обход этих методов добраться было нельзя. Ведь хранить данные отдельно гораздо проще и гораздо меньше проблем при изменении.

С этим я согласен. Однако данный подход на уровне реализации не отменяет возможности предоставлять пользователю СУБД не голые данные, а целостные объекты с некоторым поведением.

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

M>>>Вот скажи мне, так ли нужно наследование в ООП?
S>>Желательно но необязательно. Я поддерживаю.

ie>На самом деле отличие ООП от объектного программирования, заключается как раз в наследовании. Нет наследования — нет второй буквы "О" в ООП.

S>>К примеру VB6 ОО язык без наследования. Благодаря adhoc полиморфизму на нем можно реализовать все теже паттерны, что и на C++ с множественным наследованием.

ie>Но как это все криво! Уж не кривизне ли нам стоит стремиться?

Криво — не значит невозможно. Если в языке без наследования можно сделать все те же паттерны что в языке с наследованием, причем паттерны, ориентированные на наследование — то тезис "наследование не обязательно" можно считать доказанным.

с другой стороны, наследование вещь очень полезная и очень удобная. В своей ООСУБД я его поддерживаю.

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

Д>потому что это видно из твоих слов.
Как это может быть видно из моих слов, если я ничего подобного не говорил?

Д>о том, что эти неудобности можно будет решить.
Решить можно проблемы, но удобства это решение не прибавит.

Д>ну напомни.
Меньше четырех лет.

Д>затем, что если проблемы есть — значит, надо пытаться их решать. Логично?
Ну решай, есть идеи? Ну а пока ты решаешь, я буду пользоваться теми средствами, где этих проблем нет.

Д>динамическая типизация. В сфере персистентного хранения данных должно неплохо работать. Ну как, куда она выходит за границы ООП?
И это новая идея? И где ООБД, с использованием динамической типизации, которая рвала бы реляционку на достаточно широком классе задачь?

Д>ну вот, уже какая-то конкретика.
Ну да, наконец-то ты смог это заметить...

Д> Вообще говоря, необходимость добавлять методы, которые работают непосредственно с private данными, встречается довольно редко.
Это потому что у тебя всегда есть возможность обратиться к данным напрямую.

Д> Намного чаще добавляются методы, которые работают с данными объекта через публичные аксессоры. Вполне очевидно, что добавление такого метода в принципе не может ничего сломать.
Вот-вот, вернулись к тому с чего я начинал, пытаемся строить обертки и адаптеры над существующими классами, чтобы добраться до нужных данных в нужном виде.

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

Д>и не надо! Доступ ко всем данным уже открыт через методы чтения и модификаци.
Значит опять возвращаемся к тому с чего начали. Либо у нас нет инкапсуляции, раз доступ полностью открыт, либо есть и объект придется-таки менять. И если-таки доступ ко всем данным есть, то он, с некоторой вероятностью, окажется совсем не тот, который хотелось бы — ну не такой объект возвращается, значит надо опять городить адаптеры...

M>>То есть все-таки можно? Уже прогресс... Это во-первых. А во вторых, количество "чего менять" в существующем коде величина разная и когда доступны плоские данные, если придется менять, при изменении требований, то существенно меньше.
Д>практика показывает прямо противоположное.
Практика показывает, что если две части системы обладают сильной связью, то изменение одной части повлияет на изменение в другой, в меньшей степени, чем если бы эта связь была слабой?!! Вот это действительно что-то новое, даже не в ООП а в принципе в программировании.

Д>почему — зло?
Потому что выливается в больший геморрой.

Д>а какую первую реализацию РБД можно считать полноценной по современным меркам?
При чем здесь современные мерки? За те пятнадцать лет, что пытаются создать ООБД, реляционки прошли путь от идеи до тотального господства.

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

AVK>>>Твои слова. Вот мне и интересно что ты там собрался дописывать.
GZ>>"Можно будет" и "надо" — у этих слов разные смыслы.
AVK>Так, понятно. Морфологию обсуждайте без меня.
Это было пояснение по поводу твоей интерпретации моих слов. Я заранее предупредил, что пророком не буду потому что не прояснял для себя сам вопрос.

AVK>Насколько я понял — все таки ты согласен с тем что LINQ в том виде, в котором он сейчас, никаких революций в ООБД не совершит?
Поживем увидим. Еще Linq как такового нет.

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

AVK>Ничего выдающегося я здесь не увидел. Для меня максимально логичным будет такой вариант:
AVK>

AVK>var x = a.Where(a=>a.LogDelete == true)
AVK>

AVK>И никакого засирания публичного интерфейса, максимальная гибкость и читаемость.
У меня функция выбора между логическим удалением объекта и физическим удалением объекта достаточно нетривиальна. И сильно зависит от самого объекта. Поэтому предпочитаю инкапсулировать данную функциональность, чтобы другим не мешало.

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

AVK>>И никакого засирания публичного интерфейса, максимальная гибкость и читаемость.
GZ>У меня функция выбора между логическим удалением объекта и физическим удалением объекта достаточно нетривиальна. И сильно зависит от самого объекта. Поэтому предпочитаю инкапсулировать данную функциональность, чтобы другим не мешало.

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

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

GZ>Для типов нужен адекватные анонимные типы. А судя по сообщению Андрея, в самом ближайшем будущем его ожидать не стоит. Поэтому данная функциональность пока будет достаточно неудобной.

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

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

S>>- инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП.
S>Гм. Тогда совершенно непонятно, зачем вообще придумывать какую-то ОБД. Ведь неинкапсулированные данные и так ездят сумасшедшими темпами — десять тысяч обработанных заказов в минуту. И это на потребительском железе, т.е. машинке типа той, с которой я это пишу!

Ездят куда? Если в гриды или отчеты — это одно. А если в объекты бизнес логики — это другое. По любому на ORM будут затраты. Их можно избежать. А в гриды и отчеты данные как и раньше отправлять мимо методов.

S>>В своей ОБД я пришел к следующему.
S>>- инкапсуляция не рекомендуется к применению. Поля объекта открыты для доступа независимо от методов самого объекта. К этим полям система может обращаться не инстанциируя сам объект.
S>Таким образом, ты спустил ООП в мусорную корзину. Если объекты устроены таким образом, то все преимущества ООП недостижимы, а весь полиморфизм сводится к выбору подходящей хранимой процедуры.

Это и не только. В моей ОБД не используется реляционная модель данных. Я применяю сетевую модель. Если учитывать и сеть — то да, вот и вся моя СУБД. Сеть + к узлам выбор СП ассоциированной с узлом.

S>Этот выбор и так есть — RDBMS супротив самописанного хранилища.

Вот я оценил возможности RDBMS и выбрал самописанное хранилище. Действительно доволен выбором.
Жаль тока в самописанке пока мультиюзера нет. Это мешает. Остальное тока радует. Впрочем, индексов еще не хватает, ну то невелика потеря, меня в силу обстаятельств интересуют только те алгоритмы которые не пользуются поиском в принципе. Исключительно навигация по указателям. А РБД для таких вещей — смерть


S>View не является аналогом инкапсуляции. В каком-то смысле, можно его и так рассматривать, но в существующем виде это скорее инструмент декомпозиции. В SQL с декомпозицией вообще очень плохо; в большинстве случаев все запросы пишутся прямо поверх самого нижнего уровня. От этого стоимость внесения изменений в систему зашкаливает, и в некоторых случаях начинаются моления на схему данных. Типа — вот этот бы столбец убрать нафиг, ибо никто не помнит, для чего он был придуман, а нельзя — вдруг отчеты посыплются.

Ну композиция-декомпозиция это вопросы головной боли разработчика. А что делать через год эксплуатации, если нужно схему данных/объектов изменить, а перекомпилить старые приложения возможности нет? Вот тут VIEW как раз и будет той самой инкапсуляцией, причем жизненно необходимой.

S>В свете этого, не вполне ясно, какую именно проблему предполагается решать при помощи твоих объектных VIEW.

Поддержки жизни системы в протяжении долгого времени. + дополнительные не критические удобства. Я на этой штуке аналог foreign key к своей БД прикрутил.

S>Бр-р. Это уже какая-то мистика начинается. Не представляю себе, как это атрибут ухитряется разделяться между экземплярами.

Хм. Обяснять здесь этот момент получаецца беспредметно. Если есть действительно сильное желание разобраться — скачайте Cerebrum и поиграйтесь. Наверняка все станет прозрачно — и решите, надо оно вам такое или нет. http://www.shuklin.com/ai/ht/ru/cerebrum/


S>Если отказаться от type inference, который так ловко был придуман в OQL, то самое сложное — это изобретение эффективной стратегии выполнения запросов типа: ... На первый взгляд, это вообще труба, т.к.

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

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

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

S>>Время нас рассудит.
M>Время уже расудило.
M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату — ни одной полноценной ООБД успешно проявившей себя

Если ООП движется к закату, что возникло вместо?

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

M>Как это может быть видно из моих слов, если я ничего подобного не говорил?

на вопрос ты опять не ответил

M>Решить можно проблемы, но удобства это решение не прибавит.

Если другие проблемы можно решить, то проблемы с удобством тем более можно решить.

M>Меньше четырех лет.

то есть первая полноценная реализация РБД появилась в 1974 году? И что это за программа была, можешь точнее рассказать?

M>Ну решай, есть идеи? Ну а пока ты решаешь, я буду пользоваться теми средствами, где этих проблем нет.

Я рад за тебя, если тебя и так всё устраивает. Честно Меня — нет.

M>И это новая идея? И где ООБД, с использованием динамической типизации, которая рвала бы реляционку на достаточно широком классе задачь?

сколько там прошло времени с начала развития ООБД, не напомнишь?

M>Ну да, наконец-то ты смог это заметить...

потому что появилось, что замечать.

Д>> Вообще говоря, необходимость добавлять методы, которые работают непосредственно с private данными, встречается довольно редко.
M>Это потому что у тебя всегда есть возможность обратиться к данным напрямую.

нет. Вообще довольно редко возникает, независимо ни от чего.

M>Вот-вот, вернулись к тому с чего я начинал, пытаемся строить обертки и адаптеры над существующими классами, чтобы добраться до нужных данных в нужном виде.

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

M>Ну, допустим, что данная БД была спроектирована так, что таки пришлось вводить новое поле, все равно но код перелопачивать не надо, старый код этого поля просто не заметит и менять надо только те части, где понадобится использовать новое поле.

Угу. Старый код этих данных не заметит и будет работать старым образом. Неправильным образом.

M>При этом, заметь, тебе даже не удалось с первого раза придумать пример, где бы пришлось менять структуру данных вмсете с кодом

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

M>Значит опять возвращаемся к тому с чего начали. Либо у нас нет инкапсуляции, раз доступ полностью открыт, либо есть и объект придется-таки менять.

class SomeClass
{
  int _someData;
    public int SomeData { get { return _someData; } }
    int _someDependentData;
    public int SomeDependentData { get { return _someDependentData; } }
    
    public void SetSomeStuff(.....)
    {
      _someData = .....;
        _someDependentData = .....;
    }
}

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

M>И если-таки доступ ко всем данным есть, то он, с некоторой вероятностью, окажется совсем не тот, который хотелось бы — ну не такой объект возвращается, значит надо опять городить адаптеры...

что значит — не такой объект? Ты хотел получить клиента, а тебе вместо него подсунули документ?

M>Практика показывает, что если две части системы обладают сильной связью, то изменение одной части повлияет на изменение в другой, в меньшей степени, чем если бы эта связь была слабой?!! Вот это действительно что-то новое, даже не в ООП а в принципе в программировании.

две части системы — это код и данные, что ли?

M>Потому что выливается в больший геморрой.

В геморрой выливается менять структуру данных в РБД. Большой геморрой, очень большой. Потому что если работающего с данными напрямую кода много, то перекапывать придется его весь. Если такого кода меньше и он сосредоточен в одном месте, то геморроя становится намного меньше.

M>При чем здесь современные мерки? За те пятнадцать лет, что пытаются создать ООБД, реляционки прошли путь от идеи до тотального господства.

Тотальное господство РБД в 1985 году? Примерно в те времена только-только появились реализации, которые поддерживали транзакции. Не помнишь, когда внешние ключи впервые появились в реализации?
Ты просто сравниваешь существующие сейчас незрелые ООБД и современные РБД, которые прошли очень большой путь и ассимилировали много идей из других концепций.

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

S>>Аналогично. В отличие от педантов, для которых секурити (инкапсуляция) важнее функциональности, я считаю основным достоинством ООП полиморфизм. А вот его то я поддерживаю в своей БД максимально.
S>Ты не можешь поддерживать полиморфизм, не поддерживая инкапсуляции. Поддержка полиморфизма требует развязки интерфейса и его реализации, а при отсутствии инкапсуляции это невозможно.

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

Здравствуйте, GlebZ, Вы писали:
GZ>IMHO Фактически, минимальный набор джентельмена -
GZ>1. Сканирование таблицы,
GZ>2. Чтение кортежа
Т.е. bookmark lookup.
GZ>3. Сканирование индекса
GZ>4. Чтение значения индекса по ключу.
GZ>А фактически хрен его знает. Даже в этом минимальном наборе нет места index range search.
А куда это он делся? Можно конечно обойтись и без него, но это сильно сужает перспективы оптимизации. Как ты можешь заметить, чтение значения по ключу — это частный случай чтения множества значений по интервалу от ID до ID. Кстати, надеюсь, ты не забыл, что индекс не обязан быть уникальным?
Возможно, есть еще какие-то операции, которые было бы полезно уметь на нижнем уровне, но я что-то так сразу и не соображу.

GZ>Не попадалась документашка, в которой бы было описано какие операции делаются на уровне хранилища(ну пожалуй кроме SystemR, которую современной уже не назовешь).
Попадалась. Называется Системы баз данных. Полный курс.

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

S>>Совершенно верно. Теперь это просто данные.
GZ>Если ты заметил, вначале вначале шел разговор об OODB.
Все верно. Просто все преимущества RDBMS связаны с четким разделением адресных пространств клиента и сервера. Через этот гемоэнцэфалический барьер проникают только примитивные типы. Того же самого хочется получить и в ODBMS: невозможность вынести настоящий объект за пределы сервера. При этом внутри они должны себя вести как раз как полноценные объекты, со всеми инкапсуляциями, наследованиями и полиморфизмами.

S>>Совершенно верно. Обновлять можно только сами объекты.
GZ>Ага. Эта штука, лично мне, нравится. Только надо делать несколько путей для апдейтности. Например бывает основной апдейт через коллекции. Дают коллекцию и говорят, валяй пиши в базу данных. Как в датасете. IMHO Это в принципе частый вариант использования.
Ну, вообще "как в датасете" мне не очень нравится. Однако, надо помнить, что датасет апдейтится при помощи дата адаптера; таким образом, на сервер фактически уезжает батч из апдейт команд.

GZ>В данном случае ты сразу подразумеваешь пессимистический протокол транзакций на блокировках. Можно сделать пессимистически сериализуемой через блокировки только операции. В остальном работать по оптимистическому протоколу.
У оптимистического протокола своих бед хватает.
Вкратце: OODBMS полезны в основном в OLTP; всякие могучие отчеты надо гонять поверх данных, и там поведение только вредит. А OLTP куда как лучше справляется в случае пессимистичного блокировщика (если, конечно, не слишком параноидально ставить локи).

GZ>Тогда удерживать блокировки между операциями не надо, и можно строить транзакции от read commited до serializable(если с предикатными блокировками).
Чревато. Ой как чревато.

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

S>Криво — не значит невозможно. Если в языке без наследования можно сделать все те же паттерны что в языке с наследованием, причем паттерны, ориентированные на наследование — то тезис "наследование не обязательно" можно считать доказанным.

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

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

Д>заблуждение — это валить задачи OLAP и OLTP в одну кучу. Никому не нужно решать "задачу хранения фактов вообще" одним на всех универсальным образом, всех интересует только решение их частных задач.

Ага, только частные задачи оказываются очень широкими. Те же OLTP используются как сырье для OLAP, причем разных видов. Записи о первичках и текущие ведомости формируют, и различные виды учетов, и аналитику по ним строят. Причем, зачастую, все это разные приложения.

Д>Совсем другое дело — OLTP, где данные меняются очень часто, а читаются сравнительно редко.

Меняются? Скорее добавляются.

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

EXO>Задача клиента, в техуровевой архитектуре — отображать.
EXO>Удобно, качественно, в разных вариантах — но только отображать.

Не так. Задача клиента — обеспечивать взаимодействие с пользователем. А там есть еще обратное направление — преобразование действий пользователя в команды получения и изменения данных. И здесь все становится много-много печальнее.

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

S>>Давайте здесь более подробно. Пусть Ш — общее число школ. У — общее число учеников. Ш' — число отфильтрованных школ. У' — число отфильтрованных учеников.

S>>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))
S>>поиск в ОБД O(logШ + logШ' * logу)
S>А куда у нас делся поиск школ? С чего он вдруг стал log(Ш)? Или у нас индекс есть? Почему у нас стоимость поиска учеников внутри школы стала logу?
S>Ок, давайте сравним.
S>РБД: O(logШ + logУ + log(Ш')+log(У'))
S>ОБД: O(logШ + logУ + log(Ш')*log(y))
S>Сравнивать, очевидно, надо log(Ш')+log(У') и log(Ш')*log(y).

S>>шото мне кажется, что ОБД здесь уделала РБД, даже при тупом обходе дерева в глубь.

S>>Давайте это разберем — в натуре интересно и полезно.
S>Давайте подставим числа. Допустим, Ш=1000, Ш' = 80 (номера от 20 до 100). y = 2000 (Y=y*Ш= 2000000) ; при этом Y' = 40% от общего количества всех учеников = 800000 (классы 5, 6, 7 и 8).
S>для РБД мы получаем log(80)+log(800000) = 4.38 + 13.59 ~ 18.
S>Для ОБД — 4.38*7.60 ~ 33.3
S>И кто тут кого уделал? (Логарифмы везде натуральные).

Э нет. тут есть момент. что делает logY в оценке для ОБД? она такого считать при поиске по дереву не будет. А индексы — пусть будут и там и там. В ОБД — в каждой школе по экземпляру инекса для учеников.


РБД: O(logШ + logУ + log(Ш')+log(У'))
ОБД: O(logШ + log(Ш')*log(y))

Сравниваем
РБД: logУ + log(Ш')+log(У')
ОБД: log(Ш')*log(y)

РБД: log(2000000) + log(80) + log(800000) = 14.51 + 4.38 + 13.59 = 32.48
ОБД: log(80)*log(2000) = 4.38*7.60 ~ 33.3

Нос к носу. При увеличении общего колличества учеников и школ иерархическая БД будет опережать ОБД. И это мы говорим о тупом поиске в глубь на основании индексов.

Еще меня смущает JOIN за log(Ш')+log(У') Тупая метрика даст просто произведение Ш' на У' а применение хештайбл min(log(Ш')*У', log(У')*Ш') если посчитать с таким JOIN то РБД пролетает однозначно. Не подскажете ли где посмотреть, как сделать JOIN за log(N) а не за N*log(N) ?

Здравствуйте, AndrewVK, Вы писали:
AVK>Не так. Задача клиента — обеспечивать взаимодействие с пользователем. А там есть еще обратное направление — преобразование действий пользователя в команды получения и изменения данных.

С этим согласен.

AVK>И здесь все становится много-много печальнее.

Почему?
Меня только обработка исключений слегка достает. Но не так чтобы уж очень...