Re[4]: Файловые системы, файлы, приложения - устаревшие конц
От: Дарней Россия  
Дата: 20.04.06 16:39
Оценка: :))) :))
Здравствуйте, GlebZ, Вы писали:

GZ>здесь
Автор: GlebZ
Дата: 05.04.05
. Тогда тоже была весна(очевидно ООБД — это весеннее обострение).


весной всем хочется секса, и только у программистов это проявляется в такой странной форме
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
ООБД
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 08:36
Оценка: 66 (4)
Здравствуйте, shuklin, Вы писали:

S> Какие здесь подводные камни?

Основной подводный камень — сделать все на основе ООБД. В самом понятии ООБД содержится некая ущербность. Дело в том, что ОО — это не голые данные, а прежде всего поведение. Иными словами ОО это некоторая обертка над данными, которая навязывает этим данным определенное поведение.
Таким образом, предлагая хранить объекты, ты предлагаешь хранить определенное поведение, что как минимум довольно здорово ограничивает возможности самих данных. Все бы ничего, если бы речь шла о какой-то конкретной довольно узкой задаче, в некоторых случаях для ООБД еще можно найти уместное применение, однако ОС система довольно эклектичная и там живут данные самого разного назначения. И основное свойство данных заключается в том, что жизненный цикл самих данных гораздо больше, чем жизненный цикл некоего поведения навязанного этим данным в рамках определенной системы. Отсюда следует, что даже если на начальном этапе все замечательно, то никто не даст гарантии, что со временем семантика данных не изменится, и при тех же циферках данным не понадобится навязать другое поведение, что будет сделать довольно проблематично, если хранить данные не в чистом виде, а уже обернутыми в некоторую семантическую модель.
Примерно такие же соображения излагал и Кодд, когда проталкивал реляционную теорию для БД общего назначения.
Сейчас с успехом пользуются данными кропотливо вносимыми с семидесятых годов, за это время они перекочевали через нескольких поколений хранилищ и пережили сотни способов интерпретации, и вряд ли это было бы возможным если бы в самом начале использовались объектные хранилища или даже иерархические.
Из вышеказанного следует, что для систем с высокой степенью изменчивости и большим количеством разнородных данных, к которым относится и ОС, ООБД в чистом виде — не подходят.
... << RSDN@Home 1.2.0 alpha rev. 0>>

25.04.06 14:29: Ветка выделена из темы Файловые системы, файлы, приложения &mdash; устаревшие концепц
Автор: shuklin
Дата: 19.04.06
— AndrewVK
Мы уже победили, просто это еще не так заметно...
Re[30]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.04.06 15:25
Оценка: 17 (2) +2
Здравствуйте, Дарней, Вы писали:
Это заблуждение.
Реляционные данные — это записи о фактах. Тем они и хороши, что факты никак не меняются со временем. Десятого мая 1966 года Дж.Виллис купил в бакалейном отделе молока на 0.52 доллара. Алгоритмы обработки — вещь эфемерная. В 1966 году просто никто не знал, что делать со всеми этими Дж.Виллисами. Потом были придуманы всякие отчеты с группировками для того, чтобы сэйлзы из сети Таргет заявляли "нам нужно увеличивать расфасовку молочных продуктов, потому что на мелкую падает спрос". И показывали различные тренды.
Уже потом вопрос "а что с этим делать" стали называть Data Mining, защищать на этом диссертации и делать большие деньги.
От этого факты не перестали быть фактами.
Хранимые процедуры, триггеры — это все фуфло. Это попытка научить RDBMS вести себя как сервер приложений. В то время, как ее изначальная роль — только регистрировать факты.
Именно поэтому инкапсуляция поведения в DBMS — это путь к потере вот этой независимой составляющей. Никто не говорит о том, что это вообще тупик. Но некоторые данные про урожай риса пережили падение пирамид; в то время, как от методов их обработки ничего не осталось.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: WoldemaR Россия  
Дата: 21.04.06 14:57
Оценка: 3 (1) +1 :)
Здравствуйте, shuklin, Вы писали:

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


S>>>Ваши доводы или совершенно неубедительны,

M>>Аргументы кончились? Не нравится — не ешь..

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


S>Ну не любишь ты ОБД, а я не люблю РБД хоть и работаю с РБД каждый день, и каждый день по сравнению со своей БД не люблю SQL все больше и больше . Знаешь, мне с тобой беседовать просто скушно. Ничего нового ты не пишешь, только твердишь что ОБД — фигня. Ни на один мой тезис о внутреннем устройсве Cerebrum ты не ответил. Ни о синонимии/омонимии идентификаторов, ни о структурном полиморфизме ... Какие еще аргументы? , ты б в старые врубился хоть Так. С вами я флейм заканчиваю. Меняйте ник и стиль общения. Жалко на такое время тратить.


Merle тебя разводит по понятиям.
Базданщики это такая кагорта программеров, которые так любили стратигическое планирование, что съели много дерьма пока проектировали свои базы. Теперь это дерьмо лезет наружу. Это выражается в снобизме на понятиях. Прямо как в академии наук. Они убеждены в том, что если ты не ел тогоже дерьма то и ничего хорошего сделать не сможешь. И нечего смотреть на твои поделки. Ты в их глазах — безграмотный самоучка, выскочка. Над которым можно разве что поглумиться.
Merle, ничего личного. Это просто психология и национальное самосознание такие.

А вам, shuklin — совет. Ищите спонсора среди буржуев. У нас в россии не принято делать из человека икону при жизни.
Вот когда сдохнет — пожалуйста.
А так мы в россии всяких надоедливых самоучек-выскочек только травим да глумимся над ними.
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 08:02
Оценка: -3
Здравствуйте, Merle, Вы писали:

S>>Ваши доводы или совершенно неубедительны,

M>Аргументы кончились? Не нравится — не ешь..

Извините, но у Вас я вообще аргументов не заметил. Только декларацию того что ОБД это бесперспективно. "Не нравится — не ешь.. "

Ну не любишь ты ОБД, а я не люблю РБД хоть и работаю с РБД каждый день, и каждый день по сравнению со своей БД не люблю SQL все больше и больше . Знаешь, мне с тобой беседовать просто скушно. Ничего нового ты не пишешь, только твердишь что ОБД — фигня. Ни на один мой тезис о внутреннем устройсве Cerebrum ты не ответил. Ни о синонимии/омонимии идентификаторов, ни о структурном полиморфизме ... Какие еще аргументы? , ты б в старые врубился хоть Так. С вами я флейм заканчиваю. Меняйте ник и стиль общения. Жалко на такое время тратить.
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 23.04.06 05:09
Оценка: +3
Здравствуйте, shuklin, Вы писали:

S>От так я вам тут все свои ноу хау и выдал ))


Пора тему сворачивать. Это уже начинает походить на анекдот про Неуловимого Джо.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.04.06 13:21
Оценка: +3
Здравствуйте, shuklin, Вы писали:
S>Аналогично. В отличие от педантов, для которых секурити (инкапсуляция) важнее функциональности, я считаю основным достоинством ООП полиморфизм. А вот его то я поддерживаю в своей БД максимально.
Ты не можешь поддерживать полиморфизм, не поддерживая инкапсуляции. Поддержка полиморфизма требует развязки интерфейса и его реализации, а при отсутствии инкапсуляции это невозможно. Слишком велико будет искушение писать внешний код (хотя бы те же запросы) в терминах публичных полей, а не виртуальных методов/свойств. Вот тебе и весь полиморфизм — нельзя будет поменять реализации этих методов/свойств, т.к. есть внешний код, завязанный на внутреннее устройство объекта.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 21.04.06 16:49
Оценка: 44 (1) +1
shuklin wrote:
> От так я вам тут все свои ноу хау и выдал )) На данный момент из ноу хау
> реализована и опубликована новая версия идентификации экземпляров
> объектов, не совместимая с ODMG. Это я про синонимию и омонимию
> идентификаторов экземпляров объектов.
Ну так покажите результаты тестов. Какие проблемы?

>

>
> C>Интересны базовые алгоритмы — они определяют скорость работы. У вас
> есть что-то новое, чего нет в существующих ОО/РБД?
> Ну вот идентификация другая. Дальше будет больше но не сразу. Не
> реализованные фичи я обсуждать не буду.
Идентификации объектов в БД используются следующие:
1. Физический ID (ID объекта является физическим указателем на
расположение объекта в хранилище).
2. Логический ID, для преобразования в физическую позицию используется
какой-нибудь механизм типа каталога страниц.
Недостатки и преимущества обоих типов давно известны и хорошо описаны.

Что у вас нового?

> C>Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.

> РБД это в первую очередь РМД. А вот моя ОБД лежит на сетевой МД. РБД она
> не может быть ну никак.
Чистая сетевая модель не позволяет эффективно строить индексы, либо
требует фиксированные пути доступа к данным (что еще хуже).

Если мы начинаем строить индексы — то опять сваливаемся в РБД.

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

Ассимптотика у алгоритмов получается другая, но зато мы можем делать
ad-hoc запросы.

> C>Отличительная особенность ООБД — навигационный доступ. Благодаря нему

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

В РБД идентификатором объекта является главный ключ, и поиск по главному
ключу занимает O(log N) времени. При реальных объемах данных можно
считать, что он займет O(1) (амортизированое константное время).

Точка разлома — в представлении коллекций. В сетевых БД коллекции
хранятся непосредственно в объекте, то есть НЕ являются табличными данными.

Возьмем классический пример: есть список школ, у каждой школы список
учеников. Нам надо найти все школы с номерами от 20 до 100 и выбрать
всех учеников с 5 по 8 классы.

В случае РБД мы делаем выборку из таблицы школ по диапазону номеров
(O(log N) времени) и join'им ее с результатами выборки из школ по классу
ученика (тоже O(log N) времени). В результате, имеем ассимптотику O(log
N) для поиска.

В случае сетевой БД мы сначала получаем список школ с указанным номером
— это займет O(log N), если есть индекс по полю записи и O(N) в
противном случае. Затем мы для каждой найденной школы берем _весь_
список ее учеников и ищем в нем учеников с указаным возрастом. В общем,
имеем сложность O(log N)*O(log M), а при третьем уровне вложенности все
еще хуже — O(log N)*O(log M)*O(log K).

Можно схитрить — построить для некоторых путей доступа быстрые
lookup-таблицы. Именно это вы и делаете по намекам на HANDLE объекта,
различный в разных контекстах и волновое распространение изменений
(кстати, об этом еще в 70-х догадались ).

Но проблема появится при изменении схемы данных — это будет дорогая
операция, требующая прочитать уйму данных.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.04.06 14:21
Оценка: 42 (2)
Здравствуйте, shuklin, Вы писали:

S>Да. Но накладные расходы на инстанциирование в ОРМ больше чем у ОБД. А так все действительно ооочень близко и похоже.

А вот теперь я тебя расстрою: накладными расходами на инстанцирование можно пренебречь. Вообще.
По сравнению со стоимостью поднятия 64kb с диска в память, самый медленный алгоритм конверсии этих килобайт в объекты бесконечно быстр.
Насчет "вся БД в памяти" — типичные реализации ODBMS выполняют "подмену адресов", благодаря которой стоимость dereferencing уже загруженного объекта близка к стоимости процессорной команды косвенного доступа. На фоне этого 80000 ссылок в секунду на 1.7 Mhz — это просто тихий ужас.

Оптимизировать инстанцирование имеет смысл только для систем, где запросы выполняются полным перебором. Но это сродни попыткам научиться быстрее вычерпывать воду из дырявой лодки. Если удастся найти метод, позволяющий вместо 8000 тысяч страниц читать ровно 1 — ту, на которой расположен искомый объект, в сэкономленное время можно вдосталь позаниматься неспешным инстанцированием.

S>Мне вот что тут интересно, JOIN у вас в этом примере оказался O(1).

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

S>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))

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

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


S>Давайте это разберем — в натуре интересно и полезно.

Давайте подставим числа. Допустим, Ш=1000, Ш' = 80 (номера от 20 до 100). y = 2000 (Y=y*Ш= 2000000) ; при этом Y' = 40% от общего количества всех учеников = 800000 (классы 5, 6, 7 и 8).
для РБД мы получаем log(80)+log(800000) = 4.38 + 13.59 ~ 18.
Для ОБД — 4.38*7.60 ~ 33.3
И кто тут кого уделал? (Логарифмы везде натуральные).
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 21.04.06 13:43
Оценка: 13 (1) +1
Здравствуйте, AndrewVK, Вы писали:

GZ>>Что значит привинчен?

AVK>То и значит, что в ООБД данные неразрывно связаны с кодом.
Вообще-то наоборот, и зависит от типа OODB. Фактически существует два типа OODB — пассивные, и активные. Пассивные, типа того-же Versant, отличаются от OODB+ORM мало. Единственное, что хранилище максимально приспособлено под навигационный доступ. Декларативные запросы идут не по объектам, а именно по данным. Активные, типа GemStone более объектные и полностью инкапсулируют данные. Правда иногда все равно эту инкапсуляцию нарушают на уровне запросов(к сожалению не спец по ней, сужу по рассказам).
Основная проблема того, что нарушается инкапсуляция — многоязычность и императивность языков. Запрос должен быть переформирован в форму которая должна быть максимально селективна. Для императива, в котором может быть написано все что угодно, из кода которого иногда просто невозможно получить граф это принципиально невозможно. Microsoft поступил проще введя лямбды. Возможно под это дело появятся новые ODB.
Re[32]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 28.04.06 13:22
Оценка: 13 (1) +1
Здравствуйте, Sinclair, Вы писали:

GZ>>А может стоит тут интерпретировать не как объекты OODB, а именно как объекты из компоненты OODB?

S>Че-то не улавливаю. Ты не мог бы развернуть?
Легко сказать да трудно сделать. Страдаю глобализмом. Все нижеследуещее следует считать во первых IMHO, во вторых относящимся именно к объектно-ориентированным базам а никак иначе. Вопросы навигации не рассматриваю.
Итак. Прежде всего некоторые тезисы. Тезисы по поводу РСУБД, касаются именно именно идеальной реляционки времен Кодда и SystemR. Кое что было решенов рамках СУБД, кое что с помощью сервисов поставляемые с той, или иной базой данных.
1. Недостаток РСУБД. Скудность информации данных. Зачастую о смысле данных можно узнать только перерыв приложение которое его использует.
2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.
3. Недостаток РСУБД. Даже для задачи хранения и получения данных, нужны вычисления. А для вычислений нужен язык. В РСУБД были внедрены языки, но поскольку первичная их задача — доступ к данным. На вычислительную мощность, и, в большей степени, на удобство пользования разработчики положили.
4. Недостаток РСУБД. Недостаточность инкапсуляции. Вьюхи в классическом виде не выполняют своей роли полностью так как работают на чтение. На данный момент можно пользовать stored procedure, которую нельзя включить в custom SQL запрос. Или с помощью триггеров instead of навешанную на VIEW или Table. Еще в некоторых базах существуют функции(сразу признаюсь что не знаю, используются они в оптимизации запросов, или нет).
5. Недостаток OOСУБД. Инкапсуляция. Инкапсуляция хороша от внешних злодеев, и очень вредна внутри OOСУБД. Наибольший пострадавший в данном случае — оптимизатор запросов.
6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.
7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.
8. Принцип Деметры(принцип хорошего проектирования):

Для любого класса C и для любого метода M, связанного с C, все объекты, которым M посылает сообщение, должны быть экземплярами классов, ассоциированными со следующими классами: классами аргументов M (включая C); классами переменных экземпляра C.

Взято отсюда.здесь. Интересная статья, советую прочитать.
9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.
9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.
10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
11. SQL хотя не является процедурным языком, но также не является и функциональным, так как не поддерживает рекурсию. Соответсвенно на нем нельзя строить произвольно сложные запросы.
12. Недостаток OODB. Он пытается увеличить скорость навигационных запросов путем адаптации хранилища к ним. Он сознательно адаптирует хранилище под конкретное приложение согласно объектной схеме. (Это я намекаю на хранение подчиненных коллекций и объектов вместе с объектом владельцем). Соответвенно теряется эффективность ad-hoc запросов.
12. Для оптимизатора запросов важна подробная информация.


Итак вооружившись этими тезисами, начинаю сочинять(играю как умею, в пианиста не стрелять).
Для каждого вида бизнес-объектов строится пара — объект состояния(хранящий состояние), и объект доступа(выполняющий операции связанные с данным объектом состояния).
Объект состояния.
1. Он только предоставляет интерфейс доступа к состоянию. Реализация доступна только в самой сборке.
2. Объект зависит от заказываемой версии. То есть, одна и та же таблица или результат может быть инстанцирована несколькими объектами в зависимости от заказываемой версии.
3. Таблица всегда содержит объекты последней версии. Объект может быть не инстанцирован никогда, и его задача только в описании метаданных для таблицы.
4. Объект содержащий данные может быть не виден за пределами сервера OODB, и использоваться только внутри ее.
5. Объект состояния может быть не привязан к таблице, и использоваться только для сборки внутри сервера, и отправки состояния клиенту.(для аналога view)
6. Объект в силу пункта 2(версионификация), может быть собран через кодогенерацию(для метапрограммирования мешает режим 24x7).
7. Объект должен быть настолько прост, насколько он может показывать свое состояние, и содержать элементарные бизнес-правила(аналог check).

Объект доступа.
1. Основная его задача не получить или изменить объект. Основная его задача указать менеджеру запросов как преобразовать запрос для использования данного типа объектов.
2. Объект может передавать управления другим объектам доступа(для реализации аналога view).
3. Объект должен поддерживать инстанцирование и разбор объектов всех версий.
4. Объект должен поддерживать версионификацию по комовскому типу. Например, показывать только свой интерфейс, который в свою очередь зависит от заказываемой версии запроса. И обрабатывать запрос в свою очередь согласно заказанной версии.
5. Все методы объекта должны быть функциональными. Это важно для оптимизатора запросов. На входе граф запроса и контекст выполнения, на выходе трансформированный граф запроса и контекст.
6. Методы получения объектов состояния и записи состояния могут быть сильно различными. Ну например, для автоматической поддержки аггрегируемых значений.
7. Существуют методы частичного вычисления. То есть, вместо того, чтобы выстраивать полный запрос, перенаправлять на таблицы которые уже содержат часть результатов.
8. В связи с предыдущим пунктом можно увеличить производительность, строя кэш результатов на те или иные объекты состояния(аналог материализованных вьюх, только в контексте OODB).
9. В связи с предыдущим пунктом можно даже увеличить производительность за счет поддержки индексирования значений методов.(точнее не даже, кое-кто такое поддерживает).

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

Может я в чем-то ошибаюсь, все это IMHO, но это мое виденье хорошей OODB.
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.04.06 13:58
Оценка: +2
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>ИМХО, любой апликейшен сервер это как-бы ООБД. Которая может использовать внешнюю РБД для хранения данных, индексации.


Но, в отличие от ООБД, сервер приложений не намертво привинчен к данным.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: IT Россия linq2db.com
Дата: 21.04.06 04:20
Оценка: +2
Здравствуйте, shuklin, Вы писали:

S>В своей ОБД я пришел к следующему.


S>- инкапсуляция не рекомендуется к применению.

S>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта.

Это уже не OODB, а COODB, где C абревиатура от castrated. Это как раз то о чём говорит Иван, получается ни два, ни полтора. Кастрированная объектная модель и такая же неполноценная база данных.

Кстати, современные ОРМ и всевозможные мапперы совсем неплохо справляются с преобразованием данных БД в объектную модель и наоборот. На это у разработчиков уходит всё меньше и меньше времени. Для большинства операций это реализуется зачастую лишь одной строчкой кода. При этом мы имеет и полноценную БД и ничем искуственно не ограниченную объектную модель.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[30]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 24.04.06 14:42
Оценка: +2
Здравствуйте, Дарней, Вы писали:

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


Д>Хранить — не просто так. Хранить для того, чтобы потом их можно было прочитать. Может быть, это никому не понадобится. Но если бы не было этой задачи, то не было бы необходимости их хранить. Вообще.


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

IT>>ЗЫ. Тебе Merle уже в пятом топике говорит, что пора завязывать, но ты всё никак не угомонишься и продолжаешь демонстрировать свою... мягко говоря, неосведомлённость в обсуждаемых вопросах. Давай лучше завязывать, ok?


Д>Мягко говоря, ты тоже нарушаешь правила форума. Не к лицу это тебе, не находишь?


Вот видишь до чего порой доводят несознательные посетители

Д>Что касается моей осведомленности, то меня мало интересует чье-то мнение о ней. Я всего лишь хочу получить наконец ответы на вопросы.


Ты их получаешь, только почему-то не хочешь принимать. Создаётся впечатление, что у тебя есть свои ответы, с которыми наши не согласуются. Но вместо того чтобы выразить своё мнение и прояснить ситуацию, ты пытаешься запутать других. Про состояние объектов я тебе уже раз пять говорил, но ты либо беспросветно тупишь, в чём я лично очень сильно сомневаюсь, либо откровенно над нами издеваешься. В любом случае, водить хороводы вокруг этой темы лично мне уже надоело.
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 26.04.06 12:42
Оценка: +2
Здравствуйте, shuklin, Вы писали:

E>>Вероятно, скоро на вашем сайте появится статья: "Дмитрий Шуклин о перспективах полиморфизма без инкапсуляции".


S>Мало вероятно Тему следующей провокации я еще не выбрал


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 26.04.06 16:25
Оценка: :))
Здравствуйте, AndrewVK, Вы писали:

AVK>Ты когда нибудь видел в SQL-серверах возможность править результат select?

Вьюхи instead of.
Re: ООБД
От: Garb  
Дата: 28.04.06 19:09
Оценка: :))
Здравствуйте, Merle, Вы писали:

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


S>> Какие здесь подводные камни?

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

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


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

Я тоже думаю, что ООБД не заменят РБД. Кстати, пора бы уточнить понятия. Тут уже начали говорить про активность объектов. Я то понимал под ООБД просто другую модель данных. Вместо плоской- иерархическую-сетевую с наследованием. Язык запросов какой-то отличный от SQL. А не то что объекты обязательно выполняются.

За РБД стоит теория. Интересно, что стоит за ООБД? Какие там языки запросов?

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

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

Вобщем, назовите задачи, которые требуют ООБД.
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: dimon0981 США  
Дата: 29.04.06 18:19
Оценка: :))
Здравствуйте, Дарней, Вы писали:

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


M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату


Д>надо же, как интересно. А что, объектов больше не будет?


Ага. Их отменили.
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 17:18
Оценка: 23 (1)
Здравствуйте, shuklin, Вы писали:

S>Я уже устал отвечать на этот вопрос одно и тоже. Не рекомендую — не значит не могу. Могу. Но инкапсуляция в том виде в котором она есть в обычном языке программирования в БД лишня. Она лишняя в РБД. Она лишняя в ОБД, Не нужна там такая концепция. Лишняя концепция не значит нереализуемая или неподдреживаемая. Я ее поддерживаю. Кто пользуется — принимает на себя следствия ее использования. Согласитесь, если сама концепция инкапсуляции просто по законам логики влечет за собой отрицательные последствия для БД — не зависимо от того ОБД или РБД — то наверное что то не с конкретной реализацией ОБД а с самой концепцией. Вот я и дал возможность — кому надо — пользоваться, кому не надо — не пользоваться.


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

IT>>А как же внутреннее состояние объекта. Жесткие требования к сериализации как я понимаю тоже из этой серии. То что будет сериализоваться будет лежать в базе просто как блоб, поиска по этим данных мы не получим.


S>Тоже устал писать одно и тоже. Объект в моей БД можно сохранять частями. См. в соседних ветках.


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

Понятие объекта в ООП строго. Брать от него половину и говорить, что это вот мол у меня тоже объект — оснований быть не может.

S>Знаете, для меня лучший аргумент — это работоспособный код который решает описанные проблемы. В соседних ветках уже есть гора сообщений с кратким описанием решений. Этот работоспособный код у меня есть, так что можете тут хоть лопнуть — мне это как бы без разницы.


Работоспособный код в вашем понимании это вообще не аргумент. Можно все что угодно сделать работоспособного...
На вашей так называемой "ОБД" есть реально работающие крупные системы в промышленной эксплуатации с опытом хотя бы в 1 год?
Хоть 1? Приведите пример.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 24.04.06 10:27
Оценка: 23 (1)
Здравствуйте, Дарней, Вы писали:

Д>я не пытался сменить разговора.

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

Д> Целью которых было как раз уточнить, что же ты имел в виду.

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

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

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

Д>Закат — это синоним слов "конец", "смерть". Отсутствие развития и "конец" — это совершенно разные вещи.

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

Д>Далее. Почему обязательно развитие ООП должно остановиться?

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

Д>почему?

Потому что принцип "расширять, гораздо выгоднее чем менять" — один из самых фундаментальных.

Д>не бывает такой задачи — "хранить данные".

Бывает.

Д> Бывает задача "хранить и обрабатывать данные".

Это две задачи. Есть задача хранить и есть задача обрабатывать. Причем задача обрабатывать, меняется гораздо чаще, чем хранить.

Д>Насколько часто ты видел полностью нормализованную базу без единой SP или триггера, кстати?

А при чем здесь SP и триггеры? Это всего лишь программа, которая может быть размещена где угодно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[35]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.05.06 04:33
Оценка: 22 (1)
Здравствуйте, GlebZ, Вы писали:

GZ>Вопрос только насколько они действенны. Современная база данных это не только данные, но и поведение. Узнать о том, что данное поле заполняется автоматом с помощью триггера, можно только просмотрев реализацию триггеров. А информация о том что поле read only, или в каких случаях оно является read only, вполне полезно.

Да, действительо, все еще хуже, чем я описал. Часть метаинформации, описанная в императивном виде, вообще не поддается получению.
GZ>По поводу того, что нет информации о связях, согласен на все +1000. Но IMHO ты не совсем прав. Реляционка нуждается в ad-hoc запросах так как "ссылка на таблицу" недостаточное условие универсальности реляционки.
С точки зрения реляционки, все (почти) в порядке. Все будет полностью в порядке только при расширении трактовки понятия Foreign Key так, чтобы оно могло ссылаться не только на хранимую таблицу, но и на произвольное реляционное выражение.
GZ>Ну например такой запрос вполне жизненен.
GZ>
GZ>select *, ISNULL(organization.Name, citizen.Family) from document outer join organization on (document.signer = organization.id and document.sign_org=1)
GZ>outer join citizen on (document.signer = citizen.id and document.sign_org=0)
GZ>where document.signed is not null
GZ>

GZ>FK — как "ссылка на таблицу" — недостаточен. Нужно что-то более полиморфное.
Это мы уже забредаем на территорию ODBMS. Реляционка пренебрегает такими концепциями, как наследование и полиморфизм.

GZ>В принципе, в OODB это решается через наследование. Но тут легко получить, как ты выражаешься, выстрел в ногу. В случае оперативной памяти, мы легко получаем ссылку на экземпляр и его RTTI. В случае СУБД, экземпляр как таковой не инстанцирован, и получение экземпляра, или его ссылки — затруднено. IMHO Лучшим выходом в случае СУБД является явное указание конкретных типов который может адресовать ссылка. Указание же типа предка, подразумевает более широкий поиск возможного типа ссылки что не есть гуд.

Нет, тут никакой проблемы нету. Дерево наследования — всего лишь дерево; способ оптимизации для операции "получить всех потомков" хорошо известен — транзитивное замыкание.
Запрос, приведенный тобой выше, будет записан значительно короче, но при выполнении автоматически раскрыт в
select *, ResponsibleParty.Name from document outer join 
(
  select id, Name from organization
  union 
  select id, Family from citizen
)
where document.signed is not null

GZ>Данные могут быть полуструктурированы(короче говоря, меняющеяся от blob'a к blob'у схема).
Это само по себе уже не так сложно, как вообще поддержка хоть какой-то семантики о блобах. Вот, к примеру, модный Full-text Search от микрософта предлагает в таких случаяз заводить в таблице рядом с image полем колонку с расширением файла! Хоть бы MIME-тип использовали, позорники.
GZ>Зависит от обстоятельств. Иногда оптимизаторы пользуются индексами как отношением.
Неважно, как именно оптимизаторы пользуются индексами. С точки зрения реляционной алгебры индексов не существует. Точно так же, как арифметика прекрасно "работает" без оглядки на схемы ускоренного сложения, применяемые в электронике.
GZ>+1 Во первых, ты забыл вернуться к убогости SQL.
Не, не забыл. Просто слово это не написал.
GZ>Во вторых, ты темповую таблицу меришь по реализации в MSSQL. Там ублюдочная реализация. Темповая таблица — это некоторый промежуточный результат для получения других конечных результатов и которая не требуют транзакционности.
Пойми, что без ленивой семантики временная таблица — ублюдок вне зависимости от способа реализации. Ее где-то надо хранить, потому что к моменту ее использования информация о способе получения данных безнадежно потеряна. Если бы это была не таблица, а ссылка на реляционное выражение, то у оптимизатора оставался бы шанс как-то уменьшить стоимость запроса.

GZ>Меня волнует один вопрос. А как описывать/использовать статистику для рекурсивных запросов?

Точно так же, как и для обычных join. А что тебя беспокоит?

GZ>Я абсолютно согласен. Это было просто утверждение о реализации большинства OODB.

Ну, потому это большинство и делит %0.01 рынка обработки данных.
GZ>Проблема в том, что объект в оперативной памяти может быть достаточно большим. Его основная цель быть полноценным экземпляром.
Неа. В хорошей ODBMS должны реально инстанцироваться лишь немногие объекты.
GZ>Это процесс бесплатный если сравнить с падением производительности при чтении большого объекта в таблице. Поэтому, конечный тип может быть эфективнее если он сборный из двух и более таблиц. Вторая проблема — наследование. Join — отнюдь не самая легкая операция в СУБД, если хранить предка и потомка раздельно. В тоже время, если их хранить вместе, также невесело. На каждый тип свой запрос и свой проход по данным. При требовании, что объект поднятый с БД должен быть полноценным экземпляром подразумевает избыточность действий и данных.
Это все происходит от того заблуждения, что основной операцией является разрешение ссылки. Конечно, если не давать описывать более осмысленные операции, то во-первых придется руками указывать СУБД какой объект поднимать, а во-вторых ей придется поднимать полный объект, т.к. она не знает, что именно я собрался с ним делать.
Вот, например, РСУБД при удачном стечении обстоятельств может вообще обходиться без чтения таблицы ("инстанцирования кортежей"), если для выполнения запроса хватает данных в индексе. Точно так же должна работать ODBMS — достаточно дать ей доступ к коду. Тогда она сможет строить код, который работает в основном с данными на диске, но так, чтобы конечный результат был неотличим от полного перебора честных инстансов с соответствующими вызовами.
S>>Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием.
GZ>Здесь выйгрыш в том, что код более гибкий. На СУБД — у нас одна обработка. На клиенте, который объект получил через web-сервис, другая обработка. В каждом слое приложения можно сделать свою обработку бизнес-объекта в соответсвии с целью, которая заложена в бизнес-логику слоя. При этом, они зависимы только по интерфейсу бизнес-объекта, а не по методам его получения или методам работы с хранилищем.
Согласен, это так.
GZ>Гы-гы. Собственно с помощью компонентной объектной модели можно скрыть факт о связи многие к многим, и о несовместимости логики за интерфейсом. Возможности не бесконечны но все таки более эффективны, чем при РСУБД.
Совершенно верно. Об этом я и говорю — чувство легкости при внесении изменений в РБД является ложным. Хорошо спроектированную ОБД будет не труднее, а легче поддерживать и развивать (а иначе нафига мы вообще это все придумываем???)

S>>На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.

GZ>Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.
Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
GZ>Тут возникает следующий вопрос. Сможем ли мы перевести большинство методов в селективные предикаты?
Ну, во-первых они не должны иметь побочных эффектов, иначе — сразу InvalidOperationException.
GZ>SQL с одной стороны много не позволяет.
Во-вторых, главное — выкусить "индексируемую" часть предиката, а остальное оставить в виде residual и честно вычислять.
GZ>Хотя в нем можно делать предикаты о которых не существует статистики, но это редкость. Будет ли это редкостью в коде OODB, еще вопрос.
Действительно, вопрос. Пока что мы говорим о гипотетической ООСУБД для гипотетической ООБД, и довольно сложно представить для чего это вообще будет применяться и как там ляжет карта со статистикой. Будет ли там 5000 классов в сложной иерархии? Будут ли там чудовищно сложные методы с рекурсивными вызовами, циклами и прочей ерундой? И т.д.

GZ>IMHO Тут может случиться казус с семантической оптимизацией. В данных условиях, подозреваю, что будет много повторяющихся предикатов, которые можно будет поубивать.

А что значит "поубивать"?
GZ>И скорее всего, нужно будет убивать промежуточные объекты, основной смысл которых предоставить путь от таблицы к таблице.
Ты имеешь в виду сбор мусора?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 10:17
Оценка: 13 (1)
Здравствуйте, IT, Вы писали:

GZ>>Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).

IT>Без понятия. К моему стыду я даже не знаю какую базу данных ты меешь ввиду
ReBar
У них кстати вышла по этому поводу интересная работа:
Lessons Learned from Managing a Petabyte

GZ>>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.

IT>И при чём тут ООБД? Или у неё здесь есть хоть малейший шанс вырваться вперёд?
Фактически да. OODB дает менее универсальное хранилище чем реляционка, но ее можно более эффективно подвернуть под конкретную задачу. Во первых, OODB — это уже готовый сервер приложений. Во вторых, сейчас наблюдается тенденция не хранения всего в единой универсальной базе данных с единым сервером приложений, а разделения функциональности по некоторой специализации. То есть вместо одного большого кластеризованного сервера приложений, некоторое кол-во поставщиков данных, и интеграционные сервера. А как поставщик данных, реляционка не слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни гибко предоставлять. Для этого делают надстройки. Уже сейчас есть тенденции в отказе от традиционных реляционных решений в пользу более слабоструктурированных xml(можно даже проследить по форуму баз данных, куда я иногда захожу).
Ну и конечно то, о чем я говорил вначале. ООDB, в рамках манифеста, не теряет идентификацию данных. OID, в отличие от primary key, является всегда синтетическим ключом, и может адресовать данные находящиеся на другом хосте. Это полезное свойство при интеграции.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 20:35
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>А избыточность XML куда девать?

GZ>>А кто тебе сказал что данные в xml базе данных лежат в текстовом виде? Это не какой-нибудь парсер.

ГВ>Да это-то понятно. Но всё равно какая-никакая, но индивидуальная идентификация атрибутов должна быть.

Ну схему то никто не отменял.

ГВ>Я имею ввиду вот что.


ГВ>Например, если у нас есть таблица документов РБД, то данные можно уложить плотно, в соответствии со структурой таблицы. Мы в любом случае будем знать, что, скажем, по смещению 0x21 от физического начала записи начинается поле "дата документа". А вот в слабоструктурированом хранилище придётся к каждому фактическому атрибуту присовокуплять его идентификатор и сущность (или код идентификатора в каком-то словаре, не суть). По сумме это должно дать нехилый оверхед по габаритам или выродиться в РБД.

Нет. Оверхеда здесь особо нет даже для реляционок. Во вторых, можно конечно все держать в одной таблице, только это слишком неоптимально по структуре чтения. А количество чтений и записей, их порядок, пожалуй самые важные параметры говорящие о качестве базы данных. В третьих, кто сказал что так уж плохо, если это будет набор таблиц. Как не пыжся, внизу всегда будет реляционка, благо хранение в большинстве случаев последовательное. Все остальные типы баз — это вопрос надстроек над таблицами и математика их общения. Поэтому не надо присовокуплять(хорошее однако слово, надо будет запомнить).
И третье, у меня не хватает время следить за современными проектами по xml базам, а это было и пока еще популярно не хуже ООДБ и их очень многого я не знаю. Так что все ИМХО.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[3]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 20.04.06 15:55
Оценка: :)
Здравствуйте, Merle, Вы писали:

S>>Да. И считаю это основным достоинством ОБД.

M>А я считаю это причиной того, что ООБД обречены.
Зачем так категорично. Мое IMHO что эпоха ООБД еще не начиналась. Чтобы не повторяться, пост годичной давности:
здесь
Автор: GlebZ
Дата: 05.04.05
. Тогда тоже была весна(очевидно ООБД — это весеннее обострение).
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: IT Россия linq2db.com
Дата: 21.04.06 04:26
Оценка: +1
Здравствуйте, Дарней, Вы писали:

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату


Д>надо же, как интересно. А что, объектов больше не будет?


Будут радёмые, куда же без них. Но вот совать ООП куда ни попадя, как то в базы данные или в распределённые среды, где ООП плохо работает, и искать в ООП панацею народ потихонечку прекращает. И это правильно. ООП бесценна на уровне небольших объектных моделей, здесь её роль трудно недооценить. Но глобализм не для ООП. Самодостаточная персистентная распределённая объектная модель мира — это утопия.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
От: shuklin  
Дата: 21.04.06 07:43
Оценка: :)
Здравствуйте, GlebZ, Вы писали:

S>>>Да. И считаю это основным достоинством ОБД.

GZ>Мое IMHO что эпоха ООБД еще не начиналась. Чтобы не повторяться, пост годичной давности:
GZ>здесь
Автор: GlebZ
Дата: 05.04.05
.


GZ>Нужна революция. Пролетарии всех стран, объединяйтесь!


GlebZ, присоединяйся к разработке Cerebrum, устроим революцию вместе
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 21.04.06 12:32
Оценка: +1
Здравствуйте, Merle, Вы писали:

M>С моей точки зрения честная ООБД — это та, которая поддерживает, как минимум, наследоване, инкапсуляцию и полиморфизм, в том виде, в котором ее поддерживают современные объектные ЯП.


для начала давай уточним, какие из современных ЯП?

к тому же наследование — далеко не обязательный пункт
фактически, для соответствия ООП требуется всего два пункта — инкапсуляция и полиморфизм (полиморфизм != virtual method). Механизм расширения объектов (опять таки != наследованию) — желателен, но не обязателен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 15:58
Оценка: :)
Здравствуйте, IT, Вы писали:

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


S>>>>- инкапсуляция не рекомендуется к применению.


IT>Ты же сам перечислил свои ограничения Ты не можешь в полной мере использовать инкапсуляцию,

Я уже устал отвечать на этот вопрос одно и тоже. Не рекомендую — не значит не могу. Могу. Но инкапсуляция в том виде в котором она есть в обычном языке программирования в БД лишня. Она лишняя в РБД. Она лишняя в ОБД, Не нужна там такая концепция. Лишняя концепция не значит нереализуемая или неподдреживаемая. Я ее поддерживаю. Кто пользуется — принимает на себя следствия ее использования. Согласитесь, если сама концепция инкапсуляции просто по законам логики влечет за собой отрицательные последствия для БД — не зависимо от того ОБД или РБД — то наверное что то не с конкретной реализацией ОБД а с самой концепцией. Вот я и дал возможность — кому надо — пользоваться, кому не надо — не пользоваться.

IT>А как же внутреннее состояние объекта. Жесткие требования к сериализации как я понимаю тоже из этой серии. То что будет сериализоваться будет лежать в базе просто как блоб, поиска по этим данных мы не получим.


Тоже устал писать одно и тоже. Объект в моей БД можно сохранять частями. См. в соседних ветках.

IT>Вот уж чья бы корово мукала насчёт неубедительной демагогии, а втоя бы лучше за собой последила. Пока кроме эмоций от тебя никаких убедительных аргументов не последовало. А аргументы и доказательства состоятельности своей позиции надо приводить как раз тебе, т.к. сегодня по истечении более десяти лет все попытки сделать OODB так и остались попытками.


Знаете, для меня лучший аргумент — это работоспособный код который решает описанные проблемы. В соседних ветках уже есть гора сообщений с кратким описанием решений. Этот работоспособный код у меня есть, так что можете тут хоть лопнуть — мне это как бы без разницы.
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 17:46
Оценка: +1
Здравствуйте, shuklin, Вы писали:

S>ИМХО поддерживает в объеме достаточном для эксплуатации. А проблемы — где их нет. Про технические и идеологические проблемы своей БД я знаю. Много их там. Не было бы — не педалил бы следующую версию


Да вы уже давно себе решили — поддерживать индексы свойств нельзя, значит поля публичные и на них придется полагаться. И все — инкапсуляция долой и все с ней связанное. И опять работа со статичными данными вместо свойств. Могли бы подумать о динамическом реинжиниринге кода поисковых предикатов для работы с индексами прайват полей, но не стали... А теперь уж поздно все выбрасывать — новая версия как никак.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: IT Россия linq2db.com
Дата: 21.04.06 22:34
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

IT>>Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.

GZ>Скорее немного не так. Когда машина начнет понимать что человек написал. А DLinq уже может интерпретировать и трансформировать такой код. Так что эпоха не начинается, а можно сказать наступила.

Ну если DLing по твоему это шаг вперёд в нужном направлении, то нам ещё долго шагать
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 22.04.06 07:28
Оценка: +1
shuklin,

MS>>Ну и правильно. Делайте для себя и не тратьте время на чужое время — все равно все для себя. Другим оно вряд-ли пригодится.


S>Уже есть прециденты обратного.


Молодец! Вообще критика полезна, но как сам наверное понимаешь, угодить всем невозможно. Если у тебя что-то действительно новое, то продолжай делать дальше, невзирая ни на что и всё будет зашибись. Даже в самом крайнем случае тебя может постигнуть неудача, которая будет следующей ступенькой к успеху!

//Для поддержки энузиазма
Автор(ы): Steve Pavlina
Дата: 20.12.2004

В статье ''How To Get More Done in Less Time'' я писал о простом способе,
который может помочь постепенно увеличить продуктивность работы, не
требуя дополнительного времени. В этой статье я расскажу о нескольких
дополнительных способах сделать больше, не работая при этом
сверхурочно.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 22.04.06 17:34
Оценка: +1
Здравствуйте, Дарней, Вы писали:

Д>А чем отличается "реальная распределенность" от "иллюзии распределенности"? Ты можешь привести какой-нибудь реальный пример?


Реальной распределённости при сегодняшнем уровне технологий добится очень сложно и то только за счёт гарантированных тормозов. Нужно транзакционно обновлять распределённое состояние объекта, т.е. делать что-то типа распределённого lock. Если эти требования снижать, то можно получить иллюзию распределённости. Например, мы можем принять такое допущение, что объект может изменяться только одним писателем, при этом доступ к объекту на время обновления его распределённого состояния разрешен, а возможными коллизиями мы можем пренебречь.

IT>>Ваня тебе уже всё рассказал про врождённые пороки ООП в ООБД, хочешь чтобы я его процитировал?


Д>всё, что он рассказал — это "ООП не работает". Как выяснилось, под "не работающим ООП" он понимает только одну из существующих реализаций ООП — вероятно, единственную, с которой он знаком. А возможность применения других реализаций или создания новых в его систему абстракций не укладывается никаким образом.


Ты можешь привести какой-нибудь реальный пример таких других реализаций?

Д>Какие принципиальные проблемы, которые можно избежать при отказе от ООП, ты видишь в данной задаче?


Синхронизация состояния.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 23.04.06 10:47
Оценка: +1
GlebZ wrote:
> <http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/index.shtml&gt;
> У них кстати вышла по этому поводу интересная работа:
> Lessons Learned from Managing a Petabyte
> <http://www.slac.stanford.edu/BFROOT/www/Public/Computing/Databases/proceedings/CIDR05.pdf&gt;
Понравилось:

The technology that best fits bookkeeping is an
RDBMS. As with the eventstore, the specifics are
abstracted, allowing more than one RDBMS
implementation to be used. Some large centers, like
SLAC (which has an Oracle site-license) use Oracle,
while most small institutes opt for an open-source
alternative, MySQL.
...
The main goal is to provide a compact, simple catalog
for users to find the most common data quickly, while
allowing access to the full archive when needed.


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

Однако для каталога, наоборот, нужны ad-hoc запросы и быстрое их
выполнение. Отсюда и использование РСУБД.

> А как поставщик данных, реляционка не

> слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни
> гибко предоставлять.
Проблема в том, что РСУБД пока лучше всего умеет поставлять
данные. И соответственно, лучше всего проявляет себя в задачах, где
нужно быстро и эффективно искать нужные данные.

ООБД позволяет быстро обрабатывать сложные данные, но плохо умеет их
искать.

> Для этого делают надстройки. Уже сейчас есть

> тенденции в отказе от традиционных реляционных решений в пользу более
> слабоструктурированных xml(можно даже проследить по форуму баз данных,
> куда я иногда захожу).
Скорее свидетельство buzzword'нутости...
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 23.04.06 17:12
Оценка: +1
Здравствуйте, Merle, Вы писали:

break
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 24.04.06 12:25
Оценка: +1
Здравствуйте, Дарней, Вы писали:

Д>Не бывает задачи "просто хранить". Если данные где-то хранятся, то только для того, чтобы их обрабатывать. А просто БД с наглухо закрытыми входами и выходами — это из раздела розовых мечтаний DBA


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

ЗЫ. Тебе Merle уже в пятом топике говорит, что пора завязывать, но ты всё никак не угомонишься и продолжаешь демонстрировать свою... мягко говоря, неосведомлённость в обсуждаемых вопросах. Давай лучше завязывать, ok?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 24.04.06 17:24
Оценка: +1
Здравствуйте, Дарней, Вы писали:

Д>если бы ты сразу сказал, что ключевая проблема, с твоей точки зрения — это состояние, то сэкономил бы массу времени и мне, и себе

Д>потому что я совсем не обязательно должен думать в том же направлении, что и ты (правда, удивительный факт?)

Удивительнее то, что мне пришлось это повторять так много раз.

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


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

Д>Проблема наличия состояния и ООП — вещи абсолютно ортогональные.


В традиционном ООП — состояние вещь перманентная.

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


Ты же только что утверждал, что в CLOS не состояния вообще

Впрочем, с этим я спорить не буду. Состояние конечно же есть везде, только вопрос в том, какого время жизни этого состояния и является ли оно распределённым.

Д>также как и его наличие не создает эту проблему только фактом своего присутстия. Весь вопрос в дизайне системы, а ОО или не ОО — дело вообще десятое, не так ли?


Строя архитектуру на базе распределённого ООП ты не можешь этого избежать. И я пытаюсь тебе это сказать уже в десятый раз. Ты же мне в качестве контаргументов пытаешься доказать, что и без ООП можно накосячить. Можно, ещё раз тебе говорю. Да, можно, легко. Вот только в случае ООП у тебя не будет другого выхода.

Д>всего лишь пытался выяснить, что конкретно ты имел в виду тем примером. Сказать про состояние раньше ты почему-то забыл.


Я говорил о распределённости, которая не строится на ООП. О протокалах я вообще не говорил, это уровень коммуникации. Зачем ты его втащил в обсуждение вообще не понятно.

IT>>Ну хотя бы проблемы связанные с отсутствием строгой типизации.


Д>а кто сказал, что в смоллтоке, к примеру, нет строгой типизации? Скажи ты такое среди смоллтокеров — такой бы вой поднялся, что уши бы завяли

Д>ты просто путаешь слабую типизацию с динамической.

Таже фигня.

IT>>Вот опять ты за своё. Тебе ещё раз повторить, что бывают вещи необходимые, а бывают недостаточные?


Д>давай лучше я еще раз повторю, что среди пунктов "инкапсуляция, расширение, полиморфизм" нет пункта "обязательно иметь сосояние"?


Это всё нетрадиционные формы ориентации ООП. Учитвая, что сейчас нетрадиционные ориентации сильно в моде, то наверное в таком контексте ты прав
Если нам не помогут, то мы тоже никого не пощадим.
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.04.06 01:11
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>Проекция подразумевается как реляционная операция. Проекция — это трансформация типа. Что майнстримовые языки очень не любят.

Не, теперь у нас есть C#3, и там с этим почти все в порядке. Мне как раз нравится проекция, поскольку она позволяет четко разделить фазы выполнения запроса и использования результатов. Т.е. для того, чтобы получить ссылку на Product из OrderItem, я должен сразу же в запросе написать
from OrderItem o select o, o.Product

Попытка обратиться к o.Product в результатах — ошибка. (Причины — просты: есть риск, что к моменту dereference мы выйдем из контекста той транзакции, в которой выполнялся селект).
А еще лучше сразу написать
from OrderItem o select o.Amount, o.Product.FullName

потому что это позволит движку сделать всякие полезные оптимизации, избежать лишних букмарк лукапов и т.д. и т.п.
GZ>Уважаемый и ужастный Антон. Если вы хотя бы одним глазом заметили сии непотребные буквы на своем величайшем многопиксельном экране, прошу вас ответить. Что легче, парсить expression tree, или IL код? Заранее извиняюсь за беспокойство.
GZ>Вот, спросил.
Насколько я успел поверхностно разобраться — одна фигня. Потому что в лямбде я могу вставить вызов метода/свойства, и упс. Парни из Dlinq просто обошлись, AFAIK, набором готовых эвристик для трансляции известного кода. Типа "a".Length превращается в Len('a') и еще некоторый более-менее убогий набор функционала.
По-хорошему, надо делать так же, как сиквел разбирает UDF: лезть унутрь этого метода, смотреть в его MSIL и т.п. В частности, убеждаться в том, что метод не меняет состояние объекта (это сразу InvalidOperationException), проверять, не получилось ли случайно так, что можно воспользоваться индексом, и т.п. Иначе банальный селект, где сравнивается свойство с константой, будет сливать, т.к. индекс построен по полю. Так что от IL можно уйти только очень недалеко и ненадолго.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 11:24
Оценка: +1
Здравствуйте, Дарней, Вы писали:

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


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

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


Меняются? Скорее добавляются.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 11:35
Оценка: +1
Здравствуйте, EXO, Вы писали:

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

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

Не так. Задача клиента — обеспечивать взаимодействие с пользователем. А там есть еще обратное направление — преобразование действий пользователя в команды получения и изменения данных. И здесь все становится много-много печальнее.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[31]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.04.06 15:37
Оценка: +1
Здравствуйте, GlebZ, Вы писали:

GZ>гемоэнцэфалический барьер


Не сочтите за наезд, но <b>гематоэнцефалический</b> барьер
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.04.06 06:53
Оценка: :)
Здравствуйте, Adopt, Вы писали:
A>только не пинайте
A>Что такое таблица с B+ индексом?
Какое именно из слов тебе непонятно?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.05.06 04:22
Оценка: +1
Здравствуйте, GlebZ, Вы писал
GZ>Легко сказать да трудно сделать. Страдаю глобализмом.

GZ>Итак. Прежде всего некоторые тезисы. Тезисы по поводу РСУБД, касаются именно именно идеальной реляционки времен Кодда и SystemR. Кое что было решенов рамках СУБД, кое что с помощью сервисов поставляемые с той, или иной базой данных.
GZ>1. Недостаток РСУБД. Скудность информации данных. Зачастую о смысле данных можно узнать только перерыв приложение которое его использует.
Хм. Не очень ясно, что же ты имеешь в виду. Я попробую развернуть здесь эту критику поподробнее:
— отсутствие внятной концепции метаданных. Классический SQL вообще не содержал средств работы с метаданными. Клиентское приложение должно было получить знания о таблицах/view и их колонках эзотерическим путем). Справедливости ради стоит отметить, что в новых версиях стандарта SQL работа с метаданными таки предусмотрена
— малое внимание к связям. FK трактуются как декларативные ограничения, к которым довольно сложно получить доступ, в то время как это на самом деле first-class citizens. Фактически, объявление FK вводит новый тип данных — "ссылка на таблицу", и это должно быть очевидно и легкодоступно.
— 100% отсутствие информации о структуре бинарных объектов. Тут уже точно пошла жесткая необходимость рыться в исходниках клиентского приложения для понимания сути blob.
Работы по поддержке пользовательских типов вместо blob и переносе хотя бы части семантики внутрь БД не слишком скоординированы. Насколько я знаю, попытки стандартизовать UDT есть, но реальная картина в мире СУБД печальна: каждый производитель тянет одеяло на себя. Кстати, стоит отметить полную бесперспективность данного подхода в отстутствие управляемой среды: исполнение пользовательского кода в контексте сервера, который должен обеспечивать высокую надежность — самоубийство.

GZ>2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.

Я бы не был так категоричен. Сама по себе реляционная модель не может обладать никакой эффективностью. Есть средства эффективной реализации некоторых выражений реляционной алгебры. Например, это индексы. Важно понимать, что индексы не являются частью реляционной модели. Опять же важно понимать, что каждый тип индексов приспособлен для оптимизации определенного класса запросов. Популярность B+tree напрямую связана с широтой класса улучшаемых запросов. Тем не менее, B+tree — не панацея. Есть и другие типы индексов, которые могут оказаться уместными в различных ситуациях. В частности, агрегатные индексы, типичные для OLAP-баз, позволяют добиться невероятных результатов. При работе с древовидными данными разработчики как правило реализуют ту или иную схему индексации поверх основной реляционной модели (Селковские диапазоны или транзитивное замыкание).
Материализованное view — это паллиатив, попытка реализовать сразу несколько типов индексов, не встроенных в движок. Временные таблицы — это вообще нонсенс; это попытка обойти либо ограничения выразительности языка, либо ограничения оптимизатора. И если со вторым еще как-то можно смириться — оптимизаторы неуклонно совершенствуются, и нужда явно указывать способ хранения промежуточных результатов снижается, то проблема с первым напрямую связана с убогостью SQL. К этому пункту мы еще вернемся.
GZ>3. Недостаток РСУБД. Даже для задачи хранения и получения данных, нужны вычисления. А для вычислений нужен язык. В РСУБД были внедрены языки, но поскольку первичная их задача — доступ к данным. На вычислительную мощность, и, в большей степени, на удобство пользования разработчики положили.
GZ>4. Недостаток РСУБД. Недостаточность инкапсуляции. Вьюхи в классическом виде не выполняют своей роли полностью так как работают на чтение. На данный момент можно пользовать stored procedure, которую нельзя включить в custom SQL запрос. Или с помощью триггеров instead of навешанную на VIEW или Table. Еще в некоторых базах существуют функции(сразу признаюсь что не знаю, используются они в оптимизации запросов, или нет).
В общем-то да. Жизнь показала, что потребность в запросах в основном сводится к вытаскиванию данных. Опять же, нужно понимать, что стоимость движка напрямую зависит от заявленной функциональности. Я думаю, что нормальная спецификация SQL могла быть разработана еще в начале 80х, но она бы так и лежала на полке из-за проблем с реализацией.
Тем не менее, надо понимать, что фундаментальными проблемами SQL являются:
— отсутствие внятной модели скалярных функций, в том числе и с рекурсивным определением
— отсутствие внятной модели реляционных функций
Стоит отметить, что современные коммерческие RDBMS хоть как-то пытаются решать эти вопросы. Тем не менее, я до сих пор не знаю СУБД, где можно передать внутрь функции ссылку на реляционное выражение. Все, что пока возможно — это построить функцию со скалярными аргументами, которая вернет таблицу. Причем далеко не все производители реализуют такую функциональность с приемлемой эффективностью. Abstraction penalty в некоторых случаях больше похожа на death sentence: например, в Interbase никакой оптимизации табличных функций в принципе не было (на момент версии 5.6, с которой я съел достаточное количество соли, возможно это исправили в новых клонах). В MS SQL разработчику хотя бы дают выстрелить себе в ногу.
Вместо расширения декларативной модели, комитет изобретает частные затычки — например, CTE. О, классно, мы теперь можем делать рекурсивные запросы, ура! Если бы SQL позволял писать table-valued функции с табличными параметрами, мы получили бы то же самое в качестве побочного эффекта. Увы и ах.


GZ>5. Недостаток OOСУБД. Инкапсуляция. Инкапсуляция хороша от внешних злодеев, и очень вредна внутри OOСУБД. Наибольший пострадавший в данном случае — оптимизатор запросов.

Это неверно. Инкапсуляция вовсе не означает криптологию: она фактически запрещает строить код, статически завязанный на подробности реализации, а вовсе не получать информацию о внутреннем устройстве кода. Ну, вот например, допустим компилятор С++ видит в некотором месте вызов метода A::a(). Соответствие областей видимости компилятор проверит первым делом, так что внешний код скомпилируется только если a() public, и т.п. Но сразу после выполнения этой проверки компилятор может забыть все эти модификаторы доступа. Если внутри этого метода всего лишь идет обращение к полю экземпляра, пусть даже и приватному, компилятор имеет полное право устранить вызов путем инлайнинга и выполнять прочие модификации. С точки зрения С++, private прячет интимности от кода, но не от компилятора. С точки зрения управляемой среды, оптимизатор всего лишь имеет права "врача, священника, и мужа" по отношению к коду хранимых сущностей, т.е. соответствующий reflection permission. Это никак не нарушает инкапсуляцию.

GZ>6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.

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

GZ>7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.

Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием. Вообще, конечно же, статическая трактовка данных, принятая в RDBMS, сильно упрощает жизнь. Хотя это вовсе не 100% упрощения, и проблемы с сопровождением все равно есть. В самом оптимистичном случае, когда вносимые изменения не требуют модификации фактологической модели (т.е. мы, к примеру, все еще считаем "телефон" скалярным атрибутом сущности "клиент", а не заменяем это на связь многие-ко-многим), все равно есть риск нарваться на несовместимость логики, когда данные находятся в состоянии, валидном с точки зрения предыдущей модели, но недостижимом в новой модели. Основное упрощение в RDBMS связано с тенденцией консолидировать логику в относительно небольшое количество крупных фрагментов. Однако у этой палки есть и обратная сторона: низкий уровень декомпозиции увеличивает общий объем необходимых изменений. В хорошо спроектированной объектной модели логика состоит из большого количества слабо связанных фрагментов, и все изменения можно четко локализовать.

GZ>8. Принцип Деметры(принцип хорошего проектирования):

GZ>

GZ>Для любого класса C и для любого метода M, связанного с C, все объекты, которым M посылает сообщение, должны быть экземплярами классов, ассоциированными со следующими классами: классами аргументов M (включая C); классами переменных экземпляра C.

GZ>Взято отсюда.здесь. Интересная статья, советую прочитать.
GZ>9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.
На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.

GZ>9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.

?
GZ>10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
?
GZ>12. Недостаток OODB. Он пытается увеличить скорость навигационных запросов путем адаптации хранилища к ним. Он сознательно адаптирует хранилище под конкретное приложение согласно объектной схеме. (Это я намекаю на хранение подчиненных коллекций и объектов вместе с объектом владельцем). Соответвенно теряется эффективность ad-hoc запросов.
Угу. Я считаю это членоудлинительством: много рекламы и мало практической ценности. Такие ODBMS оптимизируют самую ненужную операцию: инстанцирование комплексных объектов. Вместо этого необходимо уменьшать количество объектов, которые надо инстанцировать в рамках выполнения запроса.
GZ>12. Для оптимизатора запросов важна подробная информация.
Ну, с этим никто не спорит. Вообще здесь, как и много где еще, работает правило Парето: 80% успеха обеспечивается 20% усилий.
В частности, для RDBMS оказывается, что даже минимальной статистики (типа количества уникальных значений ключа индекса) достаточно для выбора планов, близких к оптимальным. Следующий шаг — построение гистограмм распределений — позволяет добиться еще некоторого сокращения лишних операций. Дополнительная семантическая оптимизация на основе данных о констреинтах позволяет улучшить планы в граничных случаях. В принципе, уже этой информации достаточно оптимизатору для того, чтобы почти не оставить шансов человеку на улучшение запросов.
Вменяемый ODBMS оптимизатор должен справляться не хуже. Все, что ему нужно — доступ к телу используемых методов. Все равно в итоге идет обращение к полям экземпляров и классов; поэтому особенной разницы в оптимизациях нет. С одной стороны, все кажется сложным — типичный "объектный" запрос будет иметь значительно более сложное AST, чем типичный реляционный. С другой стороны, есть очень хороший шанс использовать кэш. В частности, если посмотреть на статистику Jit для Януса, то окажется, что в этом приложении обработано всего ~2600 методов. Новые методы будут появляться крайне редко (относительно количества вызовов этих методов), а, значит, можно не выполнять дорогостоящий анализ каждый раз.

GZ>Итак вооружившись этими тезисами, начинаю сочинять(играю как умею, в пианиста не стрелять).

Я пока поскипаю обсуждение конкретных предложений, т.к. не готов играть на равных
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[45]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 02.05.06 16:03
Оценка: :)
Здравствуйте, IT, Вы писали:

Всё-таки оставил последнее слово за собой, хитрец
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 20.04.06 09:28
Оценка:
Здравствуйте, Merle, Вы писали:

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

Иван, что-то здесь не понял. А какие были БД в 70-ых?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re: Файловые системы, файлы, приложения - устаревшие конц
От: shuklin  
Дата: 20.04.06 11:31
Оценка:
Здравствуйте, Merle, Вы писали:

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


S>> Какие здесь подводные камни?

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

Да. И считаю это основным достоинством ОБД.

M>что как минимум довольно здорово ограничивает возможности самих данных. Все бы ничего, если бы речь шла о какой-то конкретной довольно узкой задаче, ...


Если так, то stored procedures в БД места быть не должно
Re[2]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 11:51
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Да. И считаю это основным достоинством ОБД.

А я считаю это причиной того, что ООБД обречены.

S>Если так, то stored procedures в БД места быть не должно

Не передергивай. sp — это лишь программа, которая может лежать где угодно, на сами данные она ни как не влияет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[2]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 11:51
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Иван, что-то здесь не понял. А какие были БД в 70-ых?

Кто говорил про БД? Я говорил про данные...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[3]: Файловые системы, файлы, приложения - устаревшие конц
От: shuklin  
Дата: 20.04.06 12:10
Оценка:
Здравствуйте, Merle, Вы писали:

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


S>>Да. И считаю это основным достоинством ОБД.

M>А я считаю это причиной того, что ООБД обречены.

А я считаю это причиной того, что РБД обречены на провал, а ОБД обречены на успех.
Время нас рассудит.
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 12:40
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Время нас рассудит.

Время уже расудило.
Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату — ни одной полноценной ООБД успешно проявившей себя на хоть сколь-нибудь заметном количестве промышленных задачь так и не появилось, не смотря на многочисленные попытки. А все потому, что данные != объект, и загонять данные в рамки объекта, ограничивая тем самым возможности по их интерпретации, можно только в случаях очень высокой предсказуемости системы, но, к сожалению, величиная таких задачь исчезающе мала.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[5]: Файловые системы, файлы, приложения - устаревшие конц
От: shuklin  
Дата: 20.04.06 12:49
Оценка:
Здравствуйте, Merle, Вы писали:

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


S>>Время нас рассудит.

M>Время уже расудило.
M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату — ни одной полноценной ООБД успешно проявившей себя на хоть сколь-нибудь заметном количестве промышленных задачь так и не появилось, не смотря на многочисленные попытки. А все потому, что данные != объект, и загонять данные в рамки объекта, ограничивая тем самым возможности по их интерпретации, можно только в случаях очень высокой предсказуемости системы, но, к сожалению, величиная таких задачь исчезающе мала.

Это очень ограниченная точка зрения. В плане структурной интерпретации данных ОБД гораздо багаче РБД и включают РБД в себя как частный случай. Однако создание ООСУБД технически гораздо более сложная задача, по сравнению с созданием РСУБД. Развитие пошло просто по более простому пути. А последние выбрыки производителей РСУБД по включению туда поддержки деревьев, XML и прочего как раз говорят о начинающемся закате РСУБД.
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 13:22
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Это очень ограниченная точка зрения.



S> В плане структурной интерпретации данных ОБД гораздо багаче РБД

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

S> и включают РБД в себя как частный случай.

А вот это, пожалуй, довольно однобокая точка зрения..

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

Технически ничего сверхсложного нет. Современным движкам РСУБД, по большему счету, совершенно все равно что хранить внутри, реляционные таблицы или совершенно абстрактные объекты.

S> Развитие пошло просто по более простому пути.



S>А последние выбрыки производителей РСУБД по включению туда поддержки деревьев, XML и прочего как раз говорят о начинающемся закате РСУБД.

У меня есть любмая байка по этому поводу. Знаешь как MSSQL хранит XML для оптимальной вставки, поиска и вообще работы XQuery?
По некоторым данным ребята потратили около восьми лет на исследования как это лучше сделать, а в итоге пришли все к той же банальной реляционной таблице с B+ индексом, вот и весь XML.
Так что идет не уход от реляционки, а наоборот, скорее развитие реляционки, в сторону навешивания на нее как можно большего встроенного функционала.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[5]: Файловые системы, файлы, приложения - устаревшие конц
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.04.06 13:46
Оценка:
Здравствуйте, Merle, Вы писали:

M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату — ни одной полноценной ООБД успешно проявившей себя на хоть сколь-нибудь заметном количестве промышленных задачь так и не появилось, не смотря на многочисленные попытки. А все потому, что данные != объект, и загонять данные в рамки объекта, ограничивая тем самым возможности по их интерпретации, можно только в случаях очень высокой предсказуемости системы, но, к сожалению, величиная таких задачь исчезающе мала.


ИМХО, любой апликейшен сервер это как-бы ООБД. Которая может использовать внешнюю РБД для хранения данных, индексации. Не зря Gemstone/S предпочитают называть не ООБД, а именно сервером приложения.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[5]: Файловые системы, файлы, приложения - устаревшие конц
От: Дарней Россия  
Дата: 20.04.06 13:46
Оценка:
Здравствуйте, Merle, Вы писали:

M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату


надо же, как интересно. А что, объектов больше не будет?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.04.06 13:58
Оценка:
Здравствуйте, Дарней, Вы писали:

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату


Д>надо же, как интересно. А что, объектов больше не будет?


ИМХО он имел ввиду ООБД.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: shuklin  
Дата: 20.04.06 13:59
Оценка:
Здравствуйте, Merle, Вы писали:


S>> В плане структурной интерпретации данных ОБД гораздо багаче РБД

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

Ок. Давайте подискутируем на эту тему. Меня она очень интересует как разработчика собственной ООСУБД/БЗ


M>Как ты будешь интерпретировать инкапсулированные данные, расскажи пожалуйста.

— инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП. Действительно строить индексы по вычисляемым полям объектов занятие не для слабонервных. Но ведь и РБД это не умеют. Это просто очень нетривиальная задача, не зависимо от того сеть или таблица является физическим уровнем для хранения полей объектов.

В своей ОБД я пришел к следующему.

— инкапсуляция не рекомендуется к применению. Поля объекта открыты для доступа независимо от методов самого объекта. К этим полям система может обращаться не инстанциируя сам объект.

— для особых случаев допускается бинарная сериализация ЧАСТИ объекта. В этом случае программист отгребает все от ручной сериализации и прочих недостатков, о которых ты намекаешь. Согласен. Зато бинарная сериализация действительно быстрее.
Я предпочитаю иметь и предоставлять выбор, работать в стиле РБД — без явной инкапсуляции, либо в стиле ООП.

Теперь расмотрим VIEW как аналог инкапсуляции в РБД. Я поддерживаю объектные VIEW. Поддержка реализована на двух уровнях.
— на уровне модели данных один и тот же аттрибут может быть чайлдом нескольких экземпляров объектов. Это позволяет формировать объекты являющиеся JOIN аттрибутов других объектов, без потери идентичности и возможности адресации аттрибутов по указателям.

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

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


В последней версии тоже просто — благодаря сетевой архитектуре поддерживаемой на нескольких "уровнях". Экземпляр объекта представляет собой некоторого вида "иерархию" аттрибутов. Однако аттрибут может иметь несколько парент объектов. (паттерн FLYWEIGHT) Таким образом можно строить на основе одних и тех же экземпляров (скаляров, композитов) различные иерархии. — это "глубинный уровень". Тоесть "иерархия" является на самом деле сетью.

Во всех версиях на "семантическом уровне" благодаря возможности окраски связей графа с помощью ИД можно проводить операции близкие к JOIN в РБД. Тоесть что то типа WHERE ИД_СВЯЗИ(связь) = ИД_ОБЪЕКТА(объект) А это в Cerebrum было всегда. Даже в VNPI-99


S>> и включают РБД в себя как частный случай.

M>А вот это, пожалуй, довольно однобокая точка зрения..

Как раз нет. Самый примитивный вариант ОБД — это РБД с еще одним дополнительным скрытым полем в строке — vtbl и возможностью вызова через этот vtbl методов ассоциированных со строкой.


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

M>Технически ничего сверхсложного нет. Современным движкам РСУБД, по большему счету, совершенно все равно что хранить внутри, реляционные таблицы или совершенно абстрактные объекты.

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

M>Так что идет не уход от реляционки, а наоборот, скорее развитие реляционки, в сторону навешивания на нее как можно большего встроенного функционала.


Тем хуже для Microsoft & Oracle. Почемуто я им не сочуствую ))))
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.04.06 14:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ANS>>ИМХО, любой апликейшен сервер это как-бы ООБД. Которая может использовать внешнюю РБД для хранения данных, индексации.


AVK>Но, в отличие от ООБД, сервер приложений не намертво привинчен к данным.


Видимо не нужно /было/ иерархические БД называть ООБД. Тогда термин ООБД, можно будет /можно было бы/ использовать более "по назначению".
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 14:54
Оценка:
Здравствуйте, shuklin, Вы писали:

S>- инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП.

Понятно. Вот и не объектная у нас бд...

S> Но ведь и РБД это не умеют.

Это не отмазка. Реляционка так и задумывалась как голые данные, а в объектах должна быть инкапсуляция иначе это уже не объекты.

S> Это просто очень нетривиальная задача

Она, прямо скажем, не разрешима на современном уровне развития техники.

S>Я предпочитаю иметь и предоставлять выбор, работать в стиле РБД — без явной инкапсуляции, либо в стиле ООП.

При этом рекомендованый в стиле реляционки. Классная ООБД получается..

S>В последней версии тоже просто — благодаря сетевой архитектуре поддерживаемой на нескольких "уровнях". Экземпляр объекта представляет собой некоторого вида "иерархию" аттрибутов. Однако аттрибут может иметь несколько парент объектов. (паттерн FLYWEIGHT) Таким образом можно строить на основе одних и тех же экземпляров (скаляров, композитов) различные иерархии. — это "глубинный уровень". Тоесть "иерархия" является на самом деле сетью.

Вот и получаем, вместо прохода по плоскому списку ползание по иерархиям... Задумайся, почему при работе с обычной реляционкой, в большинстве случаев, для построения отчетов все ORM посылаются в лес и гоняются прямые и незатейливые запросы к плоским данным...

S>Как раз нет. Самый примитивный вариант ОБД — это РБД с еще одним дополнительным скрытым полем в строке — vtbl и возможностью вызова через этот vtbl методов ассоциированных со строкой.

И кто кого после этого частный случай..

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

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

S>Тем хуже для Microsoft & Oracle.

Ню-ню...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 14:54
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>надо же, как интересно. А что, объектов больше не будет?

Почему? Кудаже без них, только вот не везде и не всегда с ними удобно.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 20.04.06 15:00
Оценка:
Здравствуйте, Merle, Вы писали:

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


S>>- инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП.

M>Понятно. Вот и не объектная у нас бд...

Можете считать ее какой угодно

S>> Но ведь и РБД это не умеют.

M>Это не отмазка. Реляционка так и задумывалась как голые данные, а в объектах должна быть инкапсуляция иначе это уже не объекты.

Моя тоже так задумывается, дальше что?

S>> Это просто очень нетривиальная задача

M>Она, прямо скажем, не разрешима на современном уровне развития техники.

Посмотрим

S>>Я предпочитаю иметь и предоставлять выбор, работать в стиле РБД — без явной инкапсуляции, либо в стиле ООП.

M>При этом рекомендованый в стиле реляционки. Классная ООБД получается..

Именно как задумывается так и получаецца

M>Вот и получаем, вместо прохода по плоскому списку ползание по иерархиям... Задумайся, почему при работе с обычной реляционкой, в большинстве случаев, для построения отчетов все ORM посылаются в лес и гоняются прямые и незатейливые запросы к плоским данным...


Если ОРМ посылаются в лес, странно что туда же РБД за компанию не посылают При ползании по JOINs и лишним индексам — туда им и дорога.
Только не надо говорить, что в промышленных сценариев JOINами и не пахнет

M> либо один человек за год слабал...

А ты загрузи и зацени
Потом сюда недостатки, я их обдумаю, и возможно приму к разработке. По любому будет от меня тебе пасибо.
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: Дарней Россия  
Дата: 20.04.06 16:39
Оценка:
Здравствуйте, Merle, Вы писали:

M>Почему? Кудаже без них, только вот не везде и не всегда с ними удобно.


а где с ними неудобно, интересно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 20.04.06 16:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Но, в отличие от ООБД, сервер приложений не намертво привинчен к данным.

Что значит привинчен?
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 17:26
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Можете считать ее какой угодно

S>Моя тоже так задумывается, дальше что?
Дальше — не надо называть ее "О". И вообще про объекты речь не вести.

S>Если ОРМ посылаются в лес, странно что туда же РБД за компанию не посылают

Ну я же предложил тебе задуматься. Подумай, почему ORM посылают, и обращаются напрямую к реляционке.

S>При ползании по JOINs и лишним индексам — туда им и дорога.

Индексы здесь непричем.

S>А ты загрузи и зацени

Пока такого желания нет, идеология неверная.

S>Потом сюда недостатки.

На недостатки я уже указал — иерархические БД и в частности объектные, подходят для довольно узкого класса задачь, причину я указывал...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 18:00
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>а где с ними неудобно, интересно?

Например, везде, где необходимо работать с голыми данными, БД, распределенка, репорты, ect... О причинах я уже рассказывал...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 20.04.06 18:00
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Зачем так категорично.

Лучше сразу с этим смириться...

GZ> Мое IMHO что эпоха ООБД еще не начиналась.

Да пора бы уже заканчиваться, она лет 15 все начинается...

GZ> это весеннее обострение.

Да уж, только пригибайся..
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[5]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 20.04.06 18:22
Оценка:
Здравствуйте, Merle, Вы писали:

GZ>> Мое IMHO что эпоха ООБД еще не начиналась.

M>Да пора бы уже заканчиваться, она лет 15 все начинается...
Вон Влад и adontz возятся с новой игрушкой. Как дети. Значит что-то кардинальная изюминка в ней есть. А общая идея ведь датируется шестидесятыми.
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 21.04.06 03:27
Оценка:
Здравствуйте, Merle, Вы писали:

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


если есть данные и есть методы для работы с ними — это уже ООП.... Не вижу ни в одном из этих случаев ни малейших проблем.
а где именно рассказывал?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: Дарней Россия  
Дата: 21.04.06 03:27
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Вон Влад и adontz возятся с новой игрушкой. Как дети. Значит что-то кардинальная изюминка в ней есть. А общая идея ведь датируется шестидесятыми.


ничто не ново под луной... секс вообще в незапамятные времена изобрели, и до сих пор не надоедает
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: Дарней Россия  
Дата: 21.04.06 06:11
Оценка:
Здравствуйте, IT, Вы писали:

IT>Будут радёмые, куда же без них. Но вот совать ООП куда ни попадя, как то в базы данные или в распределённые среды, где ООП плохо работает, и искать в ООП панацею народ потихонечку прекращает.


Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?

IT>Самодостаточная персистентная распределённая объектная модель мира — это утопия.


А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично. Можешь подставить "функциональная", "структурная", "реляционная" или просто "математическая" — утопизма от этого не убавится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 07:30
Оценка:
Здравствуйте, Merle, Вы писали:

S>>Можете считать ее какой угодно

S>>Моя тоже так задумывается, дальше что?
M>Дальше — не надо называть ее "О". И вообще про объекты речь не вести.

А может не надо ODMG называть объектной группой ? Это вопрос точки зрения. Моя личная практика говорит мне что это у них и у Вас с идеологией проблемы
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 07:34
Оценка:
Здравствуйте, Merle, Вы писали:

Д>>а где с ними неудобно, интересно?

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

Ваши доводы или совершенно неубедительны, или доказывают прямопротивоположную точку зрения.
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 07:38
Оценка:
Здравствуйте, IT, Вы писали:


S>>- инкапсуляция не рекомендуется к применению.

S>>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта.

IT>Это уже не OODB, а COODB, где C абревиатура от castrated. Это как раз то о чём говорит Иван, получается ни два, ни полтора. Кастрированная объектная модель и такая же неполноценная база данных.


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

IT>Кстати, современные ОРМ и всевозможные мапперы совсем неплохо справляются с преобразованием данных БД в объектную модель и наоборот. На это у разработчиков уходит всё меньше и меньше времени. Для большинства операций это реализуется зачастую лишь одной строчкой кода. При этом мы имеет и полноценную БД и ничем искуственно не ограниченную объектную модель.


И на маппинг там время не тратится, и сети поддерживаются по полной, Ну ну.
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 07:41
Оценка:
Здравствуйте, Дарней, Вы писали:


Д>если есть данные и есть методы для работы с ними — это уже ООП.... Не вижу ни в одном из этих случаев ни малейших проблем.

Д>а где именно рассказывал?

Аналогично. В отличие от педантов, для которых секурити (инкапсуляция) важнее функциональности, я считаю основным достоинством ООП полиморфизм. А вот его то я поддерживаю в своей БД максимально.
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 07:42
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>если есть данные и есть методы для работы с ними — это уже ООП....

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

Д> Не вижу ни в одном из этих случаев ни малейших проблем.

Везет же...

Д>а где именно рассказывал?

Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц
Автор: Merle
Дата: 20.04.06
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 07:47
Оценка:
Здравствуйте, Merle, Вы писали:

Д>>если есть данные и есть методы для работы с ними — это уже ООП....

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

полиморфизм и инкапсуляция — разные вещи. В своей СУБД Я поддерживаю

— полиморфизм методов (наследование + виртуальные методы)
— полиморфизм интерфейсов
— полиморфизм структуры объекта (одна структура может "притвориться" другой структурой)

Первые два — на уровне инстанциированных экземпляров, третье — напрямую в модели данных.
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 07:56
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Ваши доводы или совершенно неубедительны,

Аргументы кончились? Не нравится — не ешь..

S> или доказывают прямопротивоположную точку зрения.

Это какую и каким образом?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 07:56
Оценка:
Здравствуйте, shuklin, Вы писали:

S>А может не надо ODMG называть объектной группой ?

Причем здесь ODMG, речь о твоей системе. Вообще я заметил у тебя тяга пытаться разговор менять, когда аргументы кончаются...

S>Это вопрос точки зрения.

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

S> Моя личная практика говорит мне что это у них и у Вас с идеологией проблемы

Безумству храбрых...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.04.06 08:03
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Что значит привинчен?


То и значит, что в ООБД данные неразрывно связаны с кодом.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 08:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>То и значит, что в ООБД данные неразрывно связаны с кодом.


А в РБД данные связаны с СП. Какие проблемы? Что в РБД что в ОБД с этим проблем нет.

И еще свои две копейки. В СУБД Cerebrum можно менять сборки не меняя хранилище БД. Формат хранения объектов ваааще никак не связан с реализацией этих объектов в языке программирования.

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


Итак, ОБД по этому вопросу ничем не уступает РБД.
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 08:10
Оценка:
Здравствуйте, shuklin, Вы писали:

S>полиморфизм и инкапсуляция — разные вещи.

Кто бы спорил...

S> В своей СУБД Я поддерживаю

Молодец. А теперь вспомни, что ты там не поддерживаешь. И уж коль мы выяснили, что СУБД у тебя не объектная, а здесь речь идет об ООП, то причем здесь собственно твоя СУБД?

S>Первые два — на уровне инстанциированных экземпляров, третье — напрямую в модели данных.

То есть, для того чтобы проверить полиморфный метод на соответствие предикату его надо инстанцировать, а значит индексы идут в лес, сколько у нас при этом будет занимать поиск можно хорошо представить.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 08:20
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Извините, но у Вас я вообще аргументов не заметил.

Меня всегда поражает способность не замечать неудобные вещи... =)

S> Только декларацию того что ОБД это бесперспективно.

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

S>Ну не любишь ты ОБД,

Я их не нелюблю. Я просто предпочитаю использовать в работе наиболее подходящий инструмент.
Тем более, как мы выяснили, ООБД здесь непричем.

S> Знаешь, мне с тобой беседовать просто скушно.

Еще бы, сложно смотреть правде в глаза..

S> Ни на один мой тезис о внутреннем устройсве Cerebrum ты не ответил.

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

S> Жалко на такое время тратить.

Сам же критики просил, теперь обижаешься...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 21.04.06 08:20
Оценка:
Здравствуйте, Merle, Вы писали:

Д>>если есть данные и есть методы для работы с ними — это уже ООП....

M>Смело... Ну пусть.
M>Далее, в зависимости от задачи, для одних и тех же данных нужны разные методы, соответственно, следуя твоей логике, разное ООП.

а можно поподробнее, как это?

M>Как перейти из одного ООП к другому ООП минуя прямую работу с данными?


Не бывает разных ООП, бывают разные декомпозиции. Одни из них удачные, другие не очень. Нужно выбирать удачные

M>Везет же...


везение здесь ни при чем, я тебя уверяю

Д>>а где именно рассказывал?

M>Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц
Автор: Merle
Дата: 20.04.06


много букв, еле осилил . Насколько я понял, основная и единственная мысль в том, что семантика данных в БД может меняться, а поведение объектов — нет.
Откуда такое ограничение?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 08:23
Оценка:
Здравствуйте, Merle, Вы писали:

О пошла конкретика, байкот временно снимается

S>> В своей СУБД Я поддерживаю

M>Молодец. А теперь вспомни, что ты там не поддерживаешь. И уж коль мы выяснили, что СУБД у тебя не объектная, а здесь речь идет об ООП, то причем здесь собственно твоя СУБД?

Это кто выяснил? С этой глупостью только ты тут маешся объектная/необъектная. Все уже давно все выяснили. Хранилище есть? — есть. Объекты C# хранятся? — хранятся. Модель данных есть? — сетевая. — Значить ООСУБД


S>>Первые два — на уровне инстанциированных экземпляров, третье — напрямую в модели данных.

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

1. незабываем про пункт 3.
2. ОБД тем и интересны, что обеспечивают методы разработки, которые не требуют никакого поиска вааааще и в том числе никакого поиска объектов на основе предикатов в 90% случаев. В Остальных 10% завсегда есть возможность плавно скатиться к старым проверенным методам поиска аля РБД (с сохранением сетевой модели данных).
3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)
4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД. Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.
5. Это у тебя с полиморфизмом какойто детский комплекс его якобы необходимости для ОБД во всех случаях? Когда нужен ОБД должна позволять его реализовать. Когда не нужен — должна позволить проиндексировать поле объекта в стиле РБД. Какие проблемы? Выбор у разработчика.

Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.04.06 08:23
Оценка:
Здравствуйте, shuklin, Вы писали:

AVK>>То и значит, что в ООБД данные неразрывно связаны с кодом.


S>А в РБД данные связаны с СП. Какие проблемы?


Нет, не связаны. Хранимки можно спокойно грохнуть или переписать, не озабачиваясь ни какой совместимостью. Если ООБД позволяет аналогичную операцию, то это никакая не ООБД.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 08:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:


AVK>Нет, не связаны. Хранимки можно спокойно грохнуть или переписать, не озабачиваясь ни какой совместимостью. Если ООБД позволяет аналогичную операцию, то это никакая не ООБД.


Моя — позволяет. Ты предлагаешь мне назвать мое изделие "пост объектной БД"?, ну это уш как то слишком )) пусть останется СООБЗ — как это в ее официальном текущем ее названии : Сетевая объектно ориентированная база знаний Cerebrum http://www.shuklin.com/ai/ht/ru/cerebrum — там еще нейронки отдельным модулем прикручены — но это оффтопик в этой ветке.
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 21.04.06 08:45
Оценка:
Здравствуйте, IT, Вы писали:

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

А кто сказал что в распределенной среде ООБД плохо живется?
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.04.06 09:36
Оценка:
Здравствуйте, shuklin, Вы писали:

AVK>>Нет, не связаны. Хранимки можно спокойно грохнуть или переписать, не озабачиваясь ни какой совместимостью. Если ООБД позволяет аналогичную операцию, то это никакая не ООБД.


S>Моя — позволяет. Ты предлагаешь мне назвать мое изделие "пост объектной БД"?,


Я предлагаю не называть ее объектной БД.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 09:39
Оценка:
Здравствуйте, AndrewVK, Вы писали:

S>>Моя — позволяет. Ты предлагаешь мне назвать мое изделие "пост объектной БД"?,


AVK>Я предлагаю не называть ее объектной БД.


Какое название ты считаешь более адекватным?
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 09:40
Оценка:
Здравствуйте, shuklin, Вы писали:

S>О пошла конкретика, байкот временно снимается

Как то ты быстро от своих слов отказываешься...

S>Это кто выяснил?

Я, еще вчера.

S>С этой глупостью только ты тут маешся

Ну, кто чем тут мается, у меня уже тоже сложилось четкое представление...

S> Все уже давно все выяснили.

Во-во.

S> Объекты C# хранятся?

Нет.

S> Модель данных есть?

Причем здесь модель данных?

S>2. ОБД тем и интересны, что обеспечивают методы разработки, которые не требуют никакого поиска вааааще и в том числе никакого поиска объектов на основе предикатов в 90% случаев.

То есть в 90% случаев ООБД не применимы, так как в реальной жизни нужен предикат. Мнене нужен вася пупкин окончивший школу в 2004 году, а не абстрактный объект с гуидом.

S>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта.

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

S>4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД.

О чем я и говорю. И если берем честную ООБД, то вспоминаем про инкапсуляцию и индексы отдыхают со 100% гарантией.

S> Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.

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

S>5. Это у тебя с полиморфизмом какойто детский комплекс

Скорее дело в том, что у тебя нет понимания того, что такое ООП, а все туда же — ООБД писать...

S> его якобы необходимости для ОБД во всех случаях?

То есть у нас теперь и полиморфизм не так уж в ОО необходим, замечательно. Следующее на очереди у нас, наверное, наследование...
Вот скажи мне, так ли нужно наследование в ООП?

S>Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.


Значит, вместо реляционки получили сетевую БД, не подходящую для 90% задачь, заплатку для ассоциативных запросов, коих подавляющее большинство в реальных системах, и после этого начинаем говорить о преимуществе и мощи? Забавно, право слово, этож как фанатеть-то надо...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 09:40
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>а можно поподробнее, как это?

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

Д>Не бывает разных ООП, бывают разные декомпозиции.

Не-не, все в рамках твоего определения.

Д>Одни из них удачные, другие не очень. Нужно выбирать удачные

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

Д>везение здесь ни при чем, я тебя уверяю

Не надо, не уверяй..

Д>Откуда такое ограничение?

Ответь на первый вопрос.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.04.06 09:56
Оценка:
Здравствуйте, shuklin, Вы писали:

AVK>>Я предлагаю не называть ее объектной БД.


S>Какое название ты считаешь более адекватным?


Не знаю. Надо сидеть и разбираться.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 10:04
Оценка:
Здравствуйте, Merle, Вы писали:

S>>О пошла конкретика, байкот временно снимается

M>Как то ты быстро от своих слов отказываешься...

В отличие от некоторых я открыт к компромисам. "Я хозяен своего слова, я его дал, я и обратно забрал"

S>>Это кто выяснил?

M>Я, еще вчера.

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

S>> Объекты C# хранятся?

M>Нет.

Ага, а ты даже проверял? От этого перла я ваще офигел

S>>2. ОБД тем и интересны, что обеспечивают методы разработки, которые не требуют никакого поиска вааааще и в том числе никакого поиска объектов на основе предикатов в 90% случаев.

M>То есть в 90% случаев ООБД не применимы, так как в реальной жизни нужен предикат. Мнене нужен вася пупкин окончивший школу в 2004 году, а не абстрактный объект с гуидом.

У этого васи как раз и будет ИД по которому его можно будет завсегда найти без всяких там предикатов. В 90% искать надо как раз не абстрактного васю выгнанного с школы в 2004 году, а конкретного и определенного, с некоторым ИД. Это даже в 90% реализаций БД для РБД так.

S>>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта.

M>Не пойдет, сам же писал, объект надо инстанцировать, чтобы полиморфный метод вызвать, то есть до инстанцирования объекта ты не можешь значть значение метода, значит при поиске надо явно инстанцировать кажный объект в коллекции.

Объект надо инстанциировать чтоб обновить индекс. При изменении объекта через его методы инстанциация нужна по любому. И это то что и требуется. Онто при изменении и будет инстанциирован. И изменяемая в РБД строка тоже будет в RAM загружена. Тут аналогия полная. А вот при поиске ничего лишнего инстанциировать ненужно, т.к. индекс это уже не экземпляры объектов. Нашел по индексу букмарк, по нему или прочел поле объекта напрямую, или провел инстанциирование — в зависимости от конкретной текущей задачи. Что в РБД что в сетевой ОБД — реализация одинаковая. Модели данных разные. Не вижу я тут проблему. Надумал ты ее.

S>>4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД.

M>О чем я и говорю. И если берем честную ООБД, то вспоминаем про инкапсуляцию и индексы отдыхают со 100% гарантией.

Ну если с твоей точки зрения честная ООБД та, в которой все что тебе бы хотелось чтобы не работало в ООбД не работает — то такая ООБД действительно отдохнет. Только не надо такую надуманную тобой ООБД обобщать на все остальные ООБД. Так я надумаю РБД без ордер бай и нуллов — и буду тебе тыкать статьями Дейта.


S>> Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.

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

Вот уш чего чего, а оговорок области применения ООБД я от тебя не заметил. Может пост прозевал. Приведешь ссылку?

S>>5. Это у тебя с полиморфизмом какойто детский комплекс

M>Скорее дело в том, что у тебя нет понимания того, что такое ООП, а все туда же — ООБД писать...

Если догма приоритетней — пусть такое догматичное ООП катится куда подальше. А если приорететнее функциональность — то тудаже с догмами.


M>Вот скажи мне, так ли нужно наследование в ООП?


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

Полиморфизм более желателен чем наследование. Я поддерживаю как структурный так и поведения. Вот без чего в ООП будет грусно — так без полиморфизма.


M>Значит, вместо реляционки получили сетевую БД, не подходящую для 90% задачь, заплатку для ассоциативных запросов, коих подавляющее большинство в реальных системах, и после этого начинаем говорить о преимуществе и мощи? Забавно, право слово, этож как фанатеть-то надо...


И что ты куришь чтоб к таким выводам приходить и так слова собеседников переврать?
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 10:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не знаю. Надо сидеть и разбираться.


СООБЗ — это самое близкое к тому что я уже сделал/собираюсь сделать и что я смог сформулировать достаточно коротко.
Если найду более адекватное название — само собой переименую.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 10:16
Оценка:
Здравствуйте, Merle, Вы писали:


Д>>Одни из них удачные, другие не очень. Нужно выбирать удачные

M>Ок, удачная декомпозиция для разных задачь по одним и тем же данным будет разная. Как перейти от одной к другой минуя прямую работу с данными?

Сетевая модель, в отличии от иерархической (для иерархической ОМД все твои замечания действительно полностью адекватны) позволяет представлять один и тот же элемент данных одновременно в разных декомпозициях. И кстати, и в отличии от РМД в которой все данные жестко прибиты к кортежам. Чтобы в РМД перейти от одной нарезки (НФ) к другой нужно делать безумные JOINs. Что делает РМД эквивалентной иерархической модели. Тоесть выявленная тобой проблема одинаково присуща как иерархическим так и реляционным моделям. Хотя РМД по сравнению с иерархической выглядит несколько адекватнее.

И в этом случае РМД + РБД отдыхают по сравнению с сетевыми ОМД/ОБД.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 21.04.06 10:22
Оценка:
Здравствуйте, Merle, Вы писали:

M>Это у тебя надо спрашивать. Ты такое определение придумал, вот и пляши от него...


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

Д>>Не бывает разных ООП, бывают разные декомпозиции.

M>Не-не, все в рамках твоего определения.

да, в его рамках. А в чем проблемы?

M>Ок, удачная декомпозиция для разных задачь по одним и тем же данным будет разная. Как перейти от одной к другой минуя прямую работу с данными?


В чем конкретно будут заключаться различия этих декомпозиций?

M>Не надо, не уверяй..


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

Д>>Откуда такое ограничение?

M>Ответь на первый вопрос.

а где там вообще вопрос? Это там, где "спроси себя сам", что ли? Честное слово, у меня нет никакого желания играть в Нео и Морфеуса
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 11:23
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Я хозяен своего слова, я его дал, я и обратно забрал

Понятно.

S> Если тебе в розовых очках легче — майся дальше.

Золотые слова.

S>Ага, а ты даже проверял?

Зачем? Ты сам все рассказал.

S>У этого васи как раз и будет ИД по которому его можно будет завсегда найти без всяких там предикатов.

Как я узнаю что этот ID относится именно к этому васе?

S> Это даже в 90% реализаций БД для РБД так.

Что там было про розовые очки?

S> И изменяемая в РБД строка тоже будет в RAM загружена. Тут аналогия полная.

Я не понимаю почему ты все время пытаешься соскочить на реляционку и объяснить, что там точно так же, ты за свою систему ответь.

S> Не вижу я тут проблему. Надумал ты ее.

И еще раз, про розовые очки, определенно, очень удачная фраза...

S>Ну если с твоей точки зрения честная ООБД та,

С моей точки зрения честная ООБД — это та, которая поддерживает, как минимум, наследоване, инкапсуляцию и полиморфизм, в том виде, в котором ее поддерживают современные объектные ЯП.

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

Твоей избирательности при чтении чужих сообщений я уже удивлялся.

S>Может пост прозевал. Приведешь ссылку?

Легко: Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц
Автор: Merle
Дата: 20.04.06


S>Если догма приоритетней

Дело не в догме, а втом, что если уж упоминаешь в названии своей БД слово "объект" — будь любезен соответствовать.

S>Желательно но необязательно.


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

S> Вот без чего в ООП будет грусно — так без полиморфизма.

Но тем не менее он, по твоим словам, необязателен. Best! И подобную конструкцию, после всего этого ты продолжаеь называть ОО?
Вообщем больше чем на обычную сетевую БД твоя конструкция не тянет.

S>И что ты куришь чтоб к таким выводам приходить и так слова собеседников переврать?

Я правильно понимаю, что некто бесчестный, не найдя подходящих аргументов, обвиняет меня во вранье, чтобы уйти от темы?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 11:23
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>В чем здесь неразрешимая проблема то?

О неразрешимих проблемах никто не говорит.
Но, как минимум, проблемы в том, что часть данных нужная одной декомпозиции не доступна из другой. Иными словами, для того чтобы любая возможная "декомпозиция", получила доступ ко всем данным, основная "декомпозиция", в которую обернуты данные, должна давать доступ ко всем данным, а это уже не совсем ООП.
Далее, эта самая основная "декомпозиция" работает с данными ограниченным набором методов, и гарантии что это набор методов будет подходить оптимальным образом для всех "декомпозиций" уровнем выше — никто не даст. Следовательно, либо эта самая основная "декомпозиция" должна знать обо всех "декомпозициях" более высокого уровня, что есть нонсенс, либо придется городить дополнительную прослойку оберток и адаптеров.
Можно так работать? — можно. Удобно? — нет. Об этом и речь.

Д>В чем конкретно будут заключаться различия этих декомпозиций?

В том что им нужны разные данные.

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

Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

Д> А то меня что-то уже слегка мутит от общих слов.

Никто не неволит...

Д>а где там вообще вопрос?

Ну хватит дурака включать...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 11:23
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Сетевая модель, в отличии от иерархической (для иерархической ОМД все твои замечания действительно полностью адекватны) позволяет представлять один и тот же элемент данных одновременно в разных декомпозициях.

Как уже было замечено, речь здесь не о сетевой модели, а об ООП.

S> И кстати, и в отличии от РМД в которой все данные жестко прибиты к кортежам.

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

S>И в этом случае РМД + РБД отдыхают по сравнению с сетевыми ОМД/ОБД.

Про розовые очки там было очень метко сказано...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: IT Россия linq2db.com
Дата: 21.04.06 11:49
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?


Не в ООП, а сам(а,о) ООП.

IT>>Самодостаточная персистентная распределённая объектная модель мира — это утопия.


Д>А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично.


Думаешь? Давай возьмём в качестве примера интернет. Чем тебе не модель мира, вот где глобализму хоть отбавляй. И ведь работает, и не утопия, но основан не на ООП, хотя где-то местами ООП безусловно с успехом используется.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: IT Россия linq2db.com
Дата: 21.04.06 11:49
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>А кто сказал что в распределенной среде ООБД плохо живется?


А кто сказал что хорошо?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 21.04.06 12:03
Оценка:
Здравствуйте, Merle, Вы писали:

M>О неразрешимих проблемах никто не говорит.


значит, про закат ООП было сказано для красного словца?

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


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

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


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

M>Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.


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

Д>> А то меня что-то уже слегка мутит от общих слов.

M>Никто не неволит...

то есть конкретных примеров так и не будет?

M>Ну хватит дурака включать...


просто формулируй мысли по человечески
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 21.04.06 12:10
Оценка:
Здравствуйте, shuklin, Вы писали:

S>>>- инкапсуляция не рекомендуется к применению.

S>>>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта.

IT>>Это уже не OODB, а COODB, где C абревиатура от castrated. Это как раз то о чём говорит Иван, получается ни два, ни полтора. Кастрированная объектная модель и такая же неполноценная база данных.


S>И что же такого важного я не смогу провернуть в такой модели, что можно провернуть в вашей?


Ты же сам перечислил свои ограничения Ты не можешь в полной мере использовать инкапсуляцию, т.е. один из трёх китов ООП ты уже скаплелёчком чик и отрезал. А как же внутреннее состояние объекта. Жесткие требования к сериализации как я понимаю тоже из этой серии. То что будет сериализоваться будет лежать в базе просто как блоб, поиска по этим данных мы не получим.

Твои объекты это фактически примитивные DTO без инкапсуляции и внутреннего состояния.

S>Как раз наоборот. Это вы в своей "полной" модели не сможете сделать многого что я смогу сделать в своей "castrated"


У меня в моей модели нет никаких искусственных ограничений. Вообще никаких. Данные лежат отдельно и обрабатываются специально для этого годами затачиваемыми средствами. А объектная модель во всей своей красе и со всеми своими целыми не насильно отрубленными причиндалами отдельно.

S>Поэтому считаю ваши доводы неубедительной демагогией.


Вот уж чья бы корово мукала насчёт неубедительной демагогии, а втоя бы лучше за собой последила. Пока кроме эмоций от тебя никаких убедительных аргументов не последовало. А аргументы и доказательства состоятельности своей позиции надо приводить как раз тебе, т.к. сегодня по истечении более десяти лет все попытки сделать OODB так и остались попытками.

S>И на маппинг там время не тратится, и сети поддерживаются по полной, Ну ну.


Время на маппинг вполне сравнимо с сериализацией объектов из твоей ООБД.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 21.04.06 12:32
Оценка:
Здравствуйте, IT, Вы писали:

Д>>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?


IT>Не в ООП, а сам(а,о) ООП.


неважно. Хочу точные данные

Д>>А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично.


IT>Думаешь? Давай возьмём в качестве примера интернет. Чем тебе не модель мира, вот где глобализму хоть отбавляй. И ведь работает, и не утопия, но основан не на ООП, хотя где-то местами ООП безусловно с успехом используется.


ну во первых, если интернет — модель, то давай уточним кое-какие вопросы.
Какие аспекты мира он моделирует, какие — нет? Иными словами, насколько полна эта модель?
Каким задачам она служит?

Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 12:49
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>значит, про закат ООП было сказано для красного словца?

Откуда такой вывод?

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

Учись мыслить абстрактно..

Д> А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.

Никто не неволит.

Д>либо нужно подумать о том, что интерфейс объектов может меняться с изменением требований к системе. Свежая мысль, не правда ли?

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

Д>Спроектировать объектную модель классов, "шоб всегда само работало", все равно никогда не получится.

Именно, об этом и речь. Так зачем ее проектировать, если можно хранить сырые данные и накручивать поверх нужные объекты в случае необходимости?

Д>персистентность? вау, как интересно! а мужики то и не знают (С)

Не знаю, что там не знают мужики, а вот проблемы с сохранением объектов сложно не заметить. Добро пожаловать мужикам в реальный мир.

Д>распределенка? а здесь то вообще какие проблемы?

Ну ка — ну ка, как там мужики объекты и вызовы по сети гоняют? В лучшем случае DTO... Это называется — нет проблем?

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

То есть, когда ты говорил, что проблем нет — обманывал?

Д>Но всё тоже можно решить при наличии желания.

А кто говорил, что ничего решить нельзя? Просто есть более адекватные способы, чем пытаться сделать все через объекты.

Д>то есть конкретных примеров так и не будет?

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

Д>просто формулируй мысли по человечески

И так уж человечнее некуда.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 21.04.06 13:31
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>>>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?

IT>>Не в ООП, а сам(а,о) ООП.
Д>неважно. Хочу точные данные

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

Д>ну во первых, если интернет — модель, то давай уточним кое-какие вопросы.

Д>Какие аспекты мира он моделирует, какие — нет? Иными словами, насколько полна эта модель?
Д>Каким задачам она служит?

Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.

Д>Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде


Точно так же можно сказать, что основа ООП — это машинные коды. Впрочем, я с этим спорить не собираюсь. Как я уже сказал, ООП прекрасно себя чувствует на небольших модельках, где может и должен эффективно применяться. Но только не надо глобализму, и всё у нас получится
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
От: IT Россия linq2db.com
Дата: 21.04.06 13:39
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Мое IMHO что эпоха ООБД еще не начиналась.


Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 21.04.06 13:46
Оценка:
Здравствуйте, Merle, Вы писали:

M>Откуда такой вывод?


ну ты уж определись хотя бы. Или есть непреодолимые проблемы, и тогда ООП действительно ничего хорошего не светит, или их нет.

M>Учись мыслить абстрактно..


излагать неясно запутанные мысли != мыслить абстрактно
если ты не в состоянии сгенерировать простой и ясный пример, который иллюстрирует твои абстракции — значит, никаких абстракций у тебя просто нет
хинт — говорить "Х не работает, потому что я так сказал" за пример проблемы не засчитывается

Д>> А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.

M>Никто не неволит.

я еще не оставил надежду, что за твоими словами есть какой-то смысл

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


объект — это совокупность данных и методов, которые их обрабатывают в соответствии с требованиями. Если требования меняются, то меняются и методы. Тебя в этом что-то удивляет?

Д>>Спроектировать объектную модель классов, "шоб всегда само работало", все равно никогда не получится.

M>Именно, об этом и речь. Так зачем ее проектировать, если можно хранить сырые данные и накручивать поверх нужные объекты в случае необходимости?

сырые данные и так всегда есть. Внутри объектов. Зачем создавать дополнительное представление данных?

M>Не знаю, что там не знают мужики, а вот проблемы с сохранением объектов сложно не заметить. Добро пожаловать мужикам в реальный мир.


с каким конкретно сохранением? Сериализацией в файл? Маппингом объектов на РБД? Сохранением объектов в ОБД? Какую конкретно из них? Какие конкретно проблемы?

M>Ну ка — ну ка, как там мужики объекты и вызовы по сети гоняют? В лучшем случае DTO... Это называется — нет проблем?


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

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

M>То есть, когда ты говорил, что проблем нет — обманывал?

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

M>А кто говорил, что ничего решить нельзя? Просто есть более адекватные способы, чем пытаться сделать все через объекты.


какие? ORM, что ли?

Д>>то есть конкретных примеров так и не будет?

M>Да куда уж конкретнее, все же разжевал, а то что примеры тебя не устраивают, так я не виноват.

я пока еще ни одного не видел, поэтому судить пока не могу

Д>>просто формулируй мысли по человечески

M>И так уж человечнее некуда.

тогда мне даже страшно представить, что будет, если ты включишь генератор флейма
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 21.04.06 13:53
Оценка:
Здравствуйте, IT, Вы писали:

GZ>>А кто сказал что в распределенной среде ООБД плохо живется?

IT>А кто сказал что хорошо?
Можешь верить или не верить но именно отчеты и распределенки лучше всего уживаются в распределенной среде по сравнению с чистой реляционкой.
Для реляционки репорты являются проблемой из-за двухмерности. Не зря Кодд придумал OLAP. Вторая проблема в том, что очень сложно обрабатывать сложные случаи типа "если у нас такая сумма, то мы берем следующий коэффициент и по нему высчитываем сумму". Навигационный доступ с ручной обработкой в данном случае более удобен.
Что касается распределенной среды, то распределенность изначально закладывалась в OID. Когда есть OID у тебя нет дубликатов ключей при репликации как понятия. OID может адресовать не строку в базе, а объект находящийся вообще на другом компе. Во многом, подобная распределенность сделана в GemStone. В ней граф объектов может быть и локальным, и удаленным.(некоторые потуги Oracle по кэшированию локальных данных появились только сейчас).
Re[5]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 21.04.06 13:54
Оценка:
Здравствуйте, IT, Вы писали:

IT>Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.

Скорее немного не так. Когда машина начнет понимать что человек написал. А DLinq уже может интерпретировать и трансформировать такой код. Так что эпоха не начинается, а можно сказать наступила.
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 15:17
Оценка:
Здравствуйте, Merle, Вы писали:


S>>Может пост прозевал. Приведешь ссылку?

M>Легко: Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц
Автор: Merle
Дата: 20.04.06


Это я ужо читал. В натуре не убеждает. Ну ни на чуть чуть. Может вы и правы в чемто, но по этому посту я этого не вижу.
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 21.04.06 15:29
Оценка:
Здравствуйте, shuklin, Вы писали:

S>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)

Кхм. А что такое "волновой алгоритм пропагации"? Гугл на запросы типа "wave index/tree/map propagation" выдает левые ссылки.

Волновой алгоритм нахождения кратчайшего пути — я знаю. А вот как он относится к индексам?

S>4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД. Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.

Интересны базовые алгоритмы — они определяют скорость работы. У вас есть что-то новое, чего нет в существующих ОО/РБД?

S>5. Это у тебя с полиморфизмом какойто детский комплекс его якобы необходимости для ОБД во всех случаях? Когда нужен ОБД должна позволять его реализовать. Когда не нужен — должна позволить проиндексировать поле объекта в стиле РБД. Какие проблемы? Выбор у разработчика.

Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.

Наследование реализуется в виде join'ов, а инкапсюляция — с помощью прикладных средств работы с БД. Даже навигационный доступ нормально работает в ORM (см. http://www.hibernate.org ).Что у вас есть принципиально нового?

S>Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.

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

ЗЫ: кстати, а Reiser4 смотрели? Там у них построена FS поверх с поддержкой построения индексов по заданным пользователем критериям (фактически, туда добавить еще движок SQL и будет готовая база), причем FS вполне резво работает на миллионах файлов в одном каталоге. Вот тут я приводил простой benchmark: http://rsdn.ru/Forum/Message.aspx?mid=1710544&amp;only=1
Автор: Cyberax
Дата: 02.03.06
Sapienti sat!
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 16:12
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


S>>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)

C>Кхм. А что такое "волновой алгоритм пропагации"? Гугл на запросы типа "wave index/tree/map propagation" выдает левые ссылки.


От так я вам тут все свои ноу хау и выдал )) На данный момент из ноу хау реализована и опубликована новая версия идентификации экземпляров объектов, не совместимая с ODMG. Это я про синонимию и омонимию идентификаторов экземпляров объектов.


C>Интересны базовые алгоритмы — они определяют скорость работы. У вас есть что-то новое, чего нет в существующих ОО/РБД?


Ну вот идентификация другая. Дальше будет больше но не сразу. Не реализованные фичи я обсуждать не буду.


C>Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.


РБД это в первую очередь РМД. А вот моя ОБД лежит на сетевой МД. РБД она не может быть ну никак.

S>>Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.

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

В РБД есть понятие буукмарк. Это и есть скрыты ОИД. Не понятно кому и чем ОИД мешает, в ОБД если он не мешает в РБД,


C>ЗЫ: кстати, а Reiser4 смотрели? Там у них построена FS поверх с поддержкой построения индексов по заданным пользователем критериям (фактически, туда добавить еще движок SQL и будет готовая база), причем FS вполне резво работает на миллионах файлов в одном каталоге. Вот тут я приводил простой benchmark: http://rsdn.ru/Forum/Message.aspx?mid=1710544&amp;only=1
Автор: Cyberax
Дата: 02.03.06


Неа, на это дело не глядел. Будет время — обязательно погляжу.
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 17:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну так покажите результаты тестов. Какие проблемы?


Никаких. вот домашняя страница проекта. Там даже сырцы открыты: http://www.shuklin.com/ai/ht/ru/cerebrum

Скорость сканирования C# объектов в кэш — до 80000 шт/сек
Скорость инстанциирования C# — ок 1000 шт/сек.

Второй показатель поддается относительно простой оптимизации. Первый — оптимизировать дальше будет гоораздо сложнее.

C>Идентификации объектов в БД используются следующие:

C>1. Физический ID (ID объекта является физическим указателем на
C>расположение объекта в хранилище).
C>2. Логический ID, для преобразования в физическую позицию используется
C>какой-нибудь механизм типа каталога страниц.
C>Недостатки и преимущества обоих типов давно известны и хорошо описаны.

C>Что у вас нового?


один и тот же ИД указывает одновременно на несколько разных объектов.

C>Чистая сетевая модель не позволяет эффективно строить индексы, либо

C>требует фиксированные пути доступа к данным (что еще хуже).

У меня сетевая модель с прямым доступам к узлам по их ИД, Так что индексы строить можно. Хотя в текущей версии они не реализованны.

C>Если мы начинаем строить индексы — то опять сваливаемся в РБД.


В БД похожую во многом на РБД. Вот только с РМД она совместимой не будет, значит и не РБД.


C>Кстати, эмуляции сетевых моделей с помощью РБД делаются без проблем —

C>просто считаем главный ключ записи указателем объекта. Коллекции
C>1-ко-многим делаются с помощью обратных указателей, а многие-ко-многим
C>делаются с помощью вспомогательной таблицы.

Разве без проблем? А перформанс? А удобство? ...

C>Ассимптотика у алгоритмов получается другая, но зато мы можем делать

C>ad-hoc запросы.

В сетевой БД никакая теория этого тоже не запрещает. LINQ видели?

>> C>Отличительная особенность ООБД — навигационный доступ. Благодаря нему

>> можно легко обрабатывать сложносвязные данные, но как раз навигационный
>> доступ мешает построению индексов.
>> В РБД есть понятие буукмарк. Это и есть скрыты ОИД. Не понятно кому и
>> чем ОИД мешает, в ОБД если он не мешает в РБД,
C>OID — это далеко не главная вещь. Я бы даже сказал, что второстепенная.

Тогда не вижу сути вопроса. В РБД тоже есть скрытый навигационный доступ, и он нормально соседсвует с индексами, мало того этими же индексами и используется.

C>В РБД идентификатором объекта является главный ключ, и поиск по главному

C>ключу занимает O(log N) времени. При реальных объемах данных можно
C>считать, что он займет O(1) (амортизированое константное время).

Да. Но накладные расходы на инстанциирование в ОРМ больше чем у ОБД. А так все действительно ооочень близко и похоже.


C>Точка разлома — в представлении коллекций. В сетевых БД коллекции

C>хранятся непосредственно в объекте, то есть НЕ являются табличными данными.

Именно. В сетевой ОБД ваще все не является табличными данными. В этом тоже дополнительное отличие. И с моей точки зрения доп приемущество. А механизмы реализации — само собой теже. Теже индексы, страницы, транзакции, блокировки, версии ...



C>Возьмем классический пример: есть список школ, у каждой школы список

C>учеников. Нам надо найти все школы с номерами от 20 до 100 и выбрать
C>всех учеников с 5 по 8 классы.

C>В случае РБД мы делаем выборку из таблицы школ по диапазону номеров

C>(O(log N) времени) и join'им ее с результатами выборки из школ по классу
C>ученика (тоже O(log N) времени). В результате, имеем ассимптотику O(log
C>N) для поиска.


Мне вот что тут интересно, JOIN у вас в этом примере оказался O(1).
Имхо тут будет тот же O(logN) * O(logN). Если есть способ это обойти — буду благодарен за повышение квалификации.
Я тогда этот метод спианерю у РБД и применю у себя.

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

тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))
с другой стороны в каждой школе учатся вовсе не все ученики. тоесть у — это уже среднее число учеников в каждой школе — чтоб не заморачиваться.

поиск в ОБД O(logШ + logШ' * logу)


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

Давайте это разберем — в натуре интересно и полезно.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 17:24
Оценка:
Здравствуйте, Max.Subpixel, Вы писали:


MS>Я могу лишь сказать, что то что вы не можете реализовать без проблем инкапсуляцию это потому, что вы плохо подумали, а не потому что это невозможно. И не надо говорить про логику — это слишком громкое заявление. Поэтому решение ваше половинчато. А говорить что инкапсуляция не нужна это вообще критическая ошибка. Инкапсуляция позволяет говорить об объектах. Если ее нет — это не объекты. Более того смысл инкапсуляции очевиден и доказан. Вы же с этим спорите и говорите, что тут что-то не то с концепцией...


Любят у нас слова переверать. В C# инкапсуляция есть? ЕЕ вам как инкапсуляции хватает?
Моя БД паразитирует на .NET и его возможностях. Можете вы и в среде моей БД пользуясь VS 2003 использовать любимую вами инкапсуляцию Что вам в ней не хватает



MS>Это тоже не объект. Пока вы продолжаете называть ваши необъектные данные объектами вы продолжаете натыкаться на теже самые вопросы и комментарии.


C# экземпляр это что?
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 17:33
Оценка:
Здравствуйте, shuklin, Вы писали:

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


C>>Ну так покажите результаты тестов. Какие проблемы?


S>Никаких. вот домашняя страница проекта. Там даже сырцы открыты: http://www.shuklin.com/ai/ht/ru/cerebrum


S>Скорость сканирования C# объектов в кэш — до 80000 шт/сек

S>Скорость инстанциирования C# — ок 1000 шт/сек.

Это смешной тест. Особенно эти "до" и "ок". Я могу за 2 часа написать систему со скоростью сканирования и инстантиирования существенно выше и это ничего не докажет. С каких пор это стало показателем производительности БД? Каким образом проводился тест? 80000 штук в секунду прочитанных объектов. Это что — все разом прочитали и вперед? На большой базе при рандомном чтении предел 100 чтений в секунду. По определению. Потому что время доступа к участку на жестком диске около 10мсек. А вы что там меряли, скорость кэша или скорость линейного чтения объектов типа Object?

А вообще хочу сказать, что ведете вы себя невежливо — сначала вы спрашиваете мнения других, а потом начинаете "тыкать" всем подряд и говорить, что вам плевать на их мнение. Я бы мог с вами обсуждать эту тему, поскольку тоже ей занимаюсь, но вы ведете себя настолько "высокомерно", что ничего конструктивного обсуждать желания нет...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 17:35
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Любят у нас слова переверать. В C# инкапсуляция есть? ЕЕ вам как инкапсуляции хватает?


Вы меня в переверании обвиняете?
Мне хватает инкапсуляции.

S>Моя БД паразитирует на .NET и его возможностях. Можете вы и в среде моей БД пользуясь VS 2003 использовать любимую вами инкапсуляцию Что вам в ней не хватает


Ваша БД не поддерживает механизмы инкапсуляции без проблем. Проблемы вы обозначили. Решить их не смогли и списали на .NET.

MS>>Это тоже не объект. Пока вы продолжаете называть ваши необъектные данные объектами вы продолжаете натыкаться на теже самые вопросы и комментарии.


S>C# экземпляр это что?


Хороший вопрос. И ответ ничего не скажет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 17:38
Оценка:
Здравствуйте, Max.Subpixel, Вы писали:

C>>>Ну так покажите результаты тестов. Какие проблемы?


S>>Никаких. вот домашняя страница проекта. Там даже сырцы открыты: http://www.shuklin.com/ai/ht/ru/cerebrum


S>>Скорость сканирования C# объектов в кэш — до 80000 шт/сек

S>>Скорость инстанциирования C# — ок 1000 шт/сек.

MS>Это смешной тест. Особенно эти "до" и "ок". Я могу за 2 часа написать систему со скоростью сканирования и инстантиирования существенно выше и это ничего не докажет. С каких пор это стало показателем производительности БД? Каким образом проводился тест? 80000 штук в секунду прочитанных объектов. Это что — все разом прочитали и вперед? На большой базе при рандомном чтении предел 100 чтений в секунду. По определению. Потому что время доступа к участку на жестком диске около 10мсек. А вы что там меряли, скорость кэша или скорость линейного чтения объектов типа Object?


sequential insert, 200000 instances, AMD 1.7 1400 items/sec, DB file 16M
repeatable sequential scan 200000 instances, 20000000 scans — 80000 items/sec
in both tests transactions are disabled.

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


Жаль.
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 17:42
Оценка:
Здравствуйте, Max.Subpixel, Вы писали:


MS>Ваша БД не поддерживает механизмы инкапсуляции без проблем. Проблемы вы обозначили. Решить их не смогли и списали на .NET.


ИМХО поддерживает в объеме достаточном для эксплуатации. А проблемы — где их нет. Про технические и идеологические проблемы своей БД я знаю. Много их там. Не было бы — не педалил бы следующую версию
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 17:42
Оценка:
Здравствуйте, shuklin, Вы писали:

S>sequential insert, 200000 instances, AMD 1.7 1400 items/sec, DB file 16M

S>repeatable sequential scan 200000 instances, 20000000 scans — 80000 items/sec
S>in both tests transactions are disabled.

Ну вот о чем я и говорил — ничего особенного — все sequential и не ACID.
Такие тесты совершенно неинтересны.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 17:45
Оценка:
Здравствуйте, Max.Subpixel, Вы писали:


MS>Ну вот о чем я и говорил — ничего особенного — все sequential и не ACID.

MS>Такие тесты совершенно неинтересны.

Тогда б конкретезировали, что интересно лично вам. А так на общий вопрос и ответ общий.
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 17:49
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Тогда б конкретезировали, что интересно лично вам. А так на общий вопрос и ответ общий.


Ну возьмите тесты www.polepos.org и проведите. Вот и посмотрим результаты хотя бы на мелких данных.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 17:54
Оценка:
Здравствуйте, Max.Subpixel, Вы писали:


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


Ващето есть идеи на этот счет. Но если вы ходили по указанной ссылке, и читали описание — там понаписано в ограничениях горааздо более серьезных вещей чем инкапсуляция. Например, текущая опубликованная версия — однопользовательская desktop ((((

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

А вот с приват полями и с индексами работать имхо смысла нет. Допустим есть у нас экземпляр объекта в котором только методы — он просто мост к данным из десятка других объектов. У него вообще полей нет. А все проперти хоть и публичные, но вычисляемые. Какой тут индекс приват полей? Не пахнет тут им. А индексить надо. И учитывать изменения прецедентов тоже надо. Собираюсь сделать, но это даже не второй приоритет работы. У меня интерес к этой БД шкурный. Делаю в первую очередь то , что нужно мне лично для тех приложений, для который я ее ваяю. Остальные увы ждут в очереди. Вот если бы на комерческую основу разработку перевести — тогда совсем дело другое. Но это тогда дело сооовсем другое.
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 17:57
Оценка:
Здравствуйте, Max.Subpixel, Вы писали:


MS>Ну возьмите тесты www.polepos.org и проведите. Вот и посмотрим результаты хотя бы на мелких данных.


За линк спасибо! Только он уже стоил всего этого бедлама. В ближайшем времени результатов не обещаю. Сами понимаете почему.
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 18:00
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Здравствуйте, Max.Subpixel, Вы писали:



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


S>Ващето есть идеи на этот счет. Но если вы ходили по указанной ссылке, и читали описание — там понаписано в ограничениях горааздо более серьезных вещей чем инкапсуляция. Например, текущая опубликованная версия — однопользовательская desktop ((((


Да, я видел. Это как-раз пол беды. А вот ошибочная концепция — это увы.

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


Ну без индексов вы вообще не уедете никуда. Хранилище без поиска вообще не нужно.

S>А вот с приват полями и с индексами работать имхо смысла нет. Допустим есть у нас экземпляр объекта в котором только методы — он просто мост к данным из десятка других объектов. У него вообще полей нет. А все проперти хоть и публичные, но вычисляемые.


Ну и что? В других-то объектах есть поля — вот по ним и индексы...

S> Какой тут индекс приват полей? Не пахнет тут им. А индексить надо. И учитывать изменения прецедентов тоже надо.


Учитывать надо изменения полей.

S>Собираюсь сделать, но это даже не второй приоритет работы. У меня интерес к этой БД шкурный. Делаю в первую очередь то , что нужно мне лично для тех приложений, для который я ее ваяю. Остальные увы ждут в очереди. Вот если бы на комерческую основу разработку перевести — тогда совсем дело другое. Но это тогда дело сооовсем другое.


Ну и правильно. Делайте для себя и не тратьте время на чужое время — все равно все для себя. Другим оно вряд-ли пригодится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 21.04.06 18:02
Оценка:
Здравствуйте, Max.Subpixel, Вы писали:

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



MS>Ну без индексов вы вообще не уедете никуда. Хранилище без поиска вообще не нужно.

MS>Ну и что? В других-то объектах есть поля — вот по ним и индексы...
MS>Учитывать надо изменения полей.

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

MS>Ну и правильно. Делайте для себя и не тратьте время на чужое время — все равно все для себя. Другим оно вряд-ли пригодится.


Уже есть прециденты обратного.
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 21.04.06 18:02
Оценка:
Здравствуйте, shuklin, Вы писали:

S>За линк спасибо! Только он уже стоил всего этого бедлама. В ближайшем времени результатов не обещаю. Сами понимаете почему.


Пожалуйста. И сравните потом навскидку с db4o или Perst. Правда без индексов там ничего не светит даже на старте...
Кстати Perst тоже 1 человеком делается в свободное время (а по производительности бьет всех подряд с головой), так что тоже не показатель, что вы 1...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 21.04.06 18:46
Оценка:
Здравствуйте, IT, Вы писали:

IT>Точные данные чего? Того что ООП не работает в распределённых системах и в ООБД? Ты понимаешь в чём дело, если нет таких данных, то они никак не могут быть точными. Есть данных, что где-то кто-то когда-то от кого-то слышал или даже видел глазами расказчика про то, что ООП вдруг успешно применился в суперраспределённой среде и ООБД. По таким слухам сложно собрать точные данные, так что извини

Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).

IT>Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.

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

Д>>Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде

По моему вы все тут начали путать программирование на ООП, и модель данных ООБД. Это разные вещи в которых совершенно разные проблемы и разные подходы. Это все равно что сравнить утюг и рубашку которую ты гладишь.
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 19:09
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>для начала давай уточним, какие из современных ЯП?

На смолтолк не претендую, достаточно шарпа.

Д>к тому же наследование — далеко не обязательный пункт

Не обязательный для чего?

Д>фактически, для соответствия ООП требуется всего два пункта — инкапсуляция и полиморфизм (полиморфизм != virtual method).

И? Суть-то в том, что у него инкапсуляции нет полиморфизм тоже странный, а все туда же — "объекты", медом на них намазано что ли?
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 19:09
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>ну ты уж определись хотя бы.

С чем? Свою точку зрения я изложил, что-то непонятно?

Д> Или есть непреодолимые проблемы, и тогда ООП действительно ничего хорошего не светит, или их нет.

Где я хоть слово говорил про непреодолимые проблемы? Помоему я достаточно четко пояснил что я имел ввиду, читай до просветления.

Д>излагать неясно запутанные мысли != мыслить абстрактно

Это да. Расскажи, заодно, как можно "неясно запутать мысли"...

Д>если ты не в состоянии сгенерировать простой и ясный пример

Я уже нагенерировал достаточно простых и ясных примеров, если они небя не устраивают, то я не виноват...

Д>я еще не оставил надежду, что за твоими словами есть какой-то смысл

Успехов...

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

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

Д>сырые данные и так всегда есть. Внутри объектов.

Только доступа к ним нет, а мне доступ нужен, чтобы новые объекты создать.

Д> Зачем создавать дополнительное представление данных?

Во-во. Объекты это как раз и есть представление данных, о чем я собственно и писал, так зачем оно нужно?

Д>с каким конкретно сохранением?

С любым.

Д> Сериализацией в файл?

Да.

Д> Маппингом объектов на РБД?

Да.

Д> Сохранением объектов в ОБД?

Да.

Д> Какие конкретно проблемы?

Везде разные.

Д>Где ты здесь видишь проблему?

В необходимости паковать, создавать промежуточный объект для пересылки, сериализовывать/десериализовывать, ect..

Д>проблемы есть

Я сказал, что у ОО есть проблемы, ты сначала начал возражать, но потом все таки признал. Вот давай на этом и завершим.

Д> Мы здесь обсуждаем перспективу, не так ли?

Мы здесь, вот конкретно здесь, обсуждаем область применимости ОО.

Д>какие? ORM, что ли?

Кто сказал ORM? Как раз наоборот, отказаться от всяких ORM и прочих объектов и работать с плоскими данными.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 19:09
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Это я ужо читал.

Прочитай еще раз, до просветления.

S> В натуре не убеждает. Ну ни на чуть чуть.

Надеяться тебя убедить было бы слишком самонадеяно с моей стороны, но, надеюсь, хотя бы пищю для размышлений я подкинул.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 21.04.06 19:16
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).

Подсказываю, это база написанная под конкретную задачу.

GZ>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.

Кто говорит о распределенности БД? В данном случае речь шла о пригодности ОО к распередленке...

GZ>По моему вы все тут начали путать программирование на ООП, и модель данных ООБД.

Никто ничего путать не начал, просто в данной подветке тема немного поменялась...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 21.04.06 20:23
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>>>А кто сказал что в распределенной среде ООБД плохо живется?

IT>>А кто сказал что хорошо?
GZ>Можешь верить или не верить но именно отчеты и распределенки лучше всего уживаются в распределенной среде по сравнению с чистой реляционкой.

И какое это имеет отношение к ООБД?
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 21.04.06 20:28
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).


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

GZ>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.


И при чём тут ООБД? Или у неё здесь есть хоть малейший шанс вырваться вперёд?
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.04.06 22:13
Оценка:
Здравствуйте, shuklin, Вы писали:

Цитируй только то что нужно для понимания твоего ответа.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 22.04.06 06:34
Оценка:
Здравствуйте, IT, Вы писали:

IT>Точные данные чего? Того что ООП не работает в распределённых системах и в ООБД? Ты понимаешь в чём дело, если нет таких данных, то они никак не могут быть точными. Есть данных, что где-то кто-то когда-то от кого-то слышал или даже видел глазами расказчика про то, что ООП вдруг успешно применился в суперраспределённой среде и ООБД. По таким слухам сложно собрать точные данные, так что извини


существует и давно применяется CORBA. Существует и применяется .NET Remoting, существуют и применяются ООБД.
Так что, значит не работают в принципе? Или ты имел в виду какие-то конкретные проблемы, которые не дают жить и которые принципиально нельзя решить из-за врожденных пороков ООП?

IT>Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.


осталось только доказать, что построить аналог с применением ООП нельзя в принципе. Потому что инкапсуляция не дает объектам жить в распределенной среде. Или из-за полиморфизма пакеты застревают в проводах
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 22.04.06 07:03
Оценка:
Здравствуйте, Merle, Вы писали:

M>На смолтолк не претендую, достаточно шарпа.


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

M>Не обязательный для чего?


необязательный для того, что считать реализацию системы ОО

M>И? Суть-то в том, что у него инкапсуляции нет полиморфизм тоже странный,


прямо-таки совсем нет? Это конечно минус.

M>а все туда же — "объекты", медом на них намазано что ли?


а какие есть варианты лучше?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 22.04.06 07:03
Оценка:
Здравствуйте, Merle, Вы писали:

Д>>ну ты уж определись хотя бы.

M>С чем? Свою точку зрения я изложил, что-то непонятно?

для тех, кто в танке, повторю и дополню тезис

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

Д>>излагать неясно запутанные мысли != мыслить абстрактно

M>Это да. Расскажи, заодно, как можно "неясно запутать мысли"...

"неясно" — это наречие, которое относится к глаголу. (С) Учебник русского языка, не помню какой класс.

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


Руки перед едой надо мыть. Зубы надо чистить каждый день. Доступ к данным нужно инкапсулировать.
Сокрытие информации — один из фундаментальных принципов построения сложных систем.

M>Только доступа к ним нет, а мне доступ нужен, чтобы новые объекты создать.


какие новые объекты? Зачем тебе для них нужны именно сырые даные?

Д>>Где ты здесь видишь проблему?

M>В необходимости паковать, создавать промежуточный объект для пересылки, сериализовывать/десериализовывать, ect..

и что, это и есть та самая проблема, которая убьет ООП?

Д>>проблемы есть

M>Я сказал, что у ОО есть проблемы, ты сначала начал возражать, но потом все таки признал. Вот давай на этом и завершим.

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

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


no comments. Еще один романтик каменного века...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: ie Россия http://ziez.blogspot.com/
Дата: 22.04.06 07:28
Оценка:
Здравствуйте, shuklin, Вы писали:

C большим интересом читаю вашу дискуссию, сам учавствовать не планировал, но...

M>>Вот скажи мне, так ли нужно наследование в ООП?

S>Желательно но необязательно. Я поддерживаю.

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

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


Но как это все криво! Уж не кривизне ли нам стоит стремиться?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 22.04.06 13:48
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>существует и давно применяется CORBA. Существует и применяется .NET Remoting,


Ты путаешь, это всё не распределённый ООП. В данном случае его можно было бы назвать удалённый, но не распределённый. Распределённый — это когда состояние твоей объектной модели размазано по нескольким компьютерам и любой объект или его часть может одновременно находится в нескольких местах.

А то что ты перечислил конечно же подразумевает ООП. Мы либо клонируем объекты, либо создаём по запросу новые, либо запрашиваем часть их состояния. Сами объекты при этом не являются распределёнными. Впрочем, иногда можно добится иллюзии распределённости.

Д>существуют и применяются ООБД.


Применяются в основном в разговорах, либо очень частных решениях. О серьёзном серийном промышленном применении я пока не слышал.

Д>Так что, значит не работают в принципе? Или ты имел в виду какие-то конкретные проблемы, которые не дают жить и которые принципиально нельзя решить из-за врожденных пороков ООП?


Ваня тебе уже всё рассказал про врождённые пороки ООП в ООБД, хочешь чтобы я его процитировал?

Д>осталось только доказать, что построить аналог с применением ООП нельзя в принципе.


Вот опять. Не с применением, а полностью на базе и идеологии ООП. Или всё ещё не улавливаешь разницу?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 22.04.06 15:02
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ты путаешь, это всё не распределённый ООП. В данном случае его можно было бы назвать удалённый, но не распределённый. Распределённый — это когда состояние твоей объектной модели размазано по нескольким компьютерам и любой объект или его часть может одновременно находится в нескольких местах.


IT>А то что ты перечислил конечно же подразумевает ООП. Мы либо клонируем объекты, либо создаём по запросу новые, либо запрашиваем часть их состояния. Сами объекты при этом не являются распределёнными. Впрочем, иногда можно добится иллюзии распределённости.


А чем отличается "реальная распределенность" от "иллюзии распределенности"? Ты можешь привести какой-нибудь реальный пример?

Д>>Так что, значит не работают в принципе? Или ты имел в виду какие-то конкретные проблемы, которые не дают жить и которые принципиально нельзя решить из-за врожденных пороков ООП?


IT>Ваня тебе уже всё рассказал про врождённые пороки ООП в ООБД, хочешь чтобы я его процитировал?


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

Д>>осталось только доказать, что построить аналог с применением ООП нельзя в принципе.


IT>Вот опять. Не с применением, а полностью на базе и идеологии ООП. Или всё ещё не улавливаешь разницу?


Хорошо. Полностью на базе и идеологии ООП. Какие принципиальные проблемы, которые можно избежать при отказе от ООП, ты видишь в данной задаче?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 22.04.06 18:59
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>ну тогда тебе неплохо бы задуматься над тем, что шарп — далеко не предел развития ООП даже на данный момент,

Да? Это тебе не плохо бы задуматься над тем, что данная подветка дискусии не посвящена недостаткам ООП или какой-то ее реализации. И я ни где не говорил, что шарп предел совершенства, я лишь говорил, что его реаизации ОО достаточно чтобы считаться ОО.

Д> и его недостатки — это недостатки одной конкретной реализации, а не недостатки ООП в принципе

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

Д>необязательный для того, что считать реализацию системы ОО

Кому как..

Д>а какие есть варианты лучше?

Зависит от задачи.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 22.04.06 18:59
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>для тех, кто в танке, повторю и дополню тезис

Тем кто в танке, пора бы прекратить навязывать мне слова, которых я не говорил. И вообще внимательнее читать сообщения.

Д>Или есть непреодолимые врожденные проблемы в ООП, и тогда ООП действительно ничего хорошего не светит.

Цитату, пожалуйста, где я говорил, что ООП ничего хорошего не светит.

Д>Если есть — приведи список таких проблем и объясни, почему жить с ними нельзя и способов решить их нет.

Эй, в танке, ау! Хватит врать. Я нигде не говорил, что есть "непреодолимые" проблемы — это ты о них все время почему-то твердишь.

Д>В ответ я пока только услышал, что ООП не работает в распределенных системах

Цитату, пожалуйста, где я такое говорил.

Д>"неясно" — это наречие, которое относится к глаголу. (С) Учебник русского языка, не помню какой класс.

Не увиливай, я не просил объяснить что такое "неясно", я просил подробно рассказать, как можо осуществить описанное тобой действие.

Д>Сокрытие информации — один из фундаментальных принципов построения сложных систем.

Ага, правильно. Сами себе создадим трудности, а потом с успехом будем их преодолевать.

Д>какие новые объекты?

Которые нужны для выполнения новых требований к системе.

Д> Зачем тебе для них нужны именно сырые даные?

Затем, через уже существующие объекты доступа к этим данным нет.

Д>и что, это и есть та самая проблема, которая убьет ООП?

Цитату, где я говорил, что убъет.

Д>Проблемы есть не у ОО как такового. Проблемы есть у некоторых распространенных существующих реализаций.

Ok, укажи мне реализацию, где этих проблем нет. В противном случае, раз не смогли сделать подходящую реализацию, значит проблема все таки у ОО.

Д>no comments. Еще один романтик каменного века...

Угу, мышы плакали, кололись, но продолжали жрать объектный кактус. Вам посолить?
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 22.04.06 18:59
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>всё, что он рассказал — это "ООП не работает".

Процитируй меня, пожалуйста или прекращай перевирать.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 23.04.06 06:10
Оценка:
Здравствуйте, Merle, Вы писали:

M>Да? Это тебе не плохо бы задуматься над тем, что данная подветка дискусии не посвящена недостаткам ООП или какой-то ее реализации.


зато наща беседа с тобой посвящена именно этой теме

Д>> и его недостатки — это недостатки одной конкретной реализации, а не недостатки ООП в принципе

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

нет никакой канонической реализации ООП, на соответствие которой язык можно проверить. Можно сказать, что язык Х реализует ООП. Нельзя сказать, что ООП — это есть реализация ООП в языке Х.

Д>>а какие есть варианты лучше?

M>Зависит от задачи.

опиши хотя бы один.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 23.04.06 06:10
Оценка:
Здравствуйте, Merle, Вы писали:

M>Тем кто в танке, пора бы прекратить навязывать мне слова, которых я не говорил. И вообще внимательнее читать сообщения.


M>Цитату, пожалуйста, где я говорил, что ООП ничего хорошего не светит.


M>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату


Д>>Если есть — приведи список таких проблем и объясни, почему жить с ними нельзя и способов решить их нет.

M>Эй, в танке, ау! Хватит врать. Я нигде не говорил, что есть "непреодолимые" проблемы — это ты о них все время почему-то твердишь.

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

Д>В ответ я пока только услышал, что ООП не работает в распределенных системах

M>Цитату, пожалуйста, где я такое говорил.

Д>если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты.
Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.



Д>>"неясно" — это наречие, которое относится к глаголу. (С) Учебник русского языка, не помню какой класс.

M>Не увиливай, я не просил объяснить что такое "неясно", я просил подробно рассказать, как можо осуществить описанное тобой действие.

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

Д>>Сокрытие информации — один из фундаментальных принципов построения сложных систем.

M>Ага, правильно. Сами себе создадим трудности, а потом с успехом будем их преодолевать.

то есть для тебя даже фундаментальные принципы построения ПО незнакомы. Ясно, учтем.

M>Которые нужны для выполнения новых требований к системе.


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

Д>> Зачем тебе для них нужны именно сырые даные?

M>Затем, через уже существующие объекты доступа к этим данным нет.

значит, нужно всего лишь изменить контракт старых объектов.

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


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

Д>>no comments. Еще один романтик каменного века...

M>Угу, мышы плакали, кололись, но продолжали жрать объектный кактус. Вам посолить?

Мыши плакали, кололись и думали, как бы вывести породу кактусов получше, потому что больше в этой пустыне жрать нечего.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 23.04.06 06:10
Оценка:
Здравствуйте, Merle, Вы писали:

M>Процитируй меня, пожалуйста или прекращай перевирать.


уже процитировал. Читай в другой ветке.
Если ты сам пишешь так, что тебя нельзя понять недвусмыслено — это уже не моя вина.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 23.04.06 06:10
Оценка:
Здравствуйте, IT, Вы писали:

IT>Реальной распределённости при сегодняшнем уровне технологий добится очень сложно и то только за счёт гарантированных тормозов. Нужно транзакционно обновлять распределённое состояние объекта, т.е. делать что-то типа распределённого lock. Если эти требования снижать, то можно получить иллюзию распределённости. Например, мы можем принять такое допущение, что объект может изменяться только одним писателем, при этом доступ к объекту на время обновления его распределённого состояния разрешен, а возможными коллизиями мы можем пренебречь.


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

IT>Ты можешь привести какой-нибудь реальный пример таких других реализаций?


Смоллток. Схема. Руби.
Некоторые концепции ООП до сих пор еще не реализованы толком ни в одном языке.
этого достаточно?

IT>Синхронизация состояния.


а при отсутствии объектов, значит, всё синхронизируется само собой?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 07:31
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>зато наща беседа с тобой посвящена именно этой теме

Наша с тобой беседа посвящена этой теме в совершенно другой подветке, не надо здесь тему менять.

Д>нет никакой канонической реализации ООП, на соответствие которой язык можно проверить.

При чем здесь каноническая реализация?

Д> Можно сказать, что язык Х реализует ООП.

Именно это я и говорю.

Д>опиши хотя бы один.

Реляционка в хранилищах.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 07:31
Оценка:
Здравствуйте, Дарней, Вы писали:

M>>Цитату, пожалуйста, где я говорил, что ООП ничего хорошего не светит.

Д>

M>>Не смотря на то что ООП, как таковое, уже пережило бурный рост и движется к закату

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

Д>Ну во первых, хватит обвинять меня во вранье.

Тогда прекращай врать.

Д> Я всего лишь пытаюсь выделить смысл в твоих словесных заграждениях.

Это невозможно сделать не читая моих сообщений.

Д>Во вторых, см пуктом выше. Как вот это твое высказывание следует понимать?

Я уже пояснил, с десяток сообщений назад, потрудись перечитать. Внимательно.

Д>Как следует понимать высказывание, что "ООП не работает в распределенных системах"?

Где я такое говорил? Мне что в каждом сообщении самого-себя цитировать? Если ты не прекратишь перевирать, то мы далеко не уедем.

Д>>В ответ я пока только услышал, что ООП не работает в распределенных системах

M>>Цитату, пожалуйста, где я такое говорил.
Д>

Д>>если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты.
Д>Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

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

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

Д>если до тебя всё еще не дошло, то мое высказывание эквивалентно следующему:

Д>"неясно излагать запутанные мысли"
И кто из нас после этого "неясно излагает запутанные мысли"?

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

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

Д>приведи детально описанный пример таких изменений.

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

Д>значит, нужно всего лишь изменить контракт старых объектов.

То есть вместо того, чтобы просто написать новый объект, мы будем менять старый с риском порушить все что есть.
Как у нас там насчет "фундаментальных принципов построения ПО"?

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

Может мыши просто подсели на кактус и не замечают ничего вокруг? Может им все-таки стоит перестать ограничивать свой рацион одним кактусом, тогда и иголки окажутся помягче...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 07:31
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>уже процитировал. Читай в другой ветке.

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

Д>Если ты сам пишешь так, что тебя нельзя понять недвусмыслено — это уже не моя вина.

Признаюсь, мне сложно написать недвусмыслено для человека, который не видит разницу между "не работает" и "плохо подходит", но сдается мне, это не моя вина.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 23.04.06 08:51
Оценка:
Здравствуйте, Merle, Вы писали:

M>Более того, в ответ на твою просьбу в следующем постинге, я четко объяснил что имел ввиду под этими словами, но ты почему-то предпоче это проигнорировать и упорно прицепился к тому, что я якобы пророчу крах ООП, хотя ничего подобного я не говорил. Так что сворачивай демагогию.


покажи пальцем, где и что ты объяснил. Ссылку на сообщение и указание точных слов в нем — в студию!

Д>>Ну во первых, хватит обвинять меня во вранье.

M>Тогда прекращай врать.

Давай обойдемся без личных нападок? Или ты без этого жить не можешь?

Д>>>В ответ я пока только услышал, что ООП не работает в распределенных системах

M>>>Цитату, пожалуйста, где я такое говорил.
Д>>

Д>>>если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты.
Д>>Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.


M>Ау, с приземленной логикой у нас как? В твоих логических построениях есть разница между "никак не работает" и "плохо работает"?


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

Если ты решил ответить на вопрос, который я тебе не задавал — это твоя проблема.
А то мне это анекдот один напоминает.

А это правда, что Иванов выиграл "Волгу" в лотерею?
Правда. Только не Иванов, а Петров, и не в лотерею, а в карты, и не "Волгу", а бутылку, и не выиграл, а проиграл.

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

M>То есть, ни одной фразы, котрую я якобы говорил, ты найти не смог. Заканчивай демагогию...


в таком случае, постарайся сделать неимоверное усилие воли и сформулировать свои мысли четко.
Ты сказал, что "ООП движется к закату". Насколько можно понять, это должно обозначать, что применение ООП со временем будет уменьшаться и, вероятно, постепенно сведется к нулю. Я правильно угадал?
Варианты ответа: да, нет, не знаю, иное. Если последнее, то расшифровать подробно.

M>И кто из нас после этого "неясно излагает запутанные мысли"?


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

M>Никаких придирок, просто хотелось понять, что ты имееешь ввиду. Однако раз ты углядел здесь придирку к построению фразы, то очевидно даже для тебя понятно, что твоя логика несколько.. запутана.


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

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


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

M>То есть вместо того, чтобы просто написать новый объект, мы будем менять старый с риском порушить все что есть.

M>Как у нас там насчет "фундаментальных принципов построения ПО"?

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

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


ну так ты предлагай варианты, я слушаю. Вариант "забить на инкапсуляцию и кодить все напрямую" мы уже рассмотрели. Может быть, у тебя есть еще мысли?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 23.04.06 08:51
Оценка:
Здравствуйте, Merle, Вы писали:

Д>>нет никакой канонической реализации ООП, на соответствие которой язык можно проверить.

M>При чем здесь каноническая реализация?

Д>> Можно сказать, что язык Х реализует ООП.

M>Именно это я и говорю.

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

Д>>опиши хотя бы один.

M>Реляционка в хранилищах.

хорошо. А теперь объясни, какие принципиальные проблемы создает применение принципов ООП к этой задаче.
Не нужно отсылать меня к своим предыдущим сообщениям — там все равно нет никакой конкретной информации. Я кстати так и не дождался ответа на вопрос, почему расширение интерфейса объекта — это зло.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 23.04.06 08:51
Оценка:
Здравствуйте, Merle, Вы писали:

это всё не имеет смысла. Читай в той ветке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 10:17
Оценка:
Здравствуйте, Merle, Вы писали:

GZ>>Игорь, угадай на чем построена самая большая в мире база данных(подсказываю, это не РСУБД).

M>Подсказываю, это база написанная под конкретную задачу.
Нет. Objectivity/DB — коммерческая БД.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 23.04.06 10:30
Оценка:
GlebZ wrote:
> GZ>>Игорь, угадай на чем построена самая большая в мире база
> данных(подсказываю, это не РСУБД).
> M>Подсказываю, это база написанная под конкретную задачу.
> Нет. Objectivity/DB — коммерческая БД.
В отчете написано, что им пришлось написать около миллиона строк на С++
для адаптации Objectivity к своей задаче. Так что она у них
коммерческая, но сильно подкрученая
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 11:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:

>> GZ>>Игорь, угадай на чем построена самая большая в мире база
>> данных(подсказываю, это не РСУБД).
>> M>Подсказываю, это база написанная под конкретную задачу.
>> Нет. Objectivity/DB — коммерческая БД.
C>В отчете написано, что им пришлось написать около миллиона строк на С++
C>для адаптации Objectivity к своей задаче. Так что она у них
C>коммерческая, но сильно подкрученая
Вообще-то 5 миллионов. Но у них это реализация задачи
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 23.04.06 11:34
Оценка:
GlebZ wrote:
> C>В отчете написано, что им пришлось написать около миллиона строк на С++
> C>для адаптации Objectivity к своей задаче. Так что она у них
> C>коммерческая, но сильно подкрученая
> Вообще-то 5 миллионов. Но у них это реализация задачи
Там где-то в начале было написано, что для обхода ограничений
Objectivity и подгонку под задачу потратили миллион строк кода.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 12:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:

>> C>В отчете написано, что им пришлось написать около миллиона строк на С++
>> C>для адаптации Objectivity к своей задаче. Так что она у них
>> C>коммерческая, но сильно подкрученая
>> Вообще-то 5 миллионов. Но у них это реализация задачи
C>Там где-то в начале было написано, что для обхода ограничений
C>Objectivity и подгонку под задачу потратили миллион строк кода.
Ты об этом?

The commercial ODBMS provided a powerful database
engine including catalog, schema management, data
consistency and recovery, but it was not deployable into a
system of BaBar’s scale without extra effort. Half a
million lines of complex C++ code were required to
customize it and to implement needed features that did not
come with the product.

... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 12:38
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Что вполне логично — основная объектная база используется для хранения

C>больших объемов сложносвязанных массивных данных. В основных данных не
C>надо делать поиск по многим таблицам со сложными объединениями, пути
C>доступа к данным относительно фиксированы и нужны сложные
C>числодробитильные вычисления на клиентах. В общем, идеальные условия для
C>ООБД.
Ты не то посмотрел. Там есть конкретный абзац почему была выбрана Objectivity

An object oriented approach seems to be the most
natural way to model HEP data, where complex many-tomany
relationships are commonplace. As explained
above, the persistency system has to also provide multipetabyte
scalability. None of the RDBMSes available in
mid-nineties offered any of these features (and they do not
appear to meet all these requirements even today). The
decision to use an Object Oriented Database Management
System – Objectivity/DB followed recommendations
from a study at CERN [14]. ODBMS technology seemed
to best fit BaBar’s needs of scalability, complexity and
C++ bindings. Also, the thick-client thin-server
architecture and distributed features seemed well suited to
scaling, in contrast with the traditional, server-heavy
RDBMS approach.

Последнее предложение наиболее интересное.

C>Однако для каталога, наоборот, нужны ad-hoc запросы и быстрое их

C>выполнение. Отсюда и использование РСУБД.
Каталог сам маленький. 3 гига.

>> А как поставщик данных, реляционка не

>> слишком хороша, поскольку не умеет ни нормально их обрабатывать, ни
>> гибко предоставлять.
C>Проблема в том, что РСУБД пока лучше всего умеет поставлять
C>данные. И соответственно, лучше всего проявляет себя в задачах, где
C>нужно быстро и эффективно искать нужные данные.

C>ООБД позволяет быстро обрабатывать сложные данные, но плохо умеет их

C>искать.
Все правильно. Основной плюс РСУБД — действительно ad-hook запросы в строго нормализованном хранилище. Только на больших данных для увеличения производительности некоторых, особо криминальных, транзакций приходится денормализовать, и некоторая возможность ad-hook запросов теряется.
И еще возникает вопрос в том, что такое сложные данные. Один пример(достаточно простой) я уже показывал:

Есть юридические лица. Есть физические лица. У них есть общие аттрибуты, есть разные аттрибуты. А у документа — есть свойство подписант, в роли которого может выступать и юридическое лицо, и физическое.

Такое легко решается.
Другой пример, более криминальный: есть папка. В ней лежат документы. У каждого из них свой набор аттрибутов. Каким запросом можно получить все документы лежащие в конкретной папке? В принципе такое в реляционной модели вообще не опишешь. Но если у тебя объектная модель с наследованием, или слабоструктурированная xml, то такое очень просто решается. Так что в ограничения реляционки натыкаться приходится достаточно часто.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 12:49
Оценка:
Здравствуйте, IT, Вы писали:


GZ>>>>А кто сказал что в распределенной среде ООБД плохо живется?

IT>>>А кто сказал что хорошо?
GZ>>Можешь верить или не верить но именно отчеты и распределенки лучше всего уживаются в распределенной среде по сравнению с чистой реляционкой.

IT>И какое это имеет отношение к ООБД?

Сорри. Читать не распределенной среды а OOБД. Очепятка.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 12:57
Оценка:
Здравствуйте, IT, Вы писали:

Д>>существует и давно применяется CORBA. Существует и применяется .NET Remoting,

IT>Ты путаешь, это всё не распределённый ООП. В данном случае его можно было бы назвать удалённый, но не распределённый. Распределённый — это когда состояние твоей объектной модели размазано по нескольким компьютерам и любой объект или его часть может одновременно находится в нескольких местах.
CORBA — может быть распределенной.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.04.06 13:21
Оценка:
Здравствуйте, shuklin, Вы писали:
S>Ок. Давайте подискутируем на эту тему. Меня она очень интересует как разработчика собственной ООСУБД/БЗ
Давайте. Меня это интересует в той же степени.

S>- инкапсуляция в ОБД ИМХО не столь категорически важна, как в ООП.

Гм. Тогда совершенно непонятно, зачем вообще придумывать какую-то ОБД. Ведь неинкапсулированные данные и так ездят сумасшедшими темпами — десять тысяч обработанных заказов в минуту. И это на потребительском железе, т.е. машинке типа той, с которой я это пишу!
S>Действительно строить индексы по вычисляемым полям объектов занятие не для слабонервных. Но ведь и РБД это не умеют.
Почему же это не умеют??? Еще как умеют.
S>Это просто очень нетривиальная задача, не зависимо от того сеть или таблица является физическим уровнем для хранения полей объектов.
Нетривиальность тут совсем не здесь
S>В своей ОБД я пришел к следующему.
S>- инкапсуляция не рекомендуется к применению. Поля объекта открыты для доступа независимо от методов самого объекта. К этим полям система может обращаться не инстанциируя сам объект.
Таким образом, ты спустил ООП в мусорную корзину. Если объекты устроены таким образом, то все преимущества ООП недостижимы, а весь полиморфизм сводится к выбору подходящей хранимой процедуры.
S>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта. В этом случае программист отгребает все от ручной сериализации и прочих недостатков, о которых ты намекаешь. Согласен. Зато бинарная сериализация действительно быстрее.
Это совсем странно.
S>Я предпочитаю иметь и предоставлять выбор, работать в стиле РБД — без явной инкапсуляции, либо в стиле ООП.
Этот выбор и так есть — RDBMS супротив самописанного хранилища.
S>Теперь расмотрим VIEW как аналог инкапсуляции в РБД. Я поддерживаю объектные VIEW.
View не является аналогом инкапсуляции. В каком-то смысле, можно его и так рассматривать, но в существующем виде это скорее инструмент декомпозиции. В SQL с декомпозицией вообще очень плохо; в большинстве случаев все запросы пишутся прямо поверх самого нижнего уровня. От этого стоимость внесения изменений в систему зашкаливает, и в некоторых случаях начинаются моления на схему данных. Типа — вот этот бы столбец убрать нафиг, ибо никто не помнит, для чего он был придуман, а нельзя — вдруг отчеты посыплются.

Так вот, view позволяют хотя бы немного "расчленить" запросы на более читабельные части.

К сожалению, параметризованные view не предусмотрены стандартом, поэтому всяк производитель реализует "table-valued functions" по-своему.
В свете этого, не вполне ясно, какую именно проблему предполагается решать при помощи твоих объектных VIEW.

S>Поддержка реализована на двух уровнях.

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

S>- на уровне собственно экземпляров — благодаря поддержке самим .NET множественного наследования интерфейсов и известным ООП паттернам, типа мост, адаптер, обертка, ...


S>В последней версии тоже просто — благодаря сетевой архитектуре поддерживаемой на нескольких "уровнях". Экземпляр объекта представляет собой некоторого вида "иерархию" аттрибутов. Однако аттрибут может иметь несколько парент объектов. (паттерн FLYWEIGHT) Таким образом можно строить на основе одних и тех же экземпляров (скаляров, композитов) различные иерархии. — это "глубинный уровень". Тоесть "иерархия" является на самом деле сетью.


S>Во всех версиях на "семантическом уровне" благодаря возможности окраски связей графа с помощью ИД можно проводить операции близкие к JOIN в РБД. Тоесть что то типа WHERE ИД_СВЯЗИ(связь) = ИД_ОБЪЕКТА(объект) А это в Cerebrum было всегда. Даже в VNPI-99


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

select * from IEmployee e where e.Position.CompensationPolicy.GetBonusAmount(e, ProjectStatus.AlphaCompleted)>500;

Подразумеваются следующие интерфейсы:
public interface IEmployee
{
  IPosition Position { get; set; }
}
public interface IPosition
{
  ICompensationPolicy CompensationPolicy { get; }
}
public interface ICompensationPolicy 
{
  Money GetBonusAmount(IEmployee employee, ProjectStatus projectStatus);
}

На первый взгляд, это вообще труба, т.к. мы оперируем исключительно виртуальными методами. Кроме того, у нас явно есть коррелированный параметр — в дополнение к параметру-константе.
В итоге, способов выполнить запрос, кроме полного перебора, не видно. Однако, если "раскрыть скобки", то теоретически возможно избавиться как минимум от полиморфизма — достаточно заменить всякий источник данных на union из соответствующего набора сканирований типов. А это откроет дорогу к применению следующих методик оптимизации.
Пока что СУБД, способная это делать, мне неизвестна.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 23.04.06 13:39
Оценка:
GlebZ wrote:
> C>Что вполне логично — основная объектная база используется для хранения
> C>больших объемов сложносвязанных массивных данных. В основных данных не
> C>надо делать поиск по многим таблицам со сложными объединениями, пути
> C>доступа к данным относительно фиксированы и нужны сложные
> C>числодробитильные вычисления на клиентах. В общем, идеальные условия для
> C>ООБД.
> Ты не то посмотрел. Там есть конкретный абзац почему была выбрана
> Objectivity
Ну вообще-то я об этом и сказал

> An object oriented approach seems to be the most

> natural way to model HEP data, where complex many-tomany
> relationships are commonplace.
"сложносвязанных" — в моем сообщении.

> above, the persistency system has to also provide multipetabyte

> scalability.
"массивных".

> Also, the thick-client thin-server

> architecture and distributed features seemed well suited to
> scaling, in contrast with the traditional, server-heavy
> RDBMS approach.
> Последнее предложение наиболее интересное.
"сложные числодробитильные вычисления на клиентах"

> C>Однако для каталога, наоборот, нужны ad-hoc запросы и быстрое их

> C>выполнение. Отсюда и использование РСУБД.
> Каталог сам маленький. 3 гига.
Однако поиск нужен быстрый.

> C>ООБД позволяет быстро обрабатывать сложные данные, но плохо умеет их

> C>искать.
> Все правильно. Основной плюс РСУБД — действительно ad-hook запросы в
> строго нормализованном хранилище.
ad-hoc вообще-то

> Только на больших данных для

> увеличения производительности некоторых, особо криминальных, транзакций
> приходится денормализовать, и некоторая возможность ad-hook запросов
> теряется.
Балланс, однако.

> И еще возникает вопрос в том, что такое сложные данные. Один

> пример(достаточно простой) я уже показывал:
> Есть юридические лица. Есть физические лица. У них есть общие аттрибуты,
> есть разные аттрибуты. А у документа — есть свойство подписант, в роли
> которого может выступать и юридическое лицо, и физическое.
> Такое легко решается.
Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно
моделируется join'ами.

> Другой пример, более криминальный: есть папка. В ней лежат документы. У

> каждого из них свой набор аттрибутов. Каким запросом можно получить все
> документы лежащие в конкретной папке?
"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я
чего-то не понимаю?

> В принципе такое в реляционной модели вообще не опишешь.

> Но если у тебя объектная модель с
> наследованием, или слабоструктурированная xml, то такое очень просто
> решается. Так что в ограничения реляционки натыкаться приходится
> достаточно часто.
Учти, надо не просто решить, а _быстро_ решить. За логарифмическое
время, иначе на больших объемах будут торррмоза.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 13:45
Оценка:
Здравствуйте, Дарней, Вы писали:

Д> Если реализация ООП в одном конкретном языке создает...

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

Д>А теперь объясни, какие принципиальные проблемы создает применение принципов ООП к этой задаче.

Re: Файловые системы, файлы, приложения &mdash; устаревшие концепц
Автор: Merle
Дата: 20.04.06


Д>Не нужно отсылать меня к своим предыдущим сообщениям — там все равно нет никакой конкретной информации.

Там все более чем конкретно и я не виноват, что ты этого не понимаешь.

Д> Я кстати так и не дождался ответа на вопрос, почему расширение интерфейса объекта — это зло.

Я тебе ответил, но ты, видимо, предпочел этого не заметить.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 13:45
Оценка:
Здравствуйте, Дарней, Вы писали:

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

Re[7]: Файловые системы, файлы, приложения &mdash; устаревшие конц
Автор: Merle
Дата: 20.04.06

...только вот не везде и не всегда с ними (объектами) удобно


Д>Давай обойдемся без личных нападок?

Никаких нападок, как ни странно, я просто не люблю, когда перевирают мои слова и приписываю мне то, что я не говорил.

Д>я у тебя спросил что? Я спросил именно про те проблемы, которые не решаются никак.

То есть попытался сменить тему разговора и развести демагогию.

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

Верно, только "развитие средств программирования" != "развитие ООП"

Д>Если ты решил ответить на вопрос, который я тебе не задавал — это твоя проблема.

То что тебе не понравился ответ, не означает, что я отвечал на что-то другое, и в любом случае это не дает тебе права перевирать мои слова.

Д>в таком случае, постарайся сделать неимоверное усилие воли и сформулировать свои мысли четко.

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

Д>Варианты ответа: да, нет, не знаю, иное. Если последнее, то расшифровать подробно.

Подробно я уже расшифровал. Еще подробнее — это означает, что дальше ООП развиваться не будет, область применения определена, оно заняло свою нишу с довольно четкими границами.

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

Кто бы говорил.

Д> Приведи пример, а, будь человеком?

Я привел уже все примеры, более чм достаточные для понимания, если не понятно — я не виноват.

Д>если добавление новых методов для работы с объектом угрожает порушить всю программу, то выход здесь один — лоботомия.

Понятно, с фундаментальными принципами у нас-таки плохо.

Д>ну так ты предлагай варианты, я слушаю.

Я изложил. Выбирать решение адекватное задаче. Например, если задача — хранить данные, то надо хранить данные, а не объекты.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 13:45
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>это всё не имеет смысла.

Действительно, но если бы ты не занимался искажением чужих слов, то возможно смысл бы сохранился.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 16:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Also, the thick-client thin-server

>> architecture and distributed features seemed well suited to
>> scaling, in contrast with the traditional, server-heavy
>> RDBMS approach.
>> Последнее предложение наиболее интересное.
C>"сложные числодробитильные вычисления на клиентах"
Вообще-то этот абзац я перевел немножко по другому. И тут вообще не говорится о числодробилках.


>> Все правильно. Основной плюс РСУБД — действительно ad-hook запросы в

>> строго нормализованном хранилище.
C>ad-hoc вообще-то
Очепятка.

>> Только на больших данных для

>> увеличения производительности некоторых, особо криминальных, транзакций
>> приходится денормализовать, и некоторая возможность ad-hook запросов
>> теряется.
C>Балланс, однако.
Иногда баланс. А иногда получается схема чрезвычайно напоминающая OODB.

C>Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно

C>моделируется join'ами.
Ты откуда такое узнал? Источник можешь указать?


>> Другой пример, более криминальный: есть папка. В ней лежат документы. У

>> каждого из них свой набор аттрибутов. Каким запросом можно получить все
>> документы лежащие в конкретной папке?
C>"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я
C>чего-то не понимаю?
Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.


>> В принципе такое в реляционной модели вообще не опишешь.

>> Но если у тебя объектная модель с
>> наследованием, или слабоструктурированная xml, то такое очень просто
>> решается. Так что в ограничения реляционки натыкаться приходится
>> достаточно часто.
C>Учти, надо не просто решить, а _быстро_ решить. За логарифмическое
C>время, иначе на больших объемах будут торррмоза.
Так в том, то и дело, что при таких вещах в реляционке можно о логарифмическом времени забыть. Здесь нужны многомерные индексы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 23.04.06 16:22
Оценка:
GlebZ wrote:
> C>Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно
> C>моделируется join'ами.
> Ты откуда такое узнал? Источник можешь указать?
На сайте Hibernate'а видел

> C>"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я

> C>чего-то не понимаю?
> Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных
> документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
Вполне можно:

1. Выделяем общие для всех документов данные в одну таблицу такого вида:
=========================================================
| DocId | Parent-folder | Creation-date |...
+=======+=====================+=========+================
| 11    | 135           | 01/01/01      |...
+-------+---------------------+--------------------------
|...


2. Делаем для каждого _типа_ документов свою таблицу:
=========================================================
| DocId | Type-specific-field | Type-specific-field I ...
+=======+=====================+==========================
| 11    | blah-blah           | blah-blah-2
+-------+---------------------+--------------------------
|...


Теперь для того, чтобы взять все документы типа "Декларация" делаем так:
SELECT * FROM declaration, document WHERE document.id=declaration.id


Таким образом получаем "наследование" — все документы типа "Декларация"
являются "Документами" и могут "cast'оваться" к ним.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 23.04.06 16:56
Оценка:
Здравствуйте, GlebZ, Вы писали:

IT>>Без понятия. К моему стыду я даже не знаю какую базу данных ты меешь ввиду

GZ>ReBar

А что они хранят в этой БД?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Файловые системы, файлы, приложения - устаревшие конц
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.04.06 17:02
Оценка:
Здравствуйте, shuklin, Вы писали:

S>>>Да. И считаю это основным достоинством ОБД.

M>>А я считаю это причиной того, что ООБД обречены.

S>А я считаю это причиной того, что РБД обречены на провал, а ОБД обречены на успех.

S>Время нас рассудит.

Оно уже лет, эдак, 20 рассуждает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 23.04.06 17:07
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Реальной распределённости при сегодняшнем уровне технологий добится очень сложно и то только за счёт гарантированных тормозов. Нужно транзакционно обновлять распределённое состояние объекта, т.е. делать что-то типа распределённого lock. Если эти требования снижать, то можно получить иллюзию распределённости. Например, мы можем принять такое допущение, что объект может изменяться только одним писателем, при этом доступ к объекту на время обновления его распределённого состояния разрешен, а возможными коллизиями мы можем пренебречь.


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


Снимается легко. Ты вообще если не хочешь можешь не связываться с этими проблемами. А в случае с распределённым ООП постоянное решение таких проблем — это перманентное состояние разработчика.

IT>>Ты можешь привести какой-нибудь реальный пример таких других реализаций?


Д>Смоллток. Схема. Руби.

Д>Некоторые концепции ООП до сих пор еще не реализованы толком ни в одном языке.
Д>этого достаточно?

Не достаточно. Это ты сейчас махнул рукой в сторону и сказал "Там, если надо сходи посмотри". Я не это спрашивал. Что конкретно в этих реализациях по твоему не укладывается в нашу систему абстракций?

IT>>Синхронизация состояния.

Д>а при отсутствии объектов, значит, всё синхронизируется само собой?

Что "всё"? В случае с объектами "всё" — это их состояние. Что ты подразумеваешь под "всё" в случае отказа от объектов?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 17:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> C>Ну это без проблем делается в РСУБД. Вообще, наследование прекрасно

>> C>моделируется join'ами.
>> Ты откуда такое узнал? Источник можешь указать?
C>На сайте Hibernate'а видел
Врут. Каждый наследник требует своего запроса. Иначе сильный overhead. В том же hibernate, можно прямо указать что overhead будет небольшой и можно получать данные через join.

>> C>"SELECT * FROM Document WHERE Document.ParentFolder=blah_blah"? Или я

>> C>чего-то не понимаю?
>> Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных
>> документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
C>Вполне можно:
Внимательней. Получить документы лежащие в папке. Я нигде не писал что документы должны быть определенного типа. Такой задачи не стоит.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 23.04.06 17:12
Оценка:
Здравствуйте, GlebZ, Вы писали:

IT>>Ты путаешь, это всё не распределённый ООП. В данном случае его можно было бы назвать удалённый, но не распределённый. Распределённый — это когда состояние твоей объектной модели размазано по нескольким компьютерам и любой объект или его часть может одновременно находится в нескольких местах.

GZ>CORBA — может быть распределенной.

Может уже больше 10 лет. Тем не менее что-то пока не видно абсолютного доминирования распределённых CORBA систем на рынке.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 17:26
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>>>Ты путаешь, это всё не распределённый ООП. В данном случае его можно было бы назвать удалённый, но не распределённый. Распределённый — это когда состояние твоей объектной модели размазано по нескольким компьютерам и любой объект или его часть может одновременно находится в нескольких местах.

GZ>>CORBA — может быть распределенной.

IT>Может уже больше 10 лет. Тем не менее что-то пока не видно абсолютного доминирования распределённых CORBA систем на рынке.

Так ты сам, вполне правильно сказал. Тормозит. Я просто поправил что CORBA, как стандарт, поддерживает распределенность.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[5]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 23.04.06 17:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

S>>>>Да. И считаю это основным достоинством ОБД.

M>>>А я считаю это причиной того, что ООБД обречены.

S>>А я считаю это причиной того, что РБД обречены на провал, а ОБД обречены на успех.

S>>Время нас рассудит.

ГВ>Оно уже лет, эдак, 20 рассуждает.

Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных. Просто по многим параметрам они более похожи на ОБД чем на реляционные базы данных.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 17:37
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Без понятия. К моему стыду я даже не знаю какую базу данных ты меешь ввиду

GZ>>ReBar

IT>А что они хранят в этой БД?

Насколько я понял какие-то физические параметры небольшой длины но в огромном количестве. Остальное для того чтобы эти данные обработать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.04.06 17:37
Оценка:
Здравствуйте, GlebZ, Вы писали:

S>>>А я считаю это причиной того, что РБД обречены на провал, а ОБД обречены на успех.

S>>>Время нас рассудит.
ГВ>>Оно уже лет, эдак, 20 рассуждает.
GZ>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных. Просто по многим параметрам они более похожи на ОБД чем на реляционные базы данных.

А избыточность XML куда девать?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 23.04.06 17:43
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А избыточность XML куда девать?

А кто тебе сказал что данные в xml базе данных лежат в текстовом виде? Это не какой-нибудь парсер.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 23.04.06 17:46
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.

GZ>>Скорее немного не так. Когда машина начнет понимать что человек написал. А DLinq уже может интерпретировать и трансформировать такой код. Так что эпоха не начинается, а можно сказать наступила.

IT>Ну если DLing по твоему это шаг вперёд в нужном направлении, то нам ещё долго шагать

DLinq умеет генерить функциональный граф который можно обработать и получить нормальные селективные условия. Это как раз то, чего сильно не хватало до этого.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 17:57
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных.

С ними та же проблема что и с ООП, слшком жестко заданная структура, которую придется менять при изменении требований...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 23.04.06 18:29
Оценка:
Здравствуйте, Merle, Вы писали:

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


GZ>>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных.

M>С ними та же проблема что и с ООП, слшком жестко заданная структура, которую придется менять при изменении требований...
С чего ты взял что там жестко заданная структура? Как раз слабоструктурированная структура которая даст фору всей реляционке. А самое главное гибкие ссылки.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 23.04.06 18:41
Оценка:
Здравствуйте, GlebZ, Вы писали:

IT>>А что они хранят в этой БД?

GZ>Насколько я понял какие-то физические параметры небольшой длины но в огромном количестве. Остальное для того чтобы эти данные обработать.

И скорее всего база работает только в режиме чтения и добавления. Никаких удалений или изменений, правильно?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.04.06 18:41
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>DLinq умеет генерить функциональный граф который можно обработать и получить нормальные селективные условия. Это как раз то, чего сильно не хватало до этого.


В Hibernate все это было еще сто лет назад.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 19:09
Оценка:
Здравствуйте, AndrewVK, Вы писали:

GZ>>DLinq умеет генерить функциональный граф который можно обработать и получить нормальные селективные условия. Это как раз то, чего сильно не хватало до этого.


AVK>В Hibernate все это было еще сто лет назад.

Что было?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.04.06 19:13
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>В Hibernate все это было еще сто лет назад.

GZ>Что было?

Я процитировал.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 19:14
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>А что они хранят в этой БД?

GZ>>Насколько я понял какие-то физические параметры небольшой длины но в огромном количестве. Остальное для того чтобы эти данные обработать.

IT>И скорее всего база работает только в режиме чтения и добавления. Никаких удалений или изменений, правильно?

Ты о concurrency? Там она есть. Прочитай документ, он написан достаточно просто и кратко. Не хочется быть кривым радио.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 19:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>В Hibernate все это было еще сто лет назад.

GZ>>Что было?

AVK>Я процитировал.

Не сразу понял что ты имел ввиду. Вопрос в том, как создается данное дерево. В Net оно создается в самом языке. Для Hibernate приходится собирать его практически вручную.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 20:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))

S>>поиск в ОБД O(logШ + logШ' * logу)
Вообще-то для OБД тут логика несколько неправильная. Если ученики и школы находятся в разных экстентах, то разницы между реляционкой и ОБД нет. Даже если ученики находятся в том же экстенте что и школы, это отнюдь не значит что по ним нельзя делать прямых выборок. Но вот если еще введена операция фильтрации по пути, если этот путь указывает на тот же экстент, то ОБД безусловно выйграет. Так как сложность будет измеряться по самому селективному предикату. Другой вопрос что тут можно попасться на остальных запросах, так как размер одного объекта хранения экстента значительно больше и потребует большего количества чтений с диска.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 20:05
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>С чего ты взял что там жестко заданная структура?

С того, что она там жестко задана, в виде дерева с одним корнем.

GZ>Как раз слабоструктурированная структура которая даст фору всей реляционке.

В чем она фору даст?

GZ> А самое главное гибкие ссылки.

И что толку от этих гибких ссылок без поддержки индексов? Структура XML документа задает один наиболее эффективный путь доступа к подветкам, все гибкие ссылки которые в этот путь не укладываются сливают по эффективности негибким...
С точки же зрения реляционки — весь XML очень хорошо укладывается в одну таблицу, что очень хорошо показал MS.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.04.06 20:09
Оценка:
Здравствуйте, GlebZ, Вы писали:

ГВ>>А избыточность XML куда девать?

GZ>А кто тебе сказал что данные в xml базе данных лежат в текстовом виде? Это не какой-нибудь парсер.

Да это-то понятно. Но всё равно какая-никакая, но индивидуальная идентификация атрибутов должна быть.

Я имею ввиду вот что.

Например, если у нас есть таблица документов РБД, то данные можно уложить плотно, в соответствии со структурой таблицы. Мы в любом случае будем знать, что, скажем, по смещению 0x21 от физического начала записи начинается поле "дата документа". А вот в слабоструктурированом хранилище придётся к каждому фактическому атрибуту присовокуплять его идентификатор и сущность (или код идентификатора в каком-то словаре, не суть). По сумме это должно дать нехилый оверхед по габаритам или выродиться в РБД.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.04.06 20:21
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Не сразу понял что ты имел ввиду. Вопрос в том, как создается данное дерево. В Net оно создается в самом языке. Для Hibernate приходится собирать его практически вручную.


Это технические детали, не имеющие кардинального значения.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
AVK Blog
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 20:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

GZ>>Не сразу понял что ты имел ввиду. Вопрос в том, как создается данное дерево. В Net оно создается в самом языке. Для Hibernate приходится собирать его практически вручную.


AVK>Это технические детали, не имеющие кардинального значения.

Имеющие. Очень даже имеющие. Если говорить о ОДБ, то теперь вполне можно обозначать некоторые методы как возможные предикаты, из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 20:50
Оценка:
Здравствуйте, Merle, Вы писали:

GZ>> А самое главное гибкие ссылки.

M>И что толку от этих гибких ссылок без поддержки индексов? Структура XML документа задает один наиболее эффективный путь доступа к подветкам, все гибкие ссылки которые в этот путь не укладываются сливают по эффективности негибким...
Дело в том, что здесь используются именно многомерные индексы. И желательно, чтобы на нем был constraint который указывал бы какого типа нода может быть элементом (некоторые утверждают что в их случае это улучшает работу их оптимизаторов запросов). И кстати, xml давно уже вырос из штанишек дерева и поддерживает ссылки. То есть сетевую модель.
M>С точки же зрения реляционки — весь XML очень хорошо укладывается в одну таблицу, что очень хорошо показал MS.
Это с точки зрения реляционки. С точки зрения разработчиков чистых xml баз данных это не совсем так. Они все таки задумываются об оптимизации работы с диском. Поэтому стараются разбивать. (правда кое-кого видел, которые хранили и в одной таблице — но это редкость).
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 23.04.06 21:07
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Дело в том, что здесь используются именно многомерные индексы.

Где и кем? Я уже приводил пример сиквела — ребята из MS потратили, по некоторым данным, около восьми лет на исследования, как лучше хранить и индексировать XML, рассматривая R-деревья, Quadtree и прочую экзотику... И в итоге остановились-таки на банальном кластерном B+ по реляционной таблице...

GZ>Это с точки зрения реляционки. С точки зрения разработчиков чистых xml баз данных это не совсем так. Они все таки задумываются об оптимизации работы с диском. Поэтому стараются разбивать. (правда кое-кого видел, которые хранили и в одной таблице — но это редкость).

Ну вот только результатов этой оптимизации с помощю хитрых индексов что-то невидать...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 23.04.06 21:24
Оценка:
Здравствуйте, Merle, Вы писали:

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


GZ>>Дело в том, что здесь используются именно многомерные индексы.

M>Где и кем? Я уже приводил пример сиквела — ребята из MS потратили, по некоторым данным, около восьми лет на исследования, как лучше хранить и индексировать XML, рассматривая R-деревья, Quadtree и прочую экзотику... И в итоге остановились-таки на банальном кластерном B+ по реляционной таблице...
Ага. И в результате получили решение, которое не особо их обременяло в реализации.

GZ>>Это с точки зрения реляционки. С точки зрения разработчиков чистых xml баз данных это не совсем так. Они все таки задумываются об оптимизации работы с диском. Поэтому стараются разбивать. (правда кое-кого видел, которые хранили и в одной таблице — но это редкость).

M>Ну вот только результатов этой оптимизации с помощю хитрых индексов что-то невидать...
Знаешь. Для того чтобы можно было квалифицированно что-то сказать, нужно пробовать benchmark. Ни со стороны Microsoft, ни с другой какой-либо стороны, я таких публикаций не видел. Соответсвенно, пока утверждения о самом правильном подходе можно считать голословными.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: Max.Subpixel Россия  
Дата: 23.04.06 21:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Ок. Давайте подискутируем на эту тему. Меня она очень интересует как разработчика собственной ООСУБД/БЗ

S>Давайте. Меня это интересует в той же степени.

Ох, сколько тут оказывается разработчиков ООБД....

S>>В своей ОБД я пришел к следующему.

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

Поддерживаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Best Regards. Max.
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 23.04.06 21:57
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Ну во первых, хватит обвинять меня во вранье. Я всего лишь пытаюсь выделить смысл в твоих словесных заграждениях.

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

Про распределённый ООП вообще-то системы не Иван
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: IT Россия linq2db.com
Дата: 23.04.06 21:57
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>С чего ты взял что там жестко заданная структура? Как раз слабоструктурированная структура которая даст фору всей реляционке. А самое главное гибкие ссылки.


Я очень сильно сомневаюсь в данном утверждении.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.04.06 01:23
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


S>>>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))

S>>>поиск в ОБД O(logШ + logШ' * logу)
GZ>Вообще-то для OБД тут логика несколько неправильная.
Это, извини, смотря какая ОБД. Если мы храним коллекцию учеников в виде коллекционного свойства ("внутри" объекта школы), то без инстанцирования ничего не выйдет.
Если мы храним учеников в отдельном экстенте, оборудуем ученика ссылкой на школу, а коллекция учеников школы строится путем выполнения backreference (select * from student where schoool = @school), то это полностью эквивалентно РБД.
GZ>Если ученики и школы находятся в разных экстентах, то разницы между реляционкой и ОБД нет. Даже если ученики находятся в том же экстенте что и школы, это отнюдь не значит что по ним нельзя делать прямых выборок. Но вот если еще введена операция фильтрации по пути, если этот путь указывает на тот же экстент, то ОБД безусловно выйграет.
Это работает только в том случае, если путь известен. Именно такая штука, насколько мне известно, работает в GemStone. Насчет безусловности я очень сомневаюсь. Для RDBMS этот запрос — всего лишь частный случай; оптимизатор может выбрать любой порядок выполнения join и один из нескольких алгоритмов — все определяется фактической статистикой заполнения данных и параметрами запроса.
GZ>Так как сложность будет измеряться по самому селективному предикату.
Я не очень себе представляю, как будет выбран самый селективный предикат.
GZ>Другой вопрос что тут можно попасться на остальных запросах, так как размер одного объекта хранения экстента значительно больше и потребует большего количества чтений с диска.
В том-то и дело. Сетевые и иерархические СУБД слили в историческом плане именно потому, что оптимизировали одни запросы в ущерб другим. Умение RDBMS адаптироваться к максимально широкому классу запросов и обеспечило их успех.

При этом обрати внимание на то, что собственно никакие ОО-свойства СУБД в данном контексте никак не задействованы.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Файловые системы, файлы, приложения - устаревшие конц
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.04.06 02:14
Оценка:
Здравствуйте, GlebZ, Вы писали:
ГВ>>Оно уже лет, эдак, 20 рассуждает.
GZ>Лично мое имхо, что в будущем будут доминировать не реляционки и не ОБД, а xml базы данных. Просто по многим параметрам они более похожи на ОБД чем на реляционные базы данных.
Это ты себе как представляешь? Чем это может быть обусловлено?
Я вижу только два отличия "XML" от, скажем, реестра:
1. наличие схемы
2. наличие языка запросов
Причем для настоящего успеха нужно к этому иметь:
3. эффективную систему внутреннего представления XML-данных
4. оптимизатор запросов, способный реализовывать запросы (2) поверх этого представления (3), используя метаданные из (1).
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.04.06 02:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Например, если у нас есть таблица документов РБД, то данные можно уложить плотно, в соответствии со структурой таблицы. Мы в любом случае будем знать, что, скажем, по смещению 0x21 от физического начала записи начинается поле "дата документа".
Вообще-то эти представления, мягко говоря, устарели. Во времена Clipper типичным решением была действительно прямоугольная таблица, где можно было точно вычислить положение поля P записи R в файле по формуле header_size + record_size*(R1-1)+offset(P).
На практике оказалось, что для эффективной реализации необходимо и достаточно знать положение фрагмента данных с точностью до одной страницы. Как только мы отказываемся от коцепции "текущей записи", прямоугольность таблицы перестает играть решающее значение.
ГВ>А вот в слабоструктурированом хранилище придётся к каждому фактическому атрибуту присовокуплять его идентификатор и сущность (или код идентификатора в каком-то словаре, не суть). По сумме это должно дать нехилый оверхед по габаритам или выродиться в РБД.
Непонятно, во что именно это должно выродиться. Современные RDBMS построены на том, что
а) есть язык декларативных запросов
б) есть набор низкоуровневых операций, которые выполняются очень эффективно (а их очень мало — table scan, index scan, index seek)
в) есть некоторая алгебра, позволяющая строить из одних операций другие (например, join как комбинация table scan + index seek)
г) есть оптимизатор запросов, который выбирает достаточно оптимальный план выполнения — т.е. набор низкоуровневых операций и алгебраических действий над их результатами.
Таким образом, структура хранилища целиком определяется набором тех самых низкоуровевых операций. Эти операции должны быть ровно такими, чтобы обеспечить приемлемую эффективность алгебры над ними; а необходимая алгебра определяется языком запросов.

Я плохо знаю, как именно реализовали поддержку XML в Yukon — тут Иван больше меня разбирался. Вроде как там внутри что-то похожее на RDBMS, но в точности я не уверен. Опять же, неясно, достигнут ли предел — может быть, отказ от некоторых операций или свойств XML позволит еще улучшить эффективность.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 24.04.06 07:48
Оценка:
GlebZ wrote:
> C>На сайте Hibernate'а видел
> Врут. Каждый наследник требует своего запроса. Иначе сильный overhead. В
> том же hibernate, можно прямо указать что overhead будет небольшой и
> можно получать данные через join.
А _зачем_ нам каждый наследник в отдельности? Обычно требуется работа
или с отдельными классами или только с базовыми классами, в обоих
случаях отдельные запросы не нужны.

Ну а в вырожденных случаях, все равно, проще все загрузить и профильтровать.

>> > Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных

>> > документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
> C>Вполне можно:
> Внимательней. Получить документы лежащие в папке. Я нигде не писал что
> документы должны быть определенного типа. Такой задачи не стоит.
А я получил все документы, лежащие в папке. Можно делать с ними дальше
что угодно, например, сделать JOIN по всем типам и вывести результат.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.04.06 07:57
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Имеющие. Очень даже имеющие. Если говорить о ОДБ, то теперь вполне можно обозначать некоторые методы как возможные предикаты,


Методы нельзя, только лямбды.

GZ> из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.


Это можно делать и в Hibernate.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 24.04.06 08:07
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Ага. И в результате получили решение, которое не особо их обременяло в реализации.

Видишь ли, MS очень сложно обременить реализацией, и уж коли они потратили столько сил на исследования альтернативных подходов, то если бы какое-то альтернативное решение показало бы заметное преимущество, то с реализацией они бы справились.

GZ> Соответсвенно, пока утверждения о самом правильном подходе можно считать голословными.

Ну вот и договорились..
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 09:31
Оценка:
Здравствуйте, Merle, Вы писали:

M>Я тебя уже дважды просил не менять тему. Прекращай заниматься демагогией. Приведя в пример один конкретный язык я отвечал на совершенно другой вопрос.


Я не менял тему. Просто напиши четко и конкретно, что ты хотел сказать. Я уже устал от твоих передергиваний.
И перестань разбрасываться обвинениями во вранье и демагогии.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 09:31
Оценка:
Здравствуйте, IT, Вы писали:

IT>Снимается легко. Ты вообще если не хочешь можешь не связываться с этими проблемами. А в случае с распределённым ООП постоянное решение таких проблем — это перманентное состояние разработчика.


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

IT>Не достаточно. Это ты сейчас махнул рукой в сторону и сказал "Там, если надо сходи посмотри". Я не это спрашивал. Что конкретно в этих реализациях по твоему не укладывается в нашу систему абстракций?


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

IT>>>Синхронизация состояния.

Д>>а при отсутствии объектов, значит, всё синхронизируется само собой?

IT>Что "всё"? В случае с объектами "всё" — это их состояние. Что ты подразумеваешь под "всё" в случае отказа от объектов?


я подразумеваю связанные наборы данных, обновление которых требует транзакционности. Так яснее?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 09:31
Оценка:
Здравствуйте, IT, Вы писали:

Д>>Как следует понимать высказывание, что "ООП не работает в распределенных системах"? Если оно не работает, значит, есть какие-то принципиальное нерешаемые проблемы? Или в твоих абстракциях нет места приземленной логике, потому что всё занял возвышеный полет мысли?


IT>Про распределённый ООП вообще-то системы не Иван


он тоже
Re[9]: Файловые системы, файлы, приложения &mdash; устаревшие конц
Автор: Merle
Дата: 20.04.06
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 09:31
Оценка:
Здравствуйте, Merle, Вы писали:

M>То есть попытался сменить тему разговора и развести демагогию.


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

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


Ура! это уже намного конструктивнее

Закат — это синоним слов "конец", "смерть". Отсутствие развития и "конец" — это совершенно разные вещи. Так что если хочешь, чтобы тебя понимали правильно — используй правильные слова.
Далее. Почему обязательно развитие ООП должно остановиться?

Д>>если добавление новых методов для работы с объектом угрожает порушить всю программу, то выход здесь один — лоботомия.

M>Понятно, с фундаментальными принципами у нас-таки плохо.

почему?

Д>>ну так ты предлагай варианты, я слушаю.

M>Я изложил. Выбирать решение адекватное задаче. Например, если задача — хранить данные, то надо хранить данные, а не объекты.

не бывает такой задачи — "хранить данные". Бывает задача "хранить и обрабатывать данные". А данные в совокупности с методами их обработки — это объекты. Насколько часто ты видел полностью нормализованную базу без единой SP или триггера, кстати?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 24.04.06 10:27
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Я не менял тему.

Менял...

Д> Просто напиши четко и конкретно, что ты хотел сказать.

Я написал, перечитай внимательно всю эту подветку.

Д>И перестань разбрасываться обвинениями во вранье и демагогии.

Ну, ты знаешь что для этого нужно сделать... И вообще давай завязывать, очевидно конструктива у нас с тобой не получится.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 10:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>>тогда поиск в РБД будет O(logШ + logУ + log(Ш'*У'))

S>>>>поиск в ОБД O(logШ + logШ' * logу)
GZ>>Вообще-то для OБД тут логика несколько неправильная.
S>Это, извини, смотря какая ОБД. Если мы храним коллекцию учеников в виде коллекционного свойства ("внутри" объекта школы), то без инстанцирования ничего не выйдет.
Ну, если мы сравниваем системы по достаточно качественным образцам(в реляционке, де факто, это Oracle и MSSQL), то стоит и в OODB брать именно качественные образцы(для меня это Versant и GemStone/S).
GZ>>Так как сложность будет измеряться по самому селективному предикату.
S>Я не очень себе представляю, как будет выбран самый селективный предикат.
По статистике ессно.
GZ>>Другой вопрос что тут можно попасться на остальных запросах, так как размер одного объекта хранения экстента значительно больше и потребует большего количества чтений с диска.
S>В том-то и дело. Сетевые и иерархические СУБД слили в историческом плане именно потому, что оптимизировали одни запросы в ущерб другим. Умение RDBMS адаптироваться к максимально широкому классу запросов и обеспечило их успех.
Только вот не надо мешать OODB и другие виды баз. Хотя данная проблема для OODB существует.
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: GlebZ Россия  
Дата: 24.04.06 11:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это ты себе как представляешь? Чем это может быть обусловлено?

S>Я вижу только два отличия "XML" от, скажем, реестра:
Ты сравниваешь чайник и комбайн. Они не сравнимы не только по мощности, но и по вариантам использования.
S>1. наличие схемы
Мало того. Можно делать схему вручную, можно создавать на основе входящего xml потока. Xml штука достаточно самоописывающаяся.
S>2. наличие языка запросов
Не просто языка запросов, а мощного языка запросов. Результат запроса — это может быть не просто подветка, или значение. Это может быть полностью сгенерированный набор нод или граф. При этом в XQuery кроме работы с путями, поддерживаются реляционный join(сейчас времени нет подсмотреть, но возможно и все стандартные реляционные операции, расширенные вряд ли). XQuery — чрезвычайно мощный язык запросов.
3. Xml может быть графом. В нем есть поддержка ссылок.
S>Причем для настоящего успеха нужно к этому иметь:
S>3. эффективную систему внутреннего представления XML-данных
+1
S>4. оптимизатор запросов, способный реализовывать запросы (2) поверх этого представления (3), используя метаданные из (1).
+1
5. Методы потоковой обработки. В отличие от реляционки, и вставляемый xml и результирующий xml — потоки. Поэтому стараются делать не только методы работы с хранилищем, но и обработку потоков.

И именно этим сейчас занимается куча народу. Каждый реализует по своему. И опять те же проблемы. Не хватает теоретиков уровня Кодда.
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 11:20
Оценка:
Здравствуйте, Merle, Вы писали:

<поскипано>

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


чаще всего кричат о демагогии те, кто сами ей занимаются. Хватит уже, не наводи на плохие мысли.

Д>>Закат — это синоним слов "конец", "смерть". Отсутствие развития и "конец" — это совершенно разные вещи.

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

Нет, я назову это днем. Может быть, даже очень длинным полярным Но уж никак не закатом.

M>Кстати, еще одна иллюстрация передергивания.


да у вас паранойя, господин

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


Новые языки и подходы плодятся каждый день. Одна из довольно интересных фич — динамическая классификация — так и не реализована толком нигде. Так что ты просто не прав, развитие идет вовсю.

M>Потому что принцип "расширять, гораздо выгоднее чем менять" — один из самых фундаментальных.


Ты уж определись, нужно тебе менять функционал или нет. Если нужно, то без изменения кода ты все равно никуда не денешься, и неважно, где он лежит — в базе или вне её.

Д>>не бывает такой задачи — "хранить данные".

M>Бывает.

Попробую догадаться. Ты случайно не администрированием баз занимаешься?

M>Это две задачи. Есть задача хранить и есть задача обрабатывать. Причем задача обрабатывать, меняется гораздо чаще, чем хранить.


Не бывает задачи "просто хранить". Если данные где-то хранятся, то только для того, чтобы их обрабатывать. А просто БД с наглухо закрытыми входами и выходами — это из раздела розовых мечтаний DBA

Д>>Насколько часто ты видел полностью нормализованную базу без единой SP или триггера, кстати?

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

При том, что это средства эмуляции инкапсуляции данных. Ну так что, много ты баз без них видел?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 11:23
Оценка:
Здравствуйте, Merle, Вы писали:

M>Я написал, перечитай внимательно всю эту подветку.


уже. ничего интересного пока не нашел
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 11:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:

>> C>На сайте Hibernate'а видел
>> Врут. Каждый наследник требует своего запроса. Иначе сильный overhead. В
>> том же hibernate, можно прямо указать что overhead будет небольшой и
>> можно получать данные через join.
C>А _зачем_ нам каждый наследник в отдельности? Обычно требуется работа
C>или с отдельными классами или только с базовыми классами, в обоих
C>случаях отдельные запросы не нужны.
Что значит с базовыми? Один из больших недостатков OODB и ORM — избыточность чтения. Экземпляр должен быть загружен полностью, иначе им пользоваться нельзя(в принципе конечно можно и наполовину, но подобных реализаций в контексте ORM я не видел. Очевидно что слишком сложная будет реализация самого объекта).

C
>>> > Плохо прочитал, смотри выделенное. И еще дополнительно — типов различных
>>> > документов обычно от 10 до 50. Вложить их в одну таблицу нельзя.
>> C>Вполне можно:
>> Внимательней. Получить документы лежащие в папке. Я нигде не писал что
>> документы должны быть определенного типа. Такой задачи не стоит.
C>А я получил все документы, лежащие в папке. Можно делать с ними дальше
C>что угодно, например, сделать JOIN по всем типам и вывести результат.
Ты не получил все документы лежащие в папке. Каждый документ — это разный набор аттрибут. Нет одной таблицы Document. Да даже если и есть, ты не сделаешь join по всем типам. У тебя получатся записи по несколько сот столбцов. Не все базы данных такое держат. К тому же, по 50 джоинам реляционка очень хреново работает. Так что скорее всего, удобоваримого результата ты здесь не получишь.
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 11:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

GZ>>Имеющие. Очень даже имеющие. Если говорить о ОДБ, то теперь вполне можно обозначать некоторые методы как возможные предикаты,

AVK>Методы нельзя, только лямбды.
А из лямбд методы вызывать нельзя?

GZ>> из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.

AVK>Это можно делать и в Hibernate.
Hibernate может разбирать программный код?
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.04.06 11:42
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>Методы нельзя, только лямбды.

GZ>А из лямбд методы вызывать нельзя?

Можно, но expression tree ты по им не получишь.

GZ>>> из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.

AVK>>Это можно делать и в Hibernate.
GZ>Hibernate может разбирать программный код?

Собственный QL может. А произвольный код программы рабирать не может и LINQ, это тебе Nemerle нужен.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 24.04.06 11:59
Оценка:
Здравствуйте, Дарней, Вы писали:

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


Отказ от ООП в данном случае условие необходимое, но не достаточное. Накосячить можно и без ООП без проблем, но с ООП это значительно проще. И при чём тут вообще инетные протоколы? Что же тебя всё время куда-то в сторону тянет.

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


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

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


Мне почему-то понять его слова труда не представляет

IT>>Что "всё"? В случае с объектами "всё" — это их состояние. Что ты подразумеваешь под "всё" в случае отказа от объектов?


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


А вот не надо нам тут психовать, если аргументы закончились?
Я уже на этот вопрос отвечал. В ООП эта проблема перманентна по определению. То что её можно успешно перетащить в другие подходы, так с этим никто не спорит. Только вот можно этого и не делать, правда?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.04.06 12:13
Оценка:
Здравствуйте, GlebZ, Вы писали:
S>>Это, извини, смотря какая ОБД. Если мы храним коллекцию учеников в виде коллекционного свойства ("внутри" объекта школы), то без инстанцирования ничего не выйдет.
GZ>Ну, если мы сравниваем системы по достаточно качественным образцам(в реляционке, де факто, это Oracle и MSSQL), то стоит и в OODB брать именно качественные образцы(для меня это Versant и GemStone/S).
Ок, давай посмотрим на GemStone. Как у них записывается вышеупомянутый запрос?
S>>В том-то и дело. Сетевые и иерархические СУБД слили в историческом плане именно потому, что оптимизировали одни запросы в ущерб другим. Умение RDBMS адаптироваться к максимально широкому классу запросов и обеспечило их успех.
GZ>Только вот не надо мешать OODB и другие виды баз. Хотя данная проблема для OODB существует.
Повторюсь: в данном контексте никакие ОО-специфичные свойства не рассматриваются. Все, о чем идет речь — навигация супротив запросов.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 24.04.06 12:21
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Нет, я назову это днем.

Как угодно...

Д>Ты уж определись, нужно тебе менять функционал или нет.

Нужно.

Д> Если нужно, то без изменения кода ты все равно никуда не денешься

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

Д> , и неважно, где он лежит — в базе или вне её.

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

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

В молоко...

Д>Если данные где-то хранятся, то только для того, чтобы их обрабатывать.

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

Д> А просто БД с наглухо закрытыми входами и выходами — это из раздела розовых мечтаний DBA

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

Д>При том, что это средства эмуляции инкапсуляции данных.

Не инкапсуляции, а декомпозиции, это разные вещи...

Д>Ну так что, много ты баз без них видел?

Без триггеров, кстати, очень много (это, к слову, довольно вредная конструкция), а sp — обычный код, которому пофигу где находиться, так что это не верная аналогия.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 12:26
Оценка:
Здравствуйте, IT, Вы писали:

IT>Отказ от ООП в данном случае условие необходимое, но не достаточное.


Необходимое — почему?

IT>Накосячить можно и без ООП без проблем, но с ООП это значительно проще.


Опять таки — почему?

IT>И при чём тут вообще инетные протоколы? Что же тебя всё время куда-то в сторону тянет.


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

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


возможно. Но есть и другие варианты, во всяком случае их можно придумать. Не понимаю я людей, которые при виде попыток придумать что-то новое сразу сразу начинают хаять — такого не бывает, и никогда не будет. Скромнее надо быть! (C) Code Complete
Шуклин может быть в чем-то и ошибается, но он хотя бы пытается придумать что-то новое. В отличие от.
А кстати, в какое другое место переносит проблему такой подход?

IT>А вот не надо нам тут психовать, если аргументы закончились?


упаси боже. Я просто спросил, достаточно ли я пояснил или нужна еще информация.

IT>Я уже на этот вопрос отвечал. В ООП эта проблема перманентна по определению. То что её можно успешно перетащить в другие подходы, так с этим никто не спорит. Только вот можно этого и не делать, правда?


То есть ты хочешь сказать, что при отказе от объектов зависимости между данными сами собой исчезнут, как по мановению волшебной палочки? Час от часу не легче
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 24.04.06 12:29
Оценка:
GlebZ wrote:
> C>А _зачем_ нам каждый наследник в отдельности? Обычно требуется работа
> C>или с отдельными классами или только с базовыми классами, в обоих
> C>случаях отдельные запросы не нужны.
> Что значит с базовыми? Один из больших недостатков OODB и ORM —
> избыточность чтения. Экземпляр должен быть загружен полностью, иначе им
> пользоваться нельзя(в принципе конечно можно и наполовину, но подобных
> реализаций в контексте ORM я не видел. Очевидно что слишком сложная
> будет реализация самого объекта).
Ну возьмем пример:
java.util.List lst=getSomeList();
Iterator it=lst.iterate();
while(it.hasNext())
{
    SomeObject obj=(SomeObject)it.next();
    //...
}


То есть нас в данном случае интересуют только данные объекта SomeObject.
Как это транслируется на RBD я уже показал.

>> > Внимательней. Получить документы лежащие в папке. Я нигде не писал что

>> > документы должны быть определенного типа. Такой задачи не стоит.
> C>А я получил все документы, лежащие в папке. Можно делать с ними дальше
> C>что угодно, например, сделать JOIN по всем типам и вывести результат.
> Ты не получил все документы лежащие в папке. Каждый документ — это
> разный набор аттрибут.
А зачем мне сразу загружать все атрибуты? Надо будет — загрузим...

Обычный сценарий — нужно взять какую-то _общую_ часть всех документов
(например, выбрать все названия документов) или произвести какую-то
операцию над каким-то типом документа.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 12:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Методы нельзя, только лямбды.

GZ>>А из лямбд методы вызывать нельзя?
AVK>Можно, но expression tree ты по им не получишь.
May be. Но в принципе, можно будет дописать. Самое главное, чтобы код нормально укладывался в дерево.

GZ>>>> из них можно будет строить вполне селективные вещи. Sinclair кажется именно этим занимался.

AVK>>>Это можно делать и в Hibernate.
GZ>>Hibernate может разбирать программный код?
AVK>Собственный QL может. А произвольный код программы рабирать не может и LINQ, это тебе Nemerle нужен.
Ессно, не произвольный код. Для того чтобы построить expression tree — код должен быть функциональным.

Главное — сделан вполне конкретный ход который открывает новые перспективы.
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 12:53
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну возьмем пример:

C>
C>java.util.List lst=getSomeList();
C>Iterator it=lst.iterate();
C>while(it.hasNext())
C>{
C>    SomeObject obj=(SomeObject)it.next();
C>    //...
C>}
C>

C>То есть нас в данном случае интересуют только данные объекта SomeObject.
C> Как это транслируется на RBD я уже показал.
Что-то я тебя не понял. То есть, ты хочешь сказать что если SomeObject абстрактный, то ява умеет работать с ним не инстанцируя полный экземпляр?

C>Обычный сценарий — нужно взять какую-то _общую_ часть всех документов

C>(например, выбрать все названия документов) или произвести какую-то
C>операцию над каким-то типом документа.
Обычный сценарий для сервера приложений собрать все нужные данные, и переправить его на клиента. А клиент уже сам будет разбираться каким образом ему эти данные в каком ракурсе он будет обрабатывать. Сервер приложений обязан быть хорошим поставщиком данных.
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.04.06 12:55
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>Можно, но expression tree ты по им не получишь.

GZ>May be. Но в принципе, можно будет дописать.

Что дописать? Компилятор C# 3.0?

GZ>Самое главное, чтобы код нормально укладывался в дерево.


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

GZ>Главное — сделан вполне конкретный ход который открывает новые перспективы.


Еще раз — эти перспективы были открыты уже давно. Проблема не в парсере языка.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[29]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 13:06
Оценка:
Здравствуйте, IT, Вы писали:

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


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

IT>ЗЫ. Тебе Merle уже в пятом топике говорит, что пора завязывать, но ты всё никак не угомонишься и продолжаешь демонстрировать свою... мягко говоря, неосведомлённость в обсуждаемых вопросах. Давай лучше завязывать, ok?


Мягко говоря, ты тоже нарушаешь правила форума. Не к лицу это тебе, не находишь?
Что касается моей осведомленности, то меня мало интересует чье-то мнение о ней. Я всего лишь хочу получить наконец ответы на вопросы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[29]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 13:06
Оценка:
Здравствуйте, Merle, Вы писали:

M>Как угодно...


вот и чудно. Осталось только согласиться, что день и закат — это совершенно разные вещи.

M>В идеале денусь — я просто напишу новый код, при этом старый функционал будет работать со старым кодом, а новый с новым, по одним и тем же данным.


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

Д>> , и неважно, где он лежит — в базе или вне её.

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

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

Д>>Если данные где-то хранятся, то только для того, чтобы их обрабатывать.

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

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

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


ну приведи хоть один пример из практики, а? У меня от чистой теории уже мозги скрипят.

Д>>При том, что это средства эмуляции инкапсуляции данных.

M>Не инкапсуляции, а декомпозиции, это разные вещи...

каким интересно образом триггеры связаны с декомпозицией данных?

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


вот ты и сам сказал — пофиг, где находиться. Но обычно его пихают именно в базу данных, а не куда-то еще. Давай я еще вспомню про отсутствие какого-либо стандарта на SP, или ты сам?
Фактически, наличие таких конструкций и денормализации даных — это признаки того, что РБД в чистом виде не работает на реальных задачах. Можно еще вспомнить, что foreign constraint — это тоже привнесенный элемент, ничего подобного в изначальной теории РБД нет. Это потом уже реальность сказала своё веское слово, и жесткие связи таблиц ненавязчиво слямзили из сетевых БД.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 13:26
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Что дописать? Компилятор C# 3.0?

Зафигом. Во-первых, его самого не написали. Хотя бы по обещаниям, и том что в данный момент есть — небо и земля. Так что возможно они и сами такую шнягу сделают. У тебя документация на expression tree есть? А то мне приходится оперировать только догадками, что весьма нехорошо.
Во вторых, никто не мешает из методов возвращать функциональный тип. Скомпоновать из таких функционалов дерево, достаточно простая задача вручную. Хотя наверняка можно будет и стандартно. Поживем увидим.

GZ>>Самое главное, чтобы код нормально укладывался в дерево.

AVK>В дерево укладываются только лямбды. Это ничегонового по сравнению с Hibernate не дает, кроме интеграции системы типов языка и источника данных. В плане анализа кода возможности равноценны.
Вот в плане анализа кода, возможности не совсем равноценны. В случае лямбд, ты имеешь статически типизированный язык, и все инструменты для данного языка, вплоть до рефакторинга.

GZ>>Главное — сделан вполне конкретный ход который открывает новые перспективы.

AVK>Еще раз — эти перспективы были открыты уже давно. Проблема не в парсере языка.
Поясню еще. Для OODB весьма криминальным вопросом является инкапсуляция объектов. Для движка запросов приходится, либо не пользовать их, либо разбирать код и пытаться перевернуть в нужную, для обработки и оптимизации запросов, форму. И перевернуть не всегда возможно. Это одно из наиболее криминальных проблем активных OODB.
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.04.06 13:37
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>Что дописать? Компилятор C# 3.0?

GZ>Зафигом.

Не знаю. Ты ведь предлагаешь что то дописывать.

GZ> Во-первых, его самого не написали.


А как же революция в деле ООБД?

GZ> Хотя бы по обещаниям, и том что в данный момент есть — небо и земля. Так что возможно они и сами такую шнягу сделают.


Не сделают.
А самое главное, о чем ты все время забываешь — LINQ рассчитан на реляционную (или близкую к ней) модель данных (возьми хотя бы наличие JOIN).

GZ>Вот в плане анализа кода, возможности не совсем равноценны.


И чем AST запроса в Hibernate отличается в плане анализа от expression tree?

AVK>>Еще раз — эти перспективы были открыты уже давно. Проблема не в парсере языка.

GZ>Поясню еще. Для OODB весьма криминальным вопросом является инкапсуляция объектов. Для движка запросов приходится, либо не пользовать их, либо разбирать код и пытаться перевернуть в нужную, для обработки и оптимизации запросов, форму.

IL для этого не менее удовен, нежели expression tree.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[30]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 24.04.06 13:47
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Осталось только согласиться, что день и закат — это совершенно разные вещи.

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

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

Аккуратно писать новый код.

Д>ну изменится какой-то код. Почему ты выставляешь это как конец всего человечества?

Что за тяга к передергиванию? Я не выставляю это как конец всего человечества. Необходимость менять код, когда можно было спроектировать так, чтобы пришлось только дописывать, я выставляю как design flaw.

Д>Те же хранимые процедуры пачками меняют, хотя как раз это очень часто приводит к неприятным последствиям.

Как тебе совершенно верно заметил Игорь, написать плохо можно всегда, а вот написать хорошо — нет. В данном случае использование ОО, резко снижает вероятность "написать хорошо"

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

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

Д> У меня от чистой теории уже мозги скрипят.

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

Д>каким интересно образом триггеры связаны с декомпозицией данных?

А с "инкапсуляцией" каким?

Д> Но обычно его пихают именно в базу данных, а не куда-то еще.

Угу, потому что поддерживать проще. И процедуры на ОО языках тоже создавать теперь практически во всякой базе можно, только вот база объектной от этого не становится и данные по прежнему лежат в плоском виде, доступные посредством SQL...

Д>Фактически, наличие таких конструкций и денормализации даных — это признаки того, что РБД в чистом виде не работает на реальных задачах.

РДБ в чистом виде никто в глаза не видел, но тем не менее даже то что есть, с реальными задачами хранения данных, в подавляющем ольшинстве случаев, справляется заметно лучше чем ООБД и другие альтернативные подходы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 13:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ок, давай посмотрим на GemStone. Как у них записывается вышеупомянутый запрос?

Без документашки не напишу. Но, по моему, ты намекаешь на то, что в запросе(точнее кода) отображается последовательность выполнения?

GZ>>Только вот не надо мешать OODB и другие виды баз. Хотя данная проблема для OODB существует.

S>Повторюсь: в данном контексте никакие ОО-специфичные свойства не рассматриваются. Все, о чем идет речь — навигация супротив запросов.
Когда OODB рассматривают только в данном контексте, мне это как-то непонятно. По некоторым ублюдкам, которые умеют работать только через навигацию, судить о всех ООDB, все равно что судить о реляционке по Clarion.
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: Cyberax Марс  
Дата: 24.04.06 14:20
Оценка:
GlebZ wrote:
> C>То есть нас в данном случае интересуют только данные объекта SomeObject.
> C> Как это транслируется на RBD я уже показал.
> Что-то я тебя не понял. То есть, ты хочешь сказать что если SomeObject
> абстрактный, то ява умеет работать с ним не инстанцируя полный экземпляр?
Это я к тому, что нам _не_ _нужен_ полный экземпляр из всех возможных
свойств в большинстве случаев.

> C>Обычный сценарий — нужно взять какую-то _общую_ часть всех документов

> C>(например, выбрать все названия документов) или произвести какую-то
> C>операцию над каким-то типом документа.
> Обычный сценарий для сервера приложений собрать все нужные данные, и
> переправить его на клиента. А клиент уже сам будет разбираться каким
> образом ему эти данные в каком ракурсе он будет обрабатывать. Сервер
> приложений обязан быть хорошим поставщиком данных.
Это, простите, не обычный сценарий, и уж тем более не для сервера
приложений.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 24.04.06 14:33
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Отказ от ООП в данном случае условие необходимое, но не достаточное.

Д>Необходимое — почему?

Ты правда не понимаешь или прикидываешься? Мне этот вопрос уже надоело мусолить.
Состояние объекта — неотъемлемая часть ООП. Соответственно, если мы не хотим связываться с синхронизацией распределённого состояния, то распределённый ООП неприемлим.

IT>>Накосячить можно и без ООП без проблем, но с ООП это значительно проще.

Д>Опять таки — почему?

По той же причине. Отказ от ООП не означает автоматически отказ от синхронизации состояния.

IT>>И при чём тут вообще инетные протоколы? Что же тебя всё время куда-то в сторону тянет.

Д>ты же сам приводил интернет в качестве глобальной распределенной системы. Не забыл еще?

Я не понимаю при чём тут интернетные протоколы и состояние объектов

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


Д>возможно. Но есть и другие варианты, во всяком случае их можно придумать. Не понимаю я людей, которые при виде попыток придумать что-то новое сразу сразу начинают хаять — такого не бывает, и никогда не будет. Скромнее надо быть! (C) Code Complete


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

А новое нами принимается на ура, если это действительно новое. На этот счёт можешь не переживать.

Д>Шуклин может быть в чем-то и ошибается, но он хотя бы пытается придумать что-то новое. В отличие от.


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

Д>А кстати, в какое другое место переносит проблему такой подход?


Ну хотя бы проблемы связанные с отсутствием строгой типизации.

Д>То есть ты хочешь сказать, что при отказе от объектов зависимости между данными сами собой исчезнут, как по мановению волшебной палочки? Час от часу не легче


Вот опять ты за своё. Тебе ещё раз повторить, что бывают вещи необходимые, а бывают недостаточные?
Если нам не помогут, то мы тоже никого не пощадим.
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 14:36
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Что дописать? Компилятор C# 3.0?

GZ>>Зафигом.
AVK>Не знаю. Ты ведь предлагаешь что то дописывать.
Да я пока не знаю что есть и что будет. Нету документации. Может и дописывать. А может и нет.

GZ>> Во-первых, его самого не написали.

AVK>А как же революция в деле ООБД?
Я ее отменил. Лучше съезжу на рыбалку.

GZ>> Хотя бы по обещаниям, и том что в данный момент есть — небо и земля. Так что возможно они и сами такую шнягу сделают.

AVK>Не сделают.
AVK>А самое главное, о чем ты все время забываешь — LINQ рассчитан на реляционную (или близкую к ней) модель данных (возьми хотя бы наличие JOIN).
Андрей, похоже ты не совсем верно понимаешь что такое OODB. Можно пояснить на пальцах. Берем DLinq(вместе со всеми обещаниями). Убираем операцию проекции(все остальные операции остаются). Делаем хранилище чтобы оптимально работало не только по запросам, но и навигационно. Ставим на все таблицы синтаксический глобально уникальный ключ. И получаем готовую пассивную объектно-ориентированную базу данных.

GZ>>Поясню еще. Для OODB весьма криминальным вопросом является инкапсуляция объектов. Для движка запросов приходится, либо не пользовать их, либо разбирать код и пытаться перевернуть в нужную, для обработки и оптимизации запросов, форму.

AVK>IL для этого не менее удовен, нежели expression tree.
Не уверен. Надо у Sinclair спросить.
Re[31]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 14:42
Оценка:
Здравствуйте, Merle, Вы писали:

M>И я нигде не говорил, что мое мнение единственно верное, но вот когда ты начал мои слова перевирать, пришлось тебя тыкать носом в каждое место где ты переврал.


Во первых, я твои слова не перевирал. Во вторых, ты так и не смог толком ответить ни на один вопрос (список прилагается)
Если это сейчас называется "натыкать носом", то мне остается только отправляться в монастырь, подальше от безумной мирской суеты. (в женский, конечно... )
Итак, список:
1. Ты согласен с тем, что ограничения одной реализации ООП не говорят о том, что их будут повторять в обязательном порядке во всех последующих реализациях?
2. Если ты таки считаешь, что будут — объясни, почму нельзя сделать лучше.
3. Что наличие и развитие новых идей говорит о том, что "технология не движется к закату"?

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

M>Аккуратно писать новый код.

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

M>Что за тяга к передергиванию? Я не выставляю это как конец всего человечества. Необходимость менять код, когда можно было спроектировать так, чтобы пришлось только дописывать, я выставляю как design flaw.


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

M>Как тебе совершенно верно заметил Игорь, написать плохо можно всегда, а вот написать хорошо — нет. В данном случае использование ОО, резко снижает вероятность "написать хорошо"


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

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

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

вот даже как? Любопытно. То есть у объекта были данные, доступ к которым был закрыт из сображений дизайна, а потом их вдруг решили открыть?
Упреждая вопрос — это единственный реальный сценарий, при котором нужно добавлять к объекту геттер. Если ты видишь другие возможные сценарии — расскажи.

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


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

Д>>каким интересно образом триггеры связаны с декомпозицией данных?

M>А с "инкапсуляцией" каким?

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

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


угу. тяжкое наследие прошлого....

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


это не доказывает, что так будет всегда. Я так понимаю, это утверждение ты опять проигнорируешь и скажешь, что мне приходится объяснять по десять раз?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 15:00
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ты правда не понимаешь или прикидываешься? Мне этот вопрос уже надоело мусолить.

IT>Состояние объекта — неотъемлемая часть ООП. Соответственно, если мы не хотим связываться с синхронизацией распределённого состояния, то распределённый ООП неприемлим.

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

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

IT>По той же причине. Отказ от ООП не означает автоматически отказ от синхронизации состояния.


также как и его наличие не создает эту проблему только фактом своего присутстия. Весь вопрос в дизайне системы, а ОО или не ОО — дело вообще десятое, не так ли?

IT>Я не понимаю при чём тут интернетные протоколы и состояние объектов


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

IT>А новое нами принимается на ура, если это действительно новое. На этот счёт можешь не переживать.


ну что ж, это утешает Главное, не выплеснуть с водой младенца.

IT>Ну хотя бы проблемы связанные с отсутствием строгой типизации.


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

Д>>То есть ты хочешь сказать, что при отказе от объектов зависимости между данными сами собой исчезнут, как по мановению волшебной палочки? Час от часу не легче


IT>Вот опять ты за своё. Тебе ещё раз повторить, что бывают вещи необходимые, а бывают недостаточные?


давай лучше я еще раз повторю, что среди пунктов "инкапсуляция, расширение, полиморфизм" нет пункта "обязательно иметь сосояние"?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[31]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 15:06
Оценка:
Здравствуйте, IT, Вы писали:

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


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

IT>Вот видишь до чего порой доводят несознательные посетители


спокойнее надо быть.....

IT>Ты их получаешь, только почему-то не хочешь принимать. Создаётся впечатление, что у тебя есть свои ответы, с которыми наши не согласуются. Но вместо того чтобы выразить своё мнение и прояснить ситуацию, ты пытаешься запутать других. Про состояние объектов я тебе уже раз пять говорил, но ты либо беспросветно тупишь, в чём я лично очень сильно сомневаюсь, либо откровенно над нами издеваешься. В любом случае, водить хороводы вокруг этой темы лично мне уже надоело.


просто из интереса — укажи свой первый постинг, где ты явно сказал по состояние?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.04.06 15:10
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>Не знаю. Ты ведь предлагаешь что то дописывать.

GZ>Да я пока не знаю что есть и что будет. Нету документации. Может и дописывать. А может и нет.

Это мода что ли такая пошла?

Но в принципе, можно будет дописать.

Твои слова. Вот мне и интересно что ты там собрался дописывать.

AVK>>А самое главное, о чем ты все время забываешь — LINQ рассчитан на реляционную (или близкую к ней) модель данных (возьми хотя бы наличие JOIN).

GZ>Андрей, похоже ты не совсем верно понимаешь что такое OODB.

А может ты?

GZ> Можно пояснить на пальцах. Берем DLinq(вместе со всеми обещаниями). Убираем операцию проекции(все остальные операции остаются).


Не уберешь ты из LINQ операцию проекции так чтобы сохранилась возможность писать декларативные запросы. Слово select опустить нельзя, см. грамматику.

AVK>>IL для этого не менее удовен, нежели expression tree.

GZ>Не уверен. Надо у Sinclair спросить.

Спроси.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[31]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 24.04.06 15:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Это заблуждение.

S>Реляционные данные — это записи о фактах. Тем они и хороши, что факты никак не меняются со временем. Десятого мая 1966 года Дж.Виллис купил в бакалейном отделе молока на 0.52 доллара. Алгоритмы обработки — вещь эфемерная. В 1966 году просто никто не знал, что делать со всеми этими Дж.Виллисами. Потом были придуманы всякие отчеты с группировками для того, чтобы сэйлзы из сети Таргет заявляли "нам нужно увеличивать расфасовку молочных продуктов, потому что на мелкую падает спрос". И показывали различные тренды.
S>Уже потом вопрос "а что с этим делать" стали называть Data Mining, защищать на этом диссертации и делать большие деньги.
S>От этого факты не перестали быть фактами.
S>Хранимые процедуры, триггеры — это все фуфло. Это попытка научить RDBMS вести себя как сервер приложений. В то время, как ее изначальная роль — только регистрировать факты.
S>Именно поэтому инкапсуляция поведения в DBMS — это путь к потере вот этой независимой составляющей. Никто не говорит о том, что это вообще тупик. Но некоторые данные про урожай риса пережили падение пирамид; в то время, как от методов их обработки ничего не осталось.

заблуждение — это валить задачи OLAP и OLTP в одну кучу. Никому не нужно решать "задачу хранения фактов вообще" одним на всех универсальным образом, всех интересует только решение их частных задач.
Данные OLAP очень редко (фактически — никогда) не меняются, их просто перегоняют в готовом виде из базы OLTP небольшими порциями через регулярные промежутки времени. Зато по этим данным часто гоняют различные статистические обработки, которые, действительно, часто меняются.
Здесь, действительно, применение ООП мало чем поможет. Фактически, из всех методов объектов будут вызываться только геттеры. С другой стороны, оно здесь и не помешает.
Совсем другое дело — OLTP, где данные меняются очень часто, а читаются сравнительно редко. Как раз здесь применение ООП могло бы дать неплохие бенефиты, поскольку задача сохранения непротиворечивости данных стоит здесь очень остро. Ограничение доступа к данным с помощью инкапсуляции должно неплохо решать эти проблемы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 16:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:


AVK>Это мода что ли такая пошла?

AVK>

Но в принципе, можно будет дописать.

AVK>Твои слова. Вот мне и интересно что ты там собрался дописывать.
"Можно будет" и "надо" — у этих слов разные смыслы. Это в принципе значит что не уверен в своих словах. А фактически, я хотел бы получить следующее. Практически всегда для больших приложений приходится инкапсулировать операции с хранилищем в некотором DAL слое. И соответсвенно, в нем существует объект который отвечает за работу с хранилищем, допустим называется Bla_blaDataAccessor. Данный объект также инкапсулирует в себе custom предикаты (например функции возвращающие Expression<Func<bla>> или IEnumerable, extension не extension пока оставим все это оставим открытым — частности). Чтобы запрос выглядел не так:
var x = a.Where(a=>log_delete==true)

a так
var x=a.IsLogDeleted(true);

Все инкапсулировано, и выглядит действительно прилично.
Такое сделать легко без дописки
Но вот что еще не менее хотелось бы:
bla-bla IsLogDeleted(IEnumerable<T> t)
{
    return t => GetStatus(t)==2;
}

Или даже пойти дальше.
bla-bla IsLogDeleted(bla-bla)
{  
    return t.SelectMany(c=>c.Childs).IsLogDeleted.Count()>0
}

Вобщем для того, чтобы получить вразумительный от меня ответ, мне нужно посидеть подумать. Дерево здесь, не дерево. И что вообще можно сделать по максимуму. Но сейчас времени нет. Загрузка на работе. На сложные вопросы не отвечаю, извиняйте.

AVK>Не уберешь ты из LINQ операцию проекции так чтобы сохранилась возможность писать декларативные запросы. Слово select опустить нельзя, см. грамматику.

Поясняю
from x in a select x //проекции нету
from x in a select new {x.field1, x.field2} //проекция есть

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

AVK>>>IL для этого не менее удовен, нежели expression tree.

GZ>>Не уверен. Надо у Sinclair спросить.

AVK>Спроси.

Спрашиваю.
Уважаемый и ужастный Антон. Если вы хотя бы одним глазом заметили сии непотребные буквы на своем величайшем многопиксельном экране, прошу вас ответить. Что легче, парсить expression tree, или IL код? Заранее извиняюсь за беспокойство.
Вот, спросил.
Re[32]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 24.04.06 17:31
Оценка:
Здравствуйте, Дарней, Вы писали:

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


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

Д>просто из интереса — укажи свой первый постинг, где ты явно сказал по состояние?


Я помню что ли? Может быть здесь
Автор: IT
Дата: 22.04.06
.
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 17:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Это я к тому, что нам _не_ _нужен_ полный экземпляр из всех возможных

C>свойств в большинстве случаев.
Кто-бы спорил.

C>Это, простите, не обычный сценарий, и уж тем более не для сервера

C>приложений.
Это вполне обычный сценарий для сервера приложений, мало того, из жизни.
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 24.04.06 18:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Непонятно, во что именно это должно выродиться. Современные RDBMS построены на том, что

S>б) есть набор низкоуровневых операций, которые выполняются очень эффективно (а их очень мало — table scan, index scan, index seek)
Это весь набор низкоуровневых операций современной RDBMS?
Re[32]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 24.04.06 19:56
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Во первых, я твои слова не перевирал.

Перевирал и много раз, более того ты опять сделал это в этом же сообщении.

Д> Во вторых, ты так и не смог толком ответить ни на один вопрос (список прилагается)

На все твои вопросы я ответил и ни по одному разу, я не виноват, что ты игнорируешь ответы.

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

Да, монашкам голову дурить проще...

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

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

Д>2. Если ты таки считаешь, что будут — объясни, почму нельзя сделать лучше.

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

Д>3. Что наличие и развитие новых идей говорит о том, что "технология не движется к закату"?

Где они, эти новые идеи? Все новые идеи далеко выходят за рамки ООП...

Д>а старые данные, которые навводили юзеры, куда девать?

Зачем их куда-то девать? Данные должны храниться.

Д>И продолжают вводить,

И пусть продолжают, в чем проблема?

Д> Вседа находятся новые требования клиентов, которые требуют изменения старого функционала — не расширения, а именно изменения.

И поэтому надо делать систему так, чтобы любое требование клиента приводило к изменению? Гениально.

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

Примем это громкое заявление как данность. Тогда в объектном хранилище ты еще и переписываешь данные, вместе со своим кодом, они же у тебя оборудованы методами доступа от которых их не оторвать. А следовательно, как минимум, существенно выше риск накосячить и последствия косяка серьезнее. Действительно подходящий инструмент для серьезных систем.

Д>Поэтому любой, кто утверждает, что пишет сразу и навсегда — просто наглый врун.

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

Д>И я сразу же отстану.

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

Д>вот даже как? Любопытно. То есть у объекта были данные, доступ к которым был закрыт из сображений дизайна, а потом их вдруг решили открыть?

Угу, помнишь свое громкое заявление парой абзацев выше?

Д>нужно сказать один раз, но по нормальному.

По нормальному — это так чтобы совпало с твоим мнением? Ну извини, не пойдет...

Д>В частности, перестать игнорировать неудобные вопросы.

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

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

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

Д>угу. тяжкое наследие прошлого....

Да-да, уже лет 15 как тяжкое наследие прошлого, но что-то все потуги ОО на этой почве пока делу не помогли, так и остается мальчик подающий надежды..

Д>это не доказывает, что так будет всегда.

А где я утверждал, что доказывает? Это лишь доказывает, что ООП здесь скорее всего уже не конкурент.

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

Скажу. Не надоело?
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.04.06 01:11
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>Это весь набор низкоуровневых операций современной RDBMS?
А что, я что-то пропустил? Неужели bookmark lookup?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: EXO Россия http://www.az.inural.ru
Дата: 25.04.06 03:35
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>Обычный сценарий для сервера приложений собрать все нужные данные, и переправить его на клиента. А клиент уже сам будет разбираться каким образом ему эти данные в каком ракурсе он будет обрабатывать. Сервер приложений обязан быть хорошим поставщиком данных.

Нет.
Это тогда не сервер приложений...
Хотя у нас порой и любят называть домашнего кота "Барсиком", но барсом он от этого не становится.
Задача клиента, в техуровевой архитектуре — отображать.
Удобно, качественно, в разных вариантах — но только отображать.
В двухуровневой (клиент-северной) архитектуре, все так, как ты говоришь. Но сервер в ней — не "сервер приложений", а действительно "поставщик данных". И нет большой разницы из скольких "компанент" он состоит: только из сервера БД, или там есть еще некий "прикладной север". Этот "прикладной сервер" может превратить универсальный сервер БД в некоторый "специализированный севе БД". Но севером приложеий он от этого не станет. Сервер приложений должен обрабатывать не запросы на "поставку данных", а логику приложения. То есть то самое: "разбираться каким образом ему эти данные в каком ракурсе он будет обрабатывать".
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 25.04.06 07:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

GZ>>Проекция подразумевается как реляционная операция. Проекция — это трансформация типа. Что майнстримовые языки очень не любят.

S>Не, теперь у нас есть C#3, и там с этим почти все в порядке. Мне как раз нравится проекция, поскольку она позволяет четко разделить фазы выполнения запроса и использования результатов. Т.е. для того, чтобы получить ссылку на Product из OrderItem, я должен сразу же в запросе написать
S>
S>from OrderItem o select o, o.Product
S>

S>Попытка обратиться к o.Product в результатах — ошибка. (Причины — просты: есть риск, что к моменту dereference мы выйдем из контекста той транзакции, в которой выполнялся селект).
1. Сомневаюсь что нужно делать Lazy Loading. В данном случае лучше загружать граф. И пользователю дать решать, что ему нужно, граф — или потом он подгрузит запросом.
2. Есть некоторая разница между Select(o).Including(o.Product) и Select(new {o, o.Product}). Первый возвращает дерево объектов, второй возвращает новый тип. И к тому-же плоский тип(у меня даже мыслей нет как работать с многомерными отношениями в движке запросов). В первом случае — два запроса(можно даже воспользоваться предположением что использовав результат предыдущего запроса, мы получим оптимальный план), во втором случае — это операция проекции полей из двух отношений в одно результирующее отношение.
3. При этом, неплохо иметь ввиду следующее. Тот же DLinq не предоставляет средств обновления для объектов полученных в результате проекции. Проблема в следующем. В случае если мы не пользуемся проекцией, вся нужная информация лежит в метаданных типа. В случае генеренного типа, такой информации мы не имеем. А также. В результате проекции мы теряем идентификационную информацию об источнике получения типа(типа теже PK). Соответсвенно, мы не сможем разложить его автоматизированно по таблицам.
S>А еще лучше сразу написать
S>
S>from OrderItem o select o.Amount, o.Product.FullName
S>

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

S>Насколько я успел поверхностно разобраться — одна фигня. Потому что в лямбде я могу вставить вызов метода/свойства, и упс. Парни из Dlinq просто обошлись, AFAIK, набором готовых эвристик для трансляции известного кода. Типа "a".Length превращается в Len('a') и еще некоторый более-менее убогий набор функционала.

S>По-хорошему, надо делать так же, как сиквел разбирает UDF: лезть унутрь этого метода, смотреть в его MSIL и т.п. В частности, убеждаться в том, что метод не меняет состояние объекта (это сразу InvalidOperationException), проверять, не получилось ли случайно так, что можно воспользоваться индексом, и т.п. Иначе банальный селект, где сравнивается свойство с константой, будет сливать, т.к. индекс построен по полю. Так что от IL можно уйти только очень недалеко и ненадолго.
Шпасибо.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[33]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 25.04.06 07:23
Оценка:
Здравствуйте, Merle, Вы писали:

<демагогия поскипана>

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


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

То есть ты считаешь что фундаментальные проблемы, присущие "ООП вообще", всё-таки есть. Осталось только понять, почему их нельзя решить никакими силами, и тогда мы наконец придем к консенсусу

Д>>2. Если ты таки считаешь, что будут — объясни, почму нельзя сделать лучше.

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

тебе напомнить, сколько времени прошло с публикации первой книги по реляционной теории и по сегодняшний день?
детальным списком косяков ты кстати так и не поделился. Это та самая "проблема" с неожиданно понадобившимися геттерами, которые почему-то должны устанавливать данные, что ли?

Д>>3. Что наличие и развитие новых идей говорит о том, что "технология не движется к закату"?

M>Где они, эти новые идеи? Все новые идеи далеко выходят за рамки ООП...

Какие конкретно новые идеи, которые куда-то далеко выходят?

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

Д>>а старые данные, которые навводили юзеры, куда девать?

M>Зачем их куда-то девать? Данные должны храниться.

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

Д>> Вседа находятся новые требования клиентов, которые требуют изменения старого функционала — не расширения, а именно изменения.

M>И поэтому надо делать систему так, чтобы любое требование клиента приводило к изменению? Гениально.

если нужно изменить функциональность, то код ее реализации надо менять. Логично, правда?
Если наше любимое правительство говорит, что с нового года НДС высчитывается по новым принципам, то код процедуры расчета НДС надо менять, и это потенциально может "всё сломать". И никаким "расширением" ты здесь не обойдешься.

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


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

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


Крайне редко можно "просто дописывать", ничего не меняя в существующем коде.

Д>>вот даже как? Любопытно. То есть у объекта были данные, доступ к которым был закрыт из сображений дизайна, а потом их вдруг решили открыть?

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

и что?

Д>>В частности, перестать игнорировать неудобные вопросы.

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

пока что вся аргументация сводилась к утверждениям "учись мыслить абстрактно" и "читай до просветления"

M>Если есть что возразить — возражай, но по существу, а не занимайся лингвистическими упражнениями.


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

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


обладает способностью — да, но тут всё зависит от доброй воли программистов. Если руководитель проекта написал в почтовую рассылку "писать в таблицу X только через хранимую процедуру, чтобы нормально обновлялись агрегатные значения в таблице Y", а кодер Вася Пупкин не читает рассылку и всё равно напишет insert into X, то всё согласование данных пойдет лесом.
Инкапсуляция данных дает возможность гарантировать соблюдение этого правила, запрещая прямой доступ к данным, вместо того чтобы решать программные задачи административными средствами.

Д>>угу. тяжкое наследие прошлого....

M>Да-да, уже лет 15 как тяжкое наследие прошлого, но что-то все потуги ОО на этой почве пока делу не помогли, так и остается мальчик подающий надежды..

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

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

M>Скажу. Не надоело?

тогда уж отвечай полнее — не "скажу", а "проигнорирую и скажу".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[33]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 25.04.06 07:29
Оценка:
Здравствуйте, IT, Вы писали:

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


IT>Не надо додумывать и досказывать за меня. Я такого не говорил. Прочитать и экспортировать — это не мои проблемы. Я могу хранить эти данные хоть на бумаге.


Зато я сказал то, про что ты забыл или не захотел рассказывать.
Мне так показалось, что мы обсуждали задачу как таковую, а не твою роль в ней. В рамках задачи, если эти данные есть, то их надо экспортировать, чтобы их мог прочитать получатель. А твоя это задача или нет — меня не волнует.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 25.04.06 07:45
Оценка:
Здравствуйте, IT, Вы писали:

IT>Удивительнее то, что мне пришлось это повторять так много раз.


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

IT>Вот ты опять пытаешься увильнуть куда-то в сторону? Ну при чём тут CLOS? ОО в CLOS и OOP, обсуждаемый в контексте топика объединяет только наличие и там и там двух букв OO. Видимо либо у тех либо у других не хватило фантазии придумать другой термин.


только давай не будем играться с терминами? Авторы называют свою реализацию ООП — и там действительно есть те вещи, которые обычно связывают с ООП. Значит, это и есть ООП. Если твое понимание ООП отличается от общепринятого, то хотя бы не надо пытаться делать это аргументом в споре.

IT>В традиционном ООП — состояние вещь перманентная.


а где про это написано? Вот прямо такими словами? Я еще не видел ни в одной книге "писать объекты без изменяемого состояния запрещено третьей сурой Корана, и все нарушители этого принципа будут гореть в аду"

IT>Ты же только что утверждал, что в CLOS не состояния вообще


точнее говоря, его обычно нет. При желании в Лиспе можно использовать состояние, но это отклонение от "линии партии"

IT>Строя архитектуру на базе распределённого ООП ты не можешь этого избежать. И я пытаюсь тебе это сказать уже в десятый раз. Ты же мне в качестве контаргументов пытаешься доказать, что и без ООП можно накосячить. Можно, ещё раз тебе говорю. Да, можно, легко. Вот только в случае ООП у тебя не будет другого выхода.


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

IT>Таже фигня.


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

IT>Это всё нетрадиционные формы ориентации ООП.


кто сказал, что они нетрадиционные?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 08:11
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>Твои слова. Вот мне и интересно что ты там собрался дописывать.

GZ>"Можно будет" и "надо" — у этих слов разные смыслы.

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

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


Да.

GZ> И соответсвенно, в нем существует объект который отвечает за работу с хранилищем, допустим называется Bla_blaDataAccessor.


Нет. Далеко не всегда такой объект есть.

GZ> Данный объект также инкапсулирует в себе custom предикаты (например функции возвращающие Expression<Func<bla>> или IEnumerable, extension не extension пока оставим все это оставим открытым — частности). Чтобы запрос выглядел не так:

GZ>
GZ>var x = a.Where(a=>log_delete==true)
GZ>

GZ>a так
GZ>
GZ>var x=a.IsLogDeleted(true);
GZ>


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

GZ>Но вот что еще не менее хотелось бы:

GZ>
GZ>bla-bla IsLogDeleted(IEnumerable<T> t)
GZ>{
GZ>    return t => GetStatus(t)==2;
GZ>}
GZ>

GZ>Или даже пойти дальше.
GZ>
GZ>bla-bla IsLogDeleted(bla-bla)
GZ>{  
GZ>    return t.SelectMany(c=>c.Childs).IsLogDeleted.Count()>0
GZ>}
GZ>


Ничего выдающегося я здесь не увидел. Для меня максимально логичным будет такой вариант:
var x = a.Where(a=>a.LogDelete == true)

И никакого засирания публичного интерфейса, максимальная гибкость и читаемость.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 08:11
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>3. При этом, неплохо иметь ввиду следующее. Тот же DLinq не предоставляет средств обновления для объектов полученных в результате проекции.


Забавный ты мужик, однако. Сначала навязываешь LINQ неестественные ему модели, а потом жалуешься, что он для этого плохо подходит. Я тебе уже неоднократно писал — LINQ как таковой не предназначен для построения ООБД и O/R мепперов. Как только ты это поймешь, все надуманные проблемы LINQ сразу же исчезнут.

GZ> Проблема в следующем. В случае если мы не пользуемся проекцией, вся нужная информация лежит в метаданных типа. В случае генеренного типа, такой информации мы не имеем. А также. В результате проекции мы теряем идентификационную информацию об источнике получения типа(типа теже PK). Соответсвенно, мы не сможем разложить его автоматизированно по таблицам.


Ты когда нибудь видел в SQL-серверах возможность править результат select?
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.04.06 08:36
Оценка:
Здравствуйте, GlebZ, Вы писали:
S>>Попытка обратиться к o.Product в результатах — ошибка. (Причины — просты: есть риск, что к моменту dereference мы выйдем из контекста той транзакции, в которой выполнялся селект).
GZ>1. Сомневаюсь что нужно делать Lazy Loading.
Вот я и говорю — никакой ленивости, только явная загрузка.
GZ>В данном случае лучше загружать граф.
А вот этого не надо. Плохо построенный граф притащит на клиента всю базу. Есть, конечно, у некоторых членоудлинители в виде чего-то типа PreloadNetwork(IEnumerable collection, int depth), в надежде на то, что прикладник догадается скормить разумный depth. А дальше — снова lazy. Не, я против. Поднимаем только то, что сказали. Никаких графов.
GZ>2. Есть некоторая разница между Select(o).Including(o.Product) и Select(new {o, o.Product}). Первый возвращает дерево объектов, второй возвращает новый тип.
Не, никаких деревьев. Я вообще не понимаю, что должно вернуться в результате Select(o).Including(o.Product) и чем оно будет отличаться от Select(o).
Я совершенно не против возвращения новых типов. Скорее даже за.
GZ>И к тому-же плоский тип(у меня даже мыслей нет как работать с многомерными отношениями в движке запросов).
Совершенно верно. Теперь это просто данные.
GZ>3. При этом, неплохо иметь ввиду следующее. Тот же DLinq не предоставляет средств обновления для объектов полученных в результате проекции. Проблема в следующем. В случае если мы не пользуемся проекцией, вся нужная информация лежит в метаданных типа.
GZ>Ага. Только как его потом обратно запихивать в БД?
Совершенно верно. Обновлять можно только сами объекты. Если мы в результате проекции вытащили, как я предлагал, o.Amount и o.Product.FullName, то никаких чудес не будет — это просто {decmial, string}. Нужно вытащить именно OrderItem, тогда можно будет попытаться его менять.
А еще лучше делать так:
DataBase.Extent<OrderItem>.Select(itemId).Apply(delegate(OrderItem item) { item.Amount *= 2; });

Подразумевается, что это эквивалентно SQL^
update OrderItems set _amount = _amount * 2 where _id = @itemId

(в предположении, что геттер и сеттер для Amount тривиальны).
Основная фишка — в правильном разруливании блокировок и прочей мути. Если мы загрузили объект в рамках одной транзакции, а меняем в другой — есть риск умножить на два совсем не то что нужно. Апдейт по предикату гораздо лучше поддается сериализации.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 25.04.06 08:44
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Зато я говорил.

Да говори, бога ради, только без меня.

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

С чего ты взял? Еще раз, я про реализацию не говорил ни слова.

Д>будем обсуждать этот тезис, или ты все-таки согласишься наконец?

С теми словами, которые ты мне присваиваешь? — никогда.
У тебя очень странная манера вести диалог, ты присваиваешь оппоненту какие-то тезисы, которые он на самом деле не говорил, а потом начинаешь с ними спорить...

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

Ну вот опять. Я говорил о задачах, которые неудобно решать с помощю ООП — ни больше не меньше. И ты согласился, что такие задачи есть, о чем спорим?

Д>тебе напомнить, сколько времени прошло с публикации первой книги по реляционной теории и по сегодняшний день?

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

Д>детальным списком косяков ты кстати так и не поделился.

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

Д>Какие конкретно новые идеи, которые куда-то далеко выходят?

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

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

Тем, что они не закрывают доступ к данным.

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

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

Д>если нужно изменить функциональность, то код ее реализации надо менять.

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

Д>Если наше любимое правительство говорит, что с нового года НДС высчитывается по новым принципам, то код процедуры расчета НДС надо менять, и это потенциально может "всё сломать".

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

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

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

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

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

Д>и что?

И ничего, сам же кричал, что требования меняются всегда, так что ничего необычного в подобной ситуации нет.

Д>пока что вся аргументация сводилась к утверждениям "учись мыслить абстрактно" и "читай до просветления"

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

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

Слова? Там вообще смысл был не очень ясен, аккурат после твоих лингвистических упражнений.

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

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

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

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

Д>тогда уж отвечай полнее — не "скажу", а "проигнорирую и скажу".

Вот опять передергиваешь, я же не проигнорировал.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[35]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 25.04.06 09:10
Оценка:
Здравствуйте, Merle, Вы писали:

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

M>С чего ты взял? Еще раз, я про реализацию не говорил ни слова.

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

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

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

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

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


ну напомни.

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


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

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


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

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

M>Тем, что они не закрывают доступ к данным.

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

Д>>если нужно изменить функциональность, то код ее реализации надо менять.

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

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

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


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

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


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

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


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

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

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

почему — зло?

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

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

а какую первую реализацию РБД можно считать полноценной по современным меркам?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 25.04.06 09:21
Оценка:
Здравствуйте, 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(если с предикатными блокировками).
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 25.04.06 09:30
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

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

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

С этим я согласен. Однако данный подход на уровне реализации не отменяет возможности предоставлять пользователю СУБД не голые данные, а целостные объекты с некоторым поведением.
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 25.04.06 09:45
Оценка:
Здравствуйте, ie, Вы писали:

M>>>Вот скажи мне, так ли нужно наследование в ООП?

S>>Желательно но необязательно. Я поддерживаю.

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


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


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


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

с другой стороны, наследование вещь очень полезная и очень удобная. В своей ООСУБД я его поддерживаю.
Re[36]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 25.04.06 10:08
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>потому что это видно из твоих слов.

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

Д>о том, что эти неудобности можно будет решить.

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

Д>ну напомни.

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

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

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

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

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

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

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

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

Это потому что у тебя всегда есть возможность обратиться к данным напрямую.

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

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

Д>Правительству приходит в голову гениальная идея ввести в паспорт новую графу — "вероисповедание".

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

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

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

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

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

Д>почему — зло?

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

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

При чем здесь современные мерки? За те пятнадцать лет, что пытаются создать ООБД, реляционки прошли путь от идеи до тотального господства.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 25.04.06 10:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Твои слова. Вот мне и интересно что ты там собрался дописывать.

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

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

Поживем увидим. Еще Linq как такового нет.

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


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

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

AVK>И никакого засирания публичного интерфейса, максимальная гибкость и читаемость.
У меня функция выбора между логическим удалением объекта и физическим удалением объекта достаточно нетривиальна. И сильно зависит от самого объекта. Поэтому предпочитаю инкапсулировать данную функциональность, чтобы другим не мешало.
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 10:25
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>И никакого засирания публичного интерфейса, максимальная гибкость и читаемость.

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

Вот так и надо было писать что "у тебя", а не "практически всегда для больших приложений".
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[29]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 10:31
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


Не надо драматизировать. Если запрос обрабатывается внутри одног метода, то проблем нет, а если он экспортируется наружу, то вполне оправдано тип описать явно. Единственное, о чем они могли бы подумать — разрешить использование кортежей в приватных членах.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[9]: Файловые системы, файлы, приложения - устаревшие конц
От: shuklin  
Дата: 25.04.06 10:49
Оценка:
Здравствуйте, 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, то самое сложное — это изобретение эффективной стратегии выполнения запросов типа: ... На первый взгляд, это вообще труба, т.к.


видимо действительно и труба и мало того — мне такое оно и нужно, в виде трубы. Ведь реализация интерфейса может быть действительно любой, и разной в каждом обрабатываемом ОБД элементе данных. Вот меня как раз и интересуют ОБД в которых каждый объект имеет свою собственную реализацию методов (или по крайней мере значительно разнящуюся от реализаций других классов).
Re[5]: Файловые системы, файлы, приложения - устаревшие конц
От: ironwit Украина  
Дата: 25.04.06 10:54
Оценка:
Здравствуйте, Merle, Вы писали:

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


S>>Время нас рассудит.

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

Если ООП движется к закату, что возникло вместо?
... << RSDN@Home 1.2.0 alpha rev. 648>>
Я не умею быть злым, и не хочу быть добрым.
Re[38]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 25.04.06 10:56
Оценка:
Здравствуйте, 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 году? Примерно в те времена только-только появились реализации, которые поддерживали транзакции. Не помнишь, когда внешние ключи впервые появились в реализации?
Ты просто сравниваешь существующие сейчас незрелые ООБД и современные РБД, которые прошли очень большой путь и ассимилировали много идей из других концепций.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 25.04.06 11:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

В таком случае я сказал свое новое слово в данном вопросе. Возможно и могу. Я поддерживаю кроме полиморфизма поведения еще полиморфизм структуры данных. Вот его можно поддерживать вообще без методов (с точки зрения пользователя). Учитывая что реализация ОБД — это по любому ОО система и внутре у ней не только данные но и куча методов. Вот на этом я и играю. Само собой виртуальные методы гдето есть, но они не в перситент объектах и их аттрибутах а в ядре самой субд. И когда идет обращение к какому то элементу в хранилище — это обращение обрабатывается движком ОБД. Если к этому моменту подменить часть объектов, выполняющих обращение, то обращение уйдет к совершенно другому экземпляру. Т.к. разадресация виртуальной функции в самом ядре СУБД — это еденицы тактов проца, то в хорошем случае мы получаем время как при прямом доступе к полю. В плохом случае — получаем время обоснованное необходимыми ударами бубна.
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.04.06 11:02
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>IMHO Фактически, минимальный набор джентельмена -
GZ>1. Сканирование таблицы,
GZ>2. Чтение кортежа
Т.е. bookmark lookup.
GZ>3. Сканирование индекса
GZ>4. Чтение значения индекса по ключу.
GZ>А фактически хрен его знает. Даже в этом минимальном наборе нет места index range search.
А куда это он делся? Можно конечно обойтись и без него, но это сильно сужает перспективы оптимизации. Как ты можешь заметить, чтение значения по ключу — это частный случай чтения множества значений по интервалу от ID до ID. Кстати, надеюсь, ты не забыл, что индекс не обязан быть уникальным?
Возможно, есть еще какие-то операции, которые было бы полезно уметь на нижнем уровне, но я что-то так сразу и не соображу.

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

Попадалась. Называется Системы баз данных. Полный курс.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.04.06 11:02
Оценка:
Здравствуйте, GlebZ, Вы писали:

S>>Совершенно верно. Теперь это просто данные.

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

S>>Совершенно верно. Обновлять можно только сами объекты.

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

GZ>В данном случае ты сразу подразумеваешь пессимистический протокол транзакций на блокировках. Можно сделать пессимистически сериализуемой через блокировки только операции. В остальном работать по оптимистическому протоколу.

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

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

Чревато. Ой как чревато.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 11:03
Оценка:
Здравствуйте, shuklin, Вы писали:

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


Можешь продемонстрировать. Потому как как обойтись без наследования реализаций мне понятно, а вот без наследования интерфейсов ...
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 25.04.06 11:43
Оценка:
Здравствуйте, 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) ?
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: EXO Россия http://www.az.inural.ru
Дата: 25.04.06 11:46
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Не так. Задача клиента — обеспечивать взаимодействие с пользователем. А там есть еще обратное направление — преобразование действий пользователя в команды получения и изменения данных.

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

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


Почему?
Меня только обработка исключений слегка достает. Но не так чтобы уж очень...
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 25.04.06 11:56
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Сервер приложений должен обрабатывать не запросы на "поставку данных", а логику приложения. То есть то самое: "разбираться каким образом ему эти данные в каком ракурсе он будет обрабатывать".


Боюсь, что подобного формального определения что такое сервер приложений не существует. Впрочем, если поделишься ссылочкой, буду премного благодарен.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: EXO Россия http://www.az.inural.ru
Дата: 25.04.06 11:58
Оценка:
Здравствуйте, IT, Вы писали:
IT>Боюсь, что подобного формального определения что такое сервер приложений не существует. Впрочем, если поделишься ссылочкой, буду премного благодарен.

Боюсь, что нет.
Но на кой он иначе "сервером приложений" называется?
Re[33]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 25.04.06 12:00
Оценка:
Здравствуйте, Merle, Вы писали:


M>Тогда в объектном хранилище ты еще и переписываешь данные, вместе со своим кодом, они же у тебя оборудованы методами доступа от которых их не оторвать.


Это заблуждение. Возьмем к примеру тот же Cerebrum. Текущая его версия на .NET 2.0 совершенно спокойно читает бинарный файл версии от 0403 расчитаной только на .NET 1.1 и спокойно инстанциирует вместо экземпляров .NET 1.1 экземпляры .NET 2.0

Мало того, объектная модель последней версии была кардинально пересмотрена и переписана. А БД таже — в том же бинарном формате. Если это даже я умею, то остальным ОБД не уметь такого просто странно. Тоесть вы в данном вопросе заблуждаетесь
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 25.04.06 12:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:


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


С этим тезисом согласен полностью. Хотя можно было бы продискутировать на тему, является ли наследование интерфейса именно наследованием, или его можно считать полиморфизмом. (тот же VB).

Ну мне от этого вопроса ни холодно ни жарко. Я в своей СУБД поддерживаю одиночное наследование классов и множественное интерфейсов как в ядре (plain-C) так и на application уровне (С#).
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.04.06 12:17
Оценка:
Здравствуйте, EXO, Вы писали:

EXO>Почему?

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

Потому что грамотная организация процесса взаимодействия пользователя это очень непростая задача, зачастую превышающая по объемности разработку сервера приложений.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 25.04.06 12:22
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Удивительнее то, что мне пришлось это повторять так много раз.


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


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

Д>Наличие состояния у узлов системы — это вещь, от которой никуда не деться. Состояние всегда будет у узлов распределенной системы, равно как и у отдельных частей этого узла. Можешь писать хоть на ООП, хоть структурно, хоть квадратно-гнездовым способом — от этого ничего не изменится.


В stateless системах проблема состояния более менее решаема. Все те допущения о которых я говорил ранее в stateless обычное дело.

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


К счастью я не одинок.

CLOS is a dynamic object system which differs radically from the OOP facilities found in static languages such as C++ or Java.


Вика — свободная страна, можешь зарегестрироваться там и дать своё поределение OO в CLOS. Может быть тогда я приму твою версию

Д>а где про это написано? Вот прямо такими словами? Я еще не видел ни в одной книге "писать объекты без изменяемого состояния запрещено третьей сурой Корана, и все нарушители этого принципа будут гореть в аду"


А что это тогда за объекты? Можешь привести пример?

IT>>Строя архитектуру на базе распределённого ООП ты не можешь этого избежать. И я пытаюсь тебе это сказать уже в десятый раз. Ты же мне в качестве контаргументов пытаешься доказать, что и без ООП можно накосячить. Можно, ещё раз тебе говорю. Да, можно, легко. Вот только в случае ООП у тебя не будет другого выхода.


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


Я же говорю, что ты не понимаешь. Честно говоря у меня уже и желания-то никакого нет объяснять. Ну попробую ещё раз начать сначала.

Речь идёт не просто об ООП. Его мы все любим, все используем и радуемся вместе с ним жизни. Использовать его можно во многих местах. Даже в сетевых протоколах можно выделить отдельно объект коннекшин и использовать его вместо хендлеров. С этим никто не спорит и спорить не собирается. Этот ООП у нас никто не отнимет.

Речь о том, что как раз вот такими вещами применение ООП и ограничивается и попытки посторить распределённые системы в идеологии ООП пораждают больше проблем, чем их решений. Речь об иерархиях объектов, представляющих собой объектную распределённую модель предметной области, одновременно живущую на множестве серверов.

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


Проблемы одни и теже.

IT>>Это всё нетрадиционные формы ориентации ООП.

Д>кто сказал, что они нетрадиционные?

Я же говорю, нетрадиционная ориентация сегодня в моде. Так что традиционное может вполне стать нетрадиционным
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 25.04.06 12:27
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Мне так показалось, что мы обсуждали задачу как таковую, а не твою роль в ней.


Предположим, что я непосредственно отвечаю за данную задачу.

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


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

В общем, боюсь что ты опять спутал курицу с яйцом
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 26.04.06 09:13
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Это заблуждение.

Это твоя Cerebrum сплошное заблуждение..

S> Возьмем к примеру тот же Cerebrum.

Нельзя твой Cerebrum брать в качестве примера, потому как не объектная она, по причине отсутствия в ней инкапсуляции, из-за которой в этой подветке весь сыр-бор и разгорелся...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[39]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 26.04.06 09:13
Оценка:
Здравствуйте, Дарней, Вы писали:

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

Ответил, а то что он тебя не устроил, так я не виноват.

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

Ну и где это решение? Их уже второй десяток лет решают и все что-то ни как...

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

Нет, в конце семидесятых, первые доступные широкой общественности публикации были не в 70м, а позже.

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

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

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

Более чем достаточно. Тому же Gemstone/S, с так полюбившейся тебе динамической типизацией, уже больше пятнадцати лет.

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

Да нет, просто появилось, видимо, к чему придраться...

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



Д>не обертки. Расширение интерфейса существующих объектов.

По кругу поехали?

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

Почему неправильным? Правильным, по старым правилам.

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

Что-то фиговая иллюстрация получается, и опять-таки, с первого раза даже такой пример придумать не смог.

Д>Как видишь, здесь мы имеем как инкапсуляцию, так и доступ ко всем данным.

Нет у нас здесь доступа ко всем данным. Что делать, если зависимость изменилась? И даже если не изменилась, ты предлагаешь делать геттеры в обязательном порядке, на всякий случай? Да уж, ОО-подход.

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

Не прикидывайся. Вспомни, почему отчеты в ОО делать неудобно...

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

Объекты и данные.

Д>В геморрой выливается менять структуру данных в РБД.

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

Д>Тотальное господство РБД в 1985 году?

Вот такое вот тотальное господство.

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

Ну сравни развитие реляционки, от первой коммерческой версии за помежуток времени в развитии ООБД, от первой же версии до наших дней.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[28]: Файловые системы, файлы, приложения - устаревшие кон
От: EXO Россия http://www.az.inural.ru
Дата: 26.04.06 09:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Потому что грамотная организация процесса взаимодействия пользователя это очень непростая задача, зачастую превышающая по объемности разработку сервера приложений.

Согласен полностью.
Тебя смутило слово "только"? Оно не про сложность/простоту, а про обработку данных.
Re[20]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.04.06 09:27
Оценка:
Здравствуйте, shuklin, Вы писали:
ет опережать ОБД. И это мы говорим о тупом поиске в глубь на основании индексов.

S>Еще меня смущает JOIN за log(Ш')+log(У')

Да, конечно косяк. Join будет сделан за Ш'+У'. Там на самом деле обе оценки гонимые.
1. С чего ты взял, что школы удастся отобрать за log(Ш)? Это годится только в том случае, если школа ровно одна. В противном случае стоимость складывается из стоимости поиска и стоимости сканирования. Т.е. log(Ш)+Ш'. К тому же, надо помнить о коэффициентах. В данном случае логарифмом можно пренебречь — в реальных СУБД у него очень большие основания.
Поэтому на самом деле итоговая стоимость будет порядка O(Ш') + O(У').
Такая же стоимость и у запроса в RDBMS, с точностью до констант при Ш' и У'.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.04.06 09:27
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Ездят куда?

См. http://tpc.org
S>Если в гриды или отчеты — это одно. А если в объекты бизнес логики — это другое.
Поясняю: RDBMS ни в каких объектах бизнес логики не нуждается. Речь идет об OLTP приложениях, типа продаж товара. Ты готов на своей настольной ОБД выписывать 10000 заказов в минуту? С учетом того, что параллельно проходят подтверждения платежей, а кто-то еще смотрит отчеты.
S>По любому на ORM будут затраты. Их можно избежать. А в гриды и отчеты данные как и раньше отправлять мимо методов.
Гриды и отчеты ездят поверх OLAP. Там ОДБ никогда не догонит специализированные базы.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 09:32
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Еще меня смущает JOIN за log(Ш')+log(У')

S>Да, конечно косяк.

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

Однко для разных задач разные модели данных более предпочтительны. ИМХО для построения ОБД наиболее близкой будет сетевая модель.

Если так, то РБД пора на пенсию.
Re[11]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 09:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Поясняю: RDBMS ни в каких объектах бизнес логики не нуждается. Речь идет об OLTP приложениях, типа продаж товара. Ты готов на своей настольной ОБД выписывать 10000 заказов в минуту? С учетом того, что параллельно проходят подтверждения платежей, а кто-то еще смотрит отчеты.


После реализации клиент-сервера 10000 — готов. Писал уже, в декабрьской версии без транзакций можно получить 80000. В текущей с транзакциями будет около 25000 — 40000. Это пока чистый функционал. Надеюсь довести после оптимизации до 100000 объектов в секунду. А ведь объект это вещь сложная, по объекту на заказ + необходимые накладные расходы — получим те же 10000. Ну и тачка моя текущая не фонтан для сервака. Так что ИМХО скоростные показатели моего поделия хоть и не в переди планеты всей, но для решения насущных задач более чем достаточны.
Re[35]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 09:49
Оценка:
Здравствуйте, Merle, Вы писали:

S>> Возьмем к примеру тот же Cerebrum.

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

Для тех кто в танке, в Cerebrum инкапсуляция присутствует, но с возможностью от нее отказаться при желании (на этапе разработки БД). В Cerebrum присутствует свобода выбора. Оба варианта будут обладать соответсвующими свойствами. С инкапсуляцией — и достоинсвами и недостатками подходов с инкапсуляцией, без инкапсуляции — тоже с достоинсвами и недостатками.
Re[36]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 26.04.06 10:18
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Для тех кто в танке, в Cerebrum инкапсуляция присутствует, но с возможностью от нее отказаться при желании (на этапе разработки БД). В Cerebrum присутствует свобода выбора.

Тяжело же вам, в танке... Если мы вибираем инкапсуляцию, значит доступа к самим данным напрямую нет, значит я прав. Если мы выбираем не инкапсуляцию, значит это не ООБД и, следовательно, я опять прав.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[37]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 10:28
Оценка:
Здравствуйте, Merle, Вы писали:

S>>Для тех кто в танке, в Cerebrum инкапсуляция присутствует, но с возможностью от нее отказаться при желании (на этапе разработки БД). В Cerebrum присутствует свобода выбора.

M>Тяжело же вам, в танке... Если мы вибираем инкапсуляцию, значит доступа к самим данным напрямую нет, значит я прав. Если мы выбираем не инкапсуляцию, значит это не ООБД и, следовательно, я опять прав.

Вы если и правы, так только в дефенициях. Мне глубоко пофиг как что назвать. От названия суть не меняется. Не зависимо от того что "правы" вы в обоих случаях, функциональность от этого не страдает. Если нам важны вопросы секурити и мы согласны забить на перформанс — вуаля, мы идем по первой веточке где вы "правы". Если нам нужно получить перформанс — идем по второй, а секурити обеспечиваем уровнем выше. Мало того, не забываем, что полиморфизм от обоих веточек не страдает. Как в одном так и в другом сценарии сохраняется возможность подставлять вместо одной структуры объектов другую структуру. Так что за исключением секурности поимели все выгоды и от ООП и открытости данных. Мало того, секурность во второй веточке тоже в ядро ОБД можно встроить, и раздавать права на чтение отдельных аттрибутов ... Так несмотря на то что вы типа правы, по любому ОБД на основе сетевой модели рулят.
Re[22]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.04.06 11:12
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Если я правильно понял ваш тезис, то получаецца что при грамотной реализации что иерархической модели что реляционной что сетевой затраты при решении одинаковых задач будут примерно одинаковыми (т.е. чудес не будет). С этим я согласен.

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

S>Если так, то РБД пора на пенсию.

Далеко еще до пора.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.04.06 11:16
Оценка:
Здравствуйте, shuklin, Вы писали:

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


S>>Поясняю: RDBMS ни в каких объектах бизнес логики не нуждается. Речь идет об OLTP приложениях, типа продаж товара. Ты готов на своей настольной ОБД выписывать 10000 заказов в минуту? С учетом того, что параллельно проходят подтверждения платежей, а кто-то еще смотрит отчеты.


S>После реализации клиент-сервера 10000 — готов. Писал уже, в декабрьской версии без транзакций можно получить 80000. В текущей с транзакциями будет около 25000 — 40000. Это пока чистый функционал. Надеюсь довести после оптимизации до 100000 объектов в секунду. А ведь объект это вещь сложная, по объекту на заказ + необходимые накладные расходы — получим те же 10000. Ну и тачка моя текущая не фонтан для сервака. Так что ИМХО скоростные показатели моего поделия хоть и не в переди планеты всей, но для решения насущных задач более чем достаточны.

Ты, наверное, не понял. Надо не загружать в память 10000 объектов. Надо делать следующее:
— создавать объект заказа
— добавлять в него в среднем примерно 10 позиций-
— сохранять объект заказа
— выполнять отгрузку заказа:
-- находить товары, перечисленные в заказе, на складе
-- уменьшать остатки на складе в соответствии с количеством в заказе (при этом надо еще и откатывать транзакцию, если товара не хватило)
и в это же время проводить платежи (т.е. находить заказ, соответствующий оплате, сравнивать суммы, и помечать заказ как оплаченный), а также время от времени выдавать отчеты типа текущих остатков.
При этом 10000 — это количество отгруженных заказов в минуту. При этом, ессно, без транзакций нельзя — иначе у тебя нарушится целостность данных.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 11:17
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>>Если я правильно понял ваш тезис, то получаецца что при грамотной реализации что иерархической модели что реляционной что сетевой затраты при решении одинаковых задач будут примерно одинаковыми (т.е. чудес не будет). С этим я согласен.
S>Нет, неправильно. В более сложных случаях сетевая модель будет сливать. Просто потому, что в какой-то момент join предикат окажется более селективным, чем примененный к экстенту. Ну вот как представь себе, что школ, в которых есть школьники нужного возраста, мало. Тогда РДБ выберет школьников, получит список школ, в которых они учатся, и проверит, какие из них попадают в нужный диапазон. Сетевая БД будет вынуждена сканировать все школы просто на всякий случай.
S>>Однко для разных задач разные модели данных более предпочтительны. ИМХО для построения ОБД наиболее близкой будет сетевая модель.

Это если модель не сетевая, а иерархическая — полностью согласен. В сетевой тот же запрос на основании статистики можно раскручивать с другого конца — со стороны учеников. На то она и сеть, что корня у нее нет. ИМХО РМД есть частный случай сетевой модели. А вот иерархии (дерево) действительно во многих случаях проигрывают.
Re[38]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 26.04.06 11:24
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Вы если и правы, так только в дефенициях. Мне глубоко пофиг как что назвать.

Вот давай подумаем, зачем ты сюда пришел со своей БД, которая рушит все устои... Ты пришел чтобы рассказать нам об этом, чтобы мы прониклись и оценили, правильно? Для того чтобы мы смогли это оценить и проникнуться нам надо понять что ты говоришь, а чтобы понять что ты говоришь, надо чтобы у нас хотя бы терминология была одинаковая... Но тебе пофиг — парадокс?
То тебе O(1) не нравится и ты его в O(C) переименовал, то объектами невесть что называешь, опять-таки потому что тебе нравится....

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

Видишь ли, в данном случае обсуждается как раз та функциональность, которая в твоей БД весьма страдает.

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

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

S>по любому ОБД на основе сетевой модели рулят.

Ты это как мантру, в любое сообщение вставляешь? Так куда у нас рулят "ООБД на основе сетевой модели", и чем они лучше сетевых БД, которым уже лет тридцать с хвостиком?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 11:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ты, наверное, не понял. Надо не загружать в память 10000 объектов. Надо делать следующее:


В ближайшей версии я обоснованно предполагаю выйти на следующие (для меня неприемлимые на самом деле — хочу в 10-100 раз лучше) показатели:

— транзакции ON
— 400-600 созданий/загрузок C# объектов в секунду
— 20000 — 40000 обращений к существующим C# объектам в секунду

На объеме БД до 2Г экземпляров.

10000 транзакций в минуту такое тянет даже сейчас.
Re[39]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 11:37
Оценка:
Здравствуйте, Merle, Вы писали:

S>>Вы если и правы, так только в дефенициях. Мне глубоко пофиг как что назвать.

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

В том числе — и для этого. Ващето больше меня интересует найти дыры в собственной концепции. Ну бывало и такое. Поэтому кстати версия от декабря 2005 имеет иерархическую глубинную архитектуру, а последняя — сетевую. Пасиба народу который меня на sql.ru попинал на предмет объектных VIEW & JOIN. До этого обсуждения я предполагал забить на сеть в глубине ядра. После обсуждения понял что халтурить не выйдет )))

M>Видишь ли, в данном случае обсуждается как раз та функциональность, которая в твоей БД весьма страдает.


Это какая же? Опять начнем мусолить функциональность инкапсуляции? У запретов нет функциональности. Если что то делать нельзя (ходить к закрытым полям) то это вовсе не функциональность а ее отсутвие. Если тебе дорги костыли и запреты — пользуйся ими наздоровье. И такого стиля девелопмента есть поддержка в моей СУБД.

M>Если мы отказываемся от инкапсуляции, то получаем хранилище ни чем не лучше реляционного,


Оно не лучше и не хуже, но оно на основе другой МД. А вот другая МД это именно ДРУГАЯ. Ну а моя реализация по поводу производительности еще не тюнилась профайлером ни разу ... А даже уже дает весьма достаточное быстродейстивие


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


"Проблемы" по сравнению с первым случаем использования моей же СУБД а не по сравнению с конкурирующими СУБД.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 26.04.06 12:23
Оценка:
Здравствуйте, shuklin, Вы писали:

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


S>В таком случае я сказал свое новое слово в данном вопросе.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 12:29
Оценка:
Здравствуйте, eao197, Вы писали:


E>Вероятно, скоро на вашем сайте появится статья: "Дмитрий Шуклин о перспективах полиморфизма без инкапсуляции".



Мало вероятно Тему следующей провокации я еще не выбрал
Re[40]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 26.04.06 13:35
Оценка:
Здравствуйте, shuklin, Вы писали:

S>В том числе — и для этого.

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

S> Ващето больше меня интересует найти дыры в собственной концепции. Ну бывало и такое.

Во-во, тебе этих дыр уже, на десять лет разгребания здесь навалили.

S>Это какая же?

А вот так же.

S>Опять начнем мусолить функциональность инкапсуляции?

Ну вообще-то, пока ты не влез, с данной функциональностью все было в порядке.

S>Если что то делать нельзя (ходить к закрытым полям) то это вовсе не функциональность а ее отсутвие.

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

S>Оно не лучше и не хуже, но оно на основе другой МД. А вот другая МД это именно ДРУГАЯ.

Ну, если цель сделать просто ДРУГУЮ, то пожалуйста, только не морочь людям голову.

S> Ну а моя реализация по поводу производительности еще не тюнилась профайлером ни разу ... А даже уже дает весьма достаточное быстродейстивие

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

S>"Проблемы" по сравнению с первым случаем использования моей же СУБД а не по сравнению с конкурирующими СУБД.

У тебя даже индексов нет по полям, о какой производительности вообще может идти речь?

Вообщем вот здесь тебе уже все сказали: Re[15]: Файловые системы, файлы, приложения &mdash; устаревшие кон
Автор: eao197
Дата: 26.04.06
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[41]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 13:40
Оценка:
Здравствуйте, Merle, Вы писали:


M>Вообщем вот здесь тебе уже все сказали: Re[15]: Файловые системы, файлы, приложения &mdash; устаревшие кон
Автор: eao197
Дата: 26.04.06


Тоесть конструктивные аргументы (что я впариваю давно уже ясно , а что вы мне тут пытаетесь впарить не понятно ) закончились ?
Re[42]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 26.04.06 14:02
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Тоесть конструктивные аргументы

Как можно давать конструктивные аргументы на неконструктивное впаривание? Это пустая трата сил...
Конструктив был в первом сообщении, но развивать его ты не захотел, а кто я такой чтобы навязываться со своим конструктивом?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[43]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 26.04.06 14:15
Оценка:
Здравствуйте, Merle, Вы писали:

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


Уважаемый, конструктива в вашем первом сообщении был мизер. И этот мизер уже исчерпан в соседних ветках. Топик получился интересный, есть что почитать. См. например про FieldDescriptor ИМХО наиболее интересная тема в данном топике т.к. раскрывает возможность построения объектных VIEW на основе синонимии/омонимии объектных идентификаторов. Еще было интересно про школы с учениками. И результат ИМХО нейтральный для обоих сторон — и там вами не пахло. Возможно в связи с отсутствием у вас контраргументов?
Re[44]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 26.04.06 14:36
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Уважаемый, конструктива в вашем первом сообщении был мизер.

Ну яж не виноват, что ты не в состоянии его воспринять...

S> Возможно в связи с отсутствием у вас контраргументов?

С отсутствием у меня желания заниматься чужим образованием, тем более когда образовываться не хотят.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[30]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 26.04.06 15:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

гемоэнцэфалический барьер

S>Ну, вообще "как в датасете" мне не очень нравится. Однако, надо помнить, что датасет апдейтится при помощи дата адаптера; таким образом, на сервер фактически уезжает батч из апдейт команд.

Маленькая поправочка. Уезжает не батч, а генерится поток команд. Если какой-то update не прошел, net начинает спрашивать нужно ли эти данные или нет. Мое IMHO что это лишняя и несколько нехорошая функциональность. Она выглядит опасной. Но если Microsoft реализовал такое, значит кому-то это нужно.

GZ>>В данном случае ты сразу подразумеваешь пессимистический протокол транзакций на блокировках. Можно сделать пессимистически сериализуемой через блокировки только операции. В остальном работать по оптимистическому протоколу.

S>У оптимистического протокола своих бед хватает.
S>Вкратце: OODBMS полезны в основном в OLTP; всякие могучие отчеты надо гонять поверх данных, и там поведение только вредит. А OLTP куда как лучше справляется в случае пессимистичного блокировщика (если, конечно, не слишком параноидально ставить локи).
Вот с этим не особо согласен. OODBMS конечно не OLAP, срезы им делать нельзя, но из-за того что он позволяет работать недекларативно с данными, для отчетов он более удобен.
Чтобы не повторяться: здесь
Автор: GlebZ
Дата: 23.04.06


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

S>Чревато. Ой как чревато.
Нормалек. И у пессимистичного, и у оптимистичного протокола свои достоинства, и свои недостатки.
Пессимистичный лучше себя ведет если есть сильная конкуренция за какие-то ресурсы на запись. Его вероятность быть успешным в таких передрягах значительно выше. Зато песня о блокирующем чтение вообще убивает. И самое поганое что если от него отвязываться, то теряешь пессимистичность и получаешь ту же версионную систему.
Мне оптимистические блокировки больше нравятся потому что их можно экспортировать с машины. Например как это делает тот-же датасет. Хотя вариант с тем что сделал Игорь в BLToolkit() мне кажется более правильным. В случае, если мы сможем добавить к экспортируемому объекту версию транзакции, то получится реализация длинных транзакций с высоким уровнем изоляции.
Ну например:
В строке сохраняем версию последней изменившей объект транзакции.
При чтении объекта:
1. Создаем транзакцию.
2. Читаем объект.
3. Если объект помечен что изменен другой незафиксированной транзакцией:
3.1 Транзакция изменившая объект началась раньше или уровень нашей транзакции Read Commited, то мы можем взять предыдущую версию объекта.
3.2 Транзакция изменившая объект началась позже, и уровень нашей транзакции Snapshot то откатываем текущую. Вероятность фиксирования транзакций значительно выше чем отката.
4. В объект помещаем номер транзакции с помощью которой он был прочитан.
5. Далее нам никакая информация о транзакции не нужна, мы можем ее выбросить. На важен только относительный номер транзакции в которой был прочитан объект.

При записи объекта:
1. Открываем новую транзакцию
2. Смотрим был ли перезаписан объект какой либо другой транзакцией чем та, которая ее прочитала. Если был, то отбиваем текущую транзакцию.
3. Если нет, то записываем новый объект и проставляем номер транзакции в запись.
4. Фиксируем транзакцию.

Фактически мы получили систему со snapshot, и самое главное, без какого-то либо состояния на сервере. Если подумать, то наверно можно еще увеличить параллельность.
Однако для Snapshot остаются Write Skew и Fantom.
Write Skew — вещь очень редкая. В принципе на нее особо внимания и не обращаешь.
Что касается фантомов, то без предикатных блокировок(пессимизмъ у нас, или оптимизмъ усе равно) мы от них не избавимся. Но так как наша задача именно избавиться от состояния, то в принципе мы их можем оптимистично облегчить. Например, в случае если кто-то решил записать данные удовлетворяющее некоторой предикатной блокировке, мы можем вмето того, чтобы пессимистично отбросить записывающую транзакцию, оптимистично убить блокировку, и пометить что все данные полученные от транзакции установившей его, нужно отбивать. Что есть достаточно правильно, поскольку если пользователь установил serializable, то именно он берет ответственность за нее, а не тот кто пытается ее нарушить.
Write Skew — штука достаточно сложноопределимая. Насколько я помню формулировка такая:
r1(x)r2(y)w1(y)w2(x). В принципе можно поступить так же. Сделать примерно такие же полублокировки на объекты, при нарушении которых транзакция которая проставили их, отлетает.
И вообще, эти две проблемы можно решить с помощью пользователя. Например, предоставить пользователю инструмент, чтобы при записи объекта, проверялось были ли изменены функционально связанные с ним объекты. Как результат, он сможет сам гибко управлять сериализацией транзакций.

Система чрезвычайно похожа на ораклоидную кроме требования, что объекты могут покидать пределы базы данных.
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 26.04.06 15:23
Оценка:
Здравствуйте, Sinclair, Вы писали:

GZ>>IMHO Фактически, минимальный набор джентельмена -

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

S>Возможно, есть еще какие-то операции, которые было бы полезно уметь на нижнем уровне, но я что-то так сразу и не соображу.

GZ>>Не попадалась документашка, в которой бы было описано какие операции делаются на уровне хранилища(ну пожалуй кроме SystemR, которую современной уже не назовешь).
S>Попадалась. Называется Системы баз данных. Полный курс.
Книжка видать хорошая. Надо бы посмотреть. Только я не верю что бывают книги в которых можно описать все.
Re[32]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 26.04.06 15:57
Оценка:
Здравствуйте, AndrewVK, Вы писали:

GZ>>гемоэнцэфалический барьер


AVK>Не сочтите за наезд, но <b>гематоэнцефалический</b> барьер

Я понял по самому термину, что он обозначает. Просто мне сильно понравилось выражение.
Re[30]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 26.04.06 16:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

А может стоит тут интерпретировать не как объекты OODB, а именно как объекты из компоненты OODB? Для Net такое управление вполне возможно. Версионификация объектов также возможна(о ней даже не забыли в манифесте ). Траблы которые получаются в РСУБД и OODB получаются достаточно сходной природы. Если вьюха или сторед процедура представить как темпоральные объекты. Решаются траблы только по разному.
Re[14]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.04.06 01:51
Оценка:
Здравствуйте, shuklin, Вы писали:

S>10000 транзакций в минуту такое тянет даже сейчас.

А что в транзакции выполняется?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.04.06 01:51
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Это если модель не сетевая, а иерархическая — полностью согласен. В сетевой тот же запрос на основании статистики можно раскручивать с другого конца — со стороны учеников.

Для этого нужен такой язык запросов, который бы не использовал императивную навигацию. В Cerebrum он есть?
S>На то она и сеть, что корня у нее нет. ИМХО РМД есть частный случай сетевой модели. А вот иерархии (дерево) действительно во многих случаях проигрывают.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.04.06 01:51
Оценка:
Здравствуйте, GlebZ, Вы писали:
S>>А куда это он делся? Можно конечно обойтись и без него, но это сильно сужает перспективы оптимизации. Как ты можешь заметить, чтение значения по ключу — это частный случай чтения множества значений по интервалу от ID до ID. Кстати, надеюсь, ты не забыл, что индекс не обязан быть уникальным?
GZ>Да. Но просто я недопру. При сканировании по диапазону, надо получить не значение а минимальную и максимальную позицию ключа в листьях для последующего сканирования.
Гм. Там все банально. Для B+tree мы, получив диапазон, очень быстро спускаемся к его левой границе и начинаем последовательное сканирование страниц. Поскольку листья образуют двусвязный список, это очень эффективно. Именно поэтому хэшиндексы и стали менее популярны — нет поддержки range scan, и нет побочного эффекта упорядоченности ключей.
S>>Попадалась. Называется Системы баз данных. Полный курс.
GZ>Книжка видать хорошая. Надо бы посмотреть.
Обязательно посмотри!
GZ>Только я не верю что бывают книги в которых можно описать все.
Там смысл не в том, что "все", а в том, что описываются все аспекты построения СУБД.
Вот оглавление, обрати внимание на главы с 11 по 16.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.04.06 01:51
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Не сочтите за наезд, но <b>гематоэнцефалический</b> барьер
Спасибо. Я знал, что он как-то не так называется, но знал, что меня поймут. Теперь буду писать правильно.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.04.06 01:51
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>А может стоит тут интерпретировать не как объекты OODB, а именно как объекты из компоненты OODB?
Че-то не улавливаю. Ты не мог бы развернуть?
GZ>Для Net такое управление вполне возможно. Версионификация объектов также возможна(о ней даже не забыли в манифесте ). Траблы которые получаются в РСУБД и OODB получаются достаточно сходной природы. Если вьюха или сторед процедура представить как темпоральные объекты. Решаются траблы только по разному.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 27.04.06 04:51
Оценка:
Здравствуйте, Merle, Вы писали:

M>Ответил, а то что он тебя не устроил, так я не виноват.


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

M>Нет, в конце семидесятых, первые доступные широкой общественности публикации были не в 70м, а позже.


издание первой книги Кодда по реляционной теории — это 70й год.

M>Меня тоже не устраивает, но из двух решений я выбираю то, где проблем меньше...


А если не устраивают оба варианта, что ты предлагаешь делать? Сидеть на печи и мечтать, что умные дядьки всё сделают?

M>Более чем достаточно. Тому же Gemstone/S, с так полюбившейся тебе динамической типизацией, уже больше пятнадцати лет.


и он сейчас вполне благополучно применяется

Д>>не обертки. Расширение интерфейса существующих объектов.

M>По кругу поехали?

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

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

M>Почему неправильным? Правильным, по старым правилам.

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

M>Нет у нас здесь доступа ко всем данным.


К каким данным вот здесь у тебя нет доступа?

M>Что делать, если зависимость изменилась?


Менять код.

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


А в чем проблема то? Только не путай опять геттеры с чм нибудь еще. Они НЕ меняют данные.

M>Не прикидывайся. Вспомни, почему отчеты в ОО делать неудобно...


Потому что нет нормального языка запросов по объектам. Пока нет.

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

M>Объекты и данные.

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

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


не более, чем alter type X add method Y

M>Вот такое вот тотальное господство.


вот такое вот хреновое лето

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


Уже сравнил. Реляционки за 1985 год совсем не порадовали меня своими фичами.


Ладно, неважно это всё. Что хотел, я от тебя уже узнал. Не то чтобы это было особо полезно, но время всё равно уже потрачено
А заниматься религиозными спорами и наблюдать, как ты бьешь себя пяткой в грудь, мне не интересно. Так что адью.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[35]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 27.04.06 04:51
Оценка:
Здравствуйте, IT, Вы писали:

IT>В общем, боюсь что ты опять спутал курицу с яйцом


это ты опять спутал задачу в целом со своей частной ролью в ней.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[33]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 27.04.06 04:51
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


в смысле, одна база работает для обеих задач?

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


не суть важно
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 27.04.06 04:51
Оценка:
Здравствуйте, IT, Вы писали:

IT>Боюсь, что ты до сих пор не понял. Попробуй всё же произнести слова "распределённый" и "ООП" вместе. Не спорить со мной о значении каждого по отдельности, а произнести вместе "распределённый ООП". И делай так при любом упоминании одного из этих слов в этой ветке. Может тогда до тебя дойдёт.


Наверно, в следующий раз ты мне посоветуешь задуматься о звуке, который издает хлопок одной ладонью Нет уж, медитативные упражнения — не для меня

IT>В stateless системах проблема состояния более менее решаема. Все те допущения о которых я говорил ранее в stateless обычное дело.


опять же, stateless в каком смысле? Когда каждый запрос не зависит от результата предыдущих?
Ну тогда никто не запрещает сочетать stateless и объекты.

IT>

IT>CLOS is a dynamic object system which differs radically from the OOP facilities found in static languages such as C++ or Java.


ну да, здесь написано, что объектная система CLOS радикально отличается от тех средств ООП, которые есть в статических языках, таких как C++ или Ява. И где здесь написано, что это "не ООП вообще"? Ну отличается. Средства ООП в Смоллтоке отличаются от аналогичных в С++ куда радикальнее, чем сам С++ отличается от Си. И что, какой-то из них нужно называть не ООП?

IT>А что это тогда за объекты? Можешь привести пример?


Такие, которые инкапсулируют прямой доступ к данным, например... лень придумывать примеры

IT>Речь о том, что как раз вот такими вещами применение ООП и ограничивается и попытки посторить распределённые системы в идеологии ООП пораждают больше проблем, чем их решений. Речь об иерархиях объектов, представляющих собой объектную распределённую модель предметной области, одновременно живущую на множестве серверов.


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

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


IT>Проблемы одни и теже.


мдя. Значит, всё-таки не почитал.

IT>Я же говорю, нетрадиционная ориентация сегодня в моде. Так что традиционное может вполне стать нетрадиционным


то есть проснешься одним "прекрасным" утром и обнаружишь, что ты — гей? Типун тебе на язык!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[15]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 27.04.06 08:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А что в транзакции выполняется?


Пользовательский код пользовательских объектов. При коммите — изменения коммитятся, при роллбак — соответсвенно отменяются.
Re[25]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 27.04.06 08:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Для этого нужен такой язык запросов, который бы не использовал императивную навигацию. В Cerebrum он есть?


Тут постоянно перепутываются теоретические соображения с практическими. В Cerebrum нет никакого декларативного языка запросов. Мало того, в перспективе я не собираюсь делать ничего похожего на OQL либо SQL — есть причины. А вот поддержку LINQ в перспективе было бы приятно сделать. Да, согласен, некоторый механизм, который бы не использовал навигацию нужен для обеспечния такой фичи.
Re[16]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.04.06 10:51
Оценка:
Здравствуйте, shuklin, Вы писали:

S>Пользовательский код пользовательских объектов. При коммите — изменения коммитятся, при роллбак — соответсвенно отменяются.

И что, твоя система выполняет 10000 ЛЮБЫХ транзакций? Независимо от объема изменений? Я тебе талдычу про результаты теста tpc-c с http://tpc.org.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: shuklin  
Дата: 27.04.06 10:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>Пользовательский код пользовательских объектов. При коммите — изменения коммитятся, при роллбак — соответсвенно отменяются.

S>И что, твоя система выполняет 10000 ЛЮБЫХ транзакций? Независимо от объема изменений? Я тебе талдычу про результаты теста tpc-c с http://tpc.org.

Ну зачем же так грубо. Говорил же, при скорости в 40000 инстанциированных объектов / в сек и пусть 500 инстанциирований в сек сами можете посчитать сколько чего в одну минуту влезет.
Re[26]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 27.04.06 12:26
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Наверно, в следующий раз ты мне посоветуешь задуматься о звуке, который издает хлопок одной ладонью Нет уж, медитативные упражнения — не для меня


Надеюсь, следущего раза не будет.

Д>Ну тогда никто не запрещает сочетать stateless и объекты.


Давай вместе: "распределённые объекты". Теперь попробуй посочетать stateless и распределённые объекты.

Д>ну да, здесь написано, что объектная система CLOS радикально отличается от тех средств ООП, которые есть в статических языках, таких как C++ или Ява.


Мне этого достаточно.

Д>И где здесь написано, что это "не ООП вообще"? Ну отличается.


А я сказал не ООП вообще? Я сказал "другой", горазд же ты перевирать чужие слова

IT>>А что это тогда за объекты? Можешь привести пример?

Д>Такие, которые инкапсулируют прямой доступ к данным, например... лень придумывать примеры

Ну напрягись.

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


Да без проблем. Три так три. Попробуй реализуй объект... ну например словарь, половина элементов которого находится на одной машине, половина на другой. Давай, вперёд.

IT>>Проблемы одни и теже.

Д>мдя. Значит, всё-таки не почитал.

Может почитал, может нет Список литературы ты привести не удосужился.

IT>>Я же говорю, нетрадиционная ориентация сегодня в моде. Так что традиционное может вполне стать нетрадиционным

Д>то есть проснешься одним "прекрасным" утром и обнаружишь, что ты — гей? Типун тебе на язык!

Нет не так, всё у тебя с ног на голову. Ты кем был тем и проснёшся, но вот именно это уже станет нетрадиционным.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 27.04.06 13:17
Оценка:
Здравствуйте, IT, Вы писали:

IT>Давай вместе: "распределённые объекты". Теперь попробуй посочетать stateless и распределённые объекты.


симметричный вариант — stateless и распределенные наборы данных... сильно легче стало?

IT>А я сказал не ООП вообще? Я сказал "другой", горазд же ты перевирать чужие слова


А ты не говорил "некоторые варианты ООП плохо работают в распределенке". Ты сказал "ООП плохо работает в распределенке" — как еще мне следовало тебя понимать?
Ну и горазды же вы словами играть....

IT>Да без проблем. Три так три. Попробуй реализуй объект... ну например словарь, половина элементов которого находится на одной машине, половина на другой. Давай, вперёд.


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

IT>Может почитал, может нет Список литературы ты привести не удосужился.


хм.... wikipedia.org?

IT>Нет не так, всё у тебя с ног на голову. Ты кем был тем и проснёшся, но вот именно это уже станет нетрадиционным.


шутка..
а на самом деле, тебе никогда не приходило в голову, что если нетрадиционные методы становятся традиционными — то это просто раньше всё стояло на голове, а не ногах? И что ситуация просто исправляется?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[28]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 27.04.06 14:02
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Да без проблем. Три так три. Попробуй реализуй объект... ну например словарь, половина элементов которого находится на одной машине, половина на другой. Давай, вперёд.


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


О! Это уже большой прогресс Теперь осталось прояснить одну мелочь. А именно, в случае не-ООП хранилища меня никто не принуждает страдать такой фигнёй. А в случае распределённого-ООП (выделено специально для тебя, читать слитно) от этих проблем я никуда не денусь.

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


Тем не менее попыток сделать системы на базе распределённого ООП пока хватает. В мире Java ушлые чуваки на этом зарабатывают неплохие бабки. Правда, кто поумнее начинает называть это немного по-другому, типа распределённый кеш или что-то в этом роде.

IT>>Может почитал, может нет Список литературы ты привести не удосужился.

Д>хм.... wikipedia.org?

Сказал бы сразу — The Internet.

Д>а на самом деле, тебе никогда не приходило в голову, что если нетрадиционные методы становятся традиционными — то это просто раньше всё стояло на голове, а не ногах? И что ситуация просто исправляется?


Ты хочешь сказать, что если ты завтра проснёшься не геем и это уже будет нетрадиционно, то это просто исправилась ситуация?
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 27.04.06 15:38
Оценка:
Здравствуйте, IT, Вы писали:

IT>О! Это уже большой прогресс Теперь осталось прояснить одну мелочь. А именно, в случае не-ООП хранилища меня никто не принуждает страдать такой фигнёй. А в случае распределённого-ООП (выделено специально для тебя, читать слитно) от этих проблем я никуда не денусь.


Если хранилище не-ООП, то синхронизировать состояние хранилищ на разных узлах тебе все равно придется. Тебя никто не принуждает, но задача этого требует Я конечно могу представить себе дзен-информационную систему, все узлы которой отправляют вводимые данные прямиком в /dev/null, а отчеты печатает из /dev/rnd
Но я не могу представить людей, которым будет нужна такая система. Можем быть, буддистским монахам.... но они обычно не заказывают софт

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

IT>Тем не менее попыток сделать системы на базе распределённого ООП пока хватает. В мире Java ушлые чуваки на этом зарабатывают неплохие бабки. Правда, кто поумнее начинает называть это немного по-другому, типа распределённый кеш или что-то в этом роде.


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

IT>Ты хочешь сказать, что если ты завтра проснёшься не геем и это уже будет нетрадиционно, то это просто исправилась ситуация?


сам понимаешь, в реальности такой ситуации никогда не будет. В отличие от изменения методов декомпозиции задач и построения систем. В том то вся беда ложных аналогий...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[30]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 27.04.06 22:22
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Если хранилище не-ООП, то синхронизировать состояние хранилищ на разных узлах тебе все равно придется.


Во-первых, я могу воспользоваться допущениями, о которых я говорил выше.
Во-вторых, я могу иметь распределённую систему и не иметь при этом хранилищ на разных узлах.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.04.06 02:21
Оценка:
Здравствуйте, shuklin, Вы писали:
S>Ну зачем же так грубо. Говорил же, при скорости в 40000 инстанциированных объектов / в сек и пусть 500 инстанциирований в сек сами можете посчитать сколько чего в одну минуту влезет.
Ничего из этого не посчитаешь. Количество транзакций зависит далеко не только от скорости примитивных операций. Иначе бы твоя система вообще шансов не имела, т.к. РБД никакими инстанцированиями не занимается и скорость загрузки страниц у нее будет повыше.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Файловые системы, файлы, приложения - устаревшие конц
От: Adopt  
Дата: 28.04.06 04:07
Оценка:
Здравствуйте, Merle, Вы писали:


M>По некоторым данным ребята потратили около восьми лет на исследования как это лучше сделать, а в итоге пришли все к той же банальной реляционной таблице с B+ индексом, вот и весь XML.


только не пинайте
Что такое таблица с B+ индексом?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[31]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 28.04.06 04:10
Оценка:
Здравствуйте, IT, Вы писали:

IT>Во-вторых, я могу иметь распределённую систему и не иметь при этом хранилищ на разных узлах.


интересно, каким тогда образом?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[27]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 28.04.06 10:16
Оценка:
Здравствуйте, AndrewVK, Вы писали:

GZ>>3. При этом, неплохо иметь ввиду следующее. Тот же DLinq не предоставляет средств обновления для объектов полученных в результате проекции.


AVK>Забавный ты мужик, однако. Сначала навязываешь LINQ неестественные ему модели, а потом жалуешься, что он для этого плохо подходит. Я тебе уже неоднократно писал — LINQ как таковой не предназначен для построения ООБД и O/R мепперов. Как только ты это поймешь, все надуманные проблемы LINQ сразу же исчезнут.

Речь идет не о LINQ а о DLinq. Надеюсь ты не будешь возражать что он содержит функциональность по предоставлению доступ к базе данных?
Re[28]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 28.04.06 10:19
Оценка:
Здравствуйте, GlebZ, Вы писали:

AVK>>Ты когда нибудь видел в SQL-серверах возможность править результат select?

GZ>Вьюхи instead of.
Не понял, и что смешного. Я сначало писал про update, тут спросили про select. Ну и ошибся. Правильный ответ функции в Oracle(как работают функции в MSSQL не знаю. Утверждать не буду, но возможно тоже).
Re[32]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 28.04.06 12:11
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Во-вторых, я могу иметь распределённую систему и не иметь при этом хранилищ на разных узлах.


Д>интересно, каким тогда образом?


Есть такая штука — база данных.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Файловые системы, файлы, приложения - устаревшие конц
От: Merle Австрия http://rsdn.ru
Дата: 28.04.06 12:52
Оценка:
Здравствуйте, Adopt, Вы писали:

A>Что такое таблица с B+ индексом?

Имелась ввиду таблица с индексом на основе B+ tree.
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[41]: Файловые системы, файлы, приложения - устаревшие кон
От: Merle Австрия http://rsdn.ru
Дата: 28.04.06 12:52
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Динамическая типизация это тоже не панацея

Ну, а что же ты тогда о ней заикался?

Д> Осталось только выяснить, что в ней плохо и нуждается в улучшении.

Выясняют уже больше пятнадцати лет. Успехов.

Д>А если не устраивают оба варианта, что ты предлагаешь делать?

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

Д>и он сейчас вполне благополучно применяется

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

M>>По кругу поехали?

Д>ага.
Тогда без меня.

Д> А кто сказал, что обработка новых записей по старым правилам — допустима?

Ну так не обрабатывай.

Д>К каким данным вот здесь у тебя нет доступа?

Ко всем.

Д>Менять код.

В сад.

Д>А в чем проблема то?

В том, чтобы делать методы на всякий случай.

Д>Потому что нет нормального языка запросов по объектам. Пока нет.

Вот когда будет, тогда и поговорим, а пока это все разговоры в пользу бедных.

Д>Уже сравнил. Реляционки за 1985 год совсем не порадовали меня своими фичами.

Опять не внимательно читаешь...

Д> Так что адью.

Сломался...
... [RSDN@Home 1.2.0 alpha rev. 619]
Мы уже победили, просто это еще не так заметно...
Re[42]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 29.04.06 04:21
Оценка:
Здравствуйте, Merle, Вы писали:

M>Сломался...


я вообще не любитель теологических диспутов...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[33]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 29.04.06 04:21
Оценка:
Здравствуйте, IT, Вы писали:

IT>Есть такая штука — база данных.


и что? Много ты видел больших распределенных систем, которые построены на базе данных?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[17]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 29.04.06 13:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Гм. Там все банально. Для B+tree мы, получив диапазон, очень быстро спускаемся к его левой границе и начинаем последовательное сканирование страниц. Поскольку листья образуют двусвязный список, это очень эффективно.

Да я все это понимаю. Просто в описанных нами элементарных операциях мы не имеем возможности получить диапазон.
S>Именно поэтому хэшиндексы и стали менее популярны — нет поддержки range scan, и нет побочного эффекта упорядоченности ключей.
Зависит от того, что мы имеем ввиду под хеш-индексом. Их достаточно много. Тот что здесь — имеетRe[18]: Настольная БД
Автор: GlebZ
Дата: 05.04.06
. Правда не без побочных эффектов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[34]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 29.04.06 16:48
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>и что? Много ты видел больших распределенных систем, которые построены на базе данных?


Много, иначе бы не говорил. Практически все проекты в которых я участвовал в последние несколько лет имеют либо кучу серверов приложений, либо (или в том числе) WebFarm и одну или несколько баз данных. Где несколько БД означает хранение разных, зачастую очень слабо или вообще не связанных между собой данных.

А ты много выидел больших распределённых систем, построенных ООП?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Файловые системы, файлы, приложения - устаревшие кон
От: dimon0981 США  
Дата: 29.04.06 18:42
Оценка:
Здравствуйте, GlebZ, Вы писали:


IT>>Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.

GZ>Во первых, отчего же все меньше баз опубликовано в интернете, и все больше SOA? Реляционка как серьезная распределенная база данных — практически неприменима.

Не стоит отождествлять SOA с OO и тем более с ООБД.
Все больше SOA? Похоже речь идет конктртно о веб-службах как о частном случае SOA.
Причина популярности веб-служб:
1) наличие стандартов
2) продвижение этой технологии большими конторами (IBM, HP, MS)
3) наличие огромного количества инструментальных средств для работы с ними (это следствие 2)

Если же отойти от веб-служб и посмотреть на SOA как на концепцию, то понятно, что она к ОО никакого отношения не имеет.
Re[13]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 29.04.06 19:44
Оценка:
Здравствуйте, dimon0981, Вы писали:

D>Не стоит отождествлять SOA с OO и тем более с ООБД.

А где ты такое видел?
D>Все больше SOA? Похоже речь идет конктртно о веб-службах как о частном случае SOA.
D>Причина популярности веб-служб:
D>1) наличие стандартов
D>2) продвижение этой технологии большими конторами (IBM, HP, MS)
D>3) наличие огромного количества инструментальных средств для работы с ними (это следствие 2)
4. Web-сервисы в большей степени отвечают свойствам компонентности и способны к самоописанию.
Это отнюдь не простой заговор корпораций с во главе W3C (первая версия была от W3C)
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[35]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 30.04.06 05:58
Оценка:
Здравствуйте, IT, Вы писали:

IT>Много, иначе бы не говорил. Практически все проекты в которых я участвовал в последние несколько лет имеют либо кучу серверов приложений, либо (или в том числе) WebFarm и одну или несколько баз данных. Где несколько БД означает хранение разных, зачастую очень слабо или вообще не связанных между собой данных.


Web farm — это, по твоему, распределенная система? Это всего лишь система распределения нагрузки. В ней нет ключевых признаков распределенной системы — ненадежность коммуникаций, большая стоимость и долгое время ожидания запроса между узлами, отсутствие синхронизированного времени.
Мягко говоря, это называется подменой условий задачи.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[36]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 30.04.06 06:12
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Web farm — это, по твоему, распределенная система?


Боюсь, у тебя несколько однобокое понятие о том, что такое распределённая система.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[37]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 02.05.06 03:45
Оценка:
Здравствуйте, IT, Вы писали:

IT>Боюсь, у тебя несколько однобокое понятие о том, что такое распределённая система.


скорее, у тебя слишком размытое. Ты просто путаешь распределенку с кластерами, хотя это очень разные вещи. Практически в любой литературе проводится различие между этими двумя вещами...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[38]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 02.05.06 04:00
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Боюсь, у тебя несколько однобокое понятие о том, что такое распределённая система.


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


Причём тут кластер вообще? Или по твоему веб-фарм == кластер?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[39]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 02.05.06 04:10
Оценка:
Здравствуйте, IT, Вы писали:

IT>Причём тут кластер вообще? Или по твоему веб-фарм == кластер?


э.... а мы под кластерами точно одно и то же понимаем?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[18]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.05.06 05:24
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>Да я все это понимаю. Просто в описанных нами элементарных операциях мы не имеем возможности получить диапазон.

"Нами" — это кем? Лично я написал ровно тот набор операций, который реализован, к примеру, в MS SQL.
GZ>Зависит от того, что мы имеем ввиду под хеш-индексом. Их достаточно много. Тот что здесь — имеетRe[18]: Настольная БД
Автор: GlebZ
Дата: 05.04.06
.

Че-то я почитал-почитал, так и не понял, как это хэш индекс даст упорядоченность ключей.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 02.05.06 12:02
Оценка:
Здравствуйте, Дарней, Вы писали:

IT>>Причём тут кластер вообще? Или по твоему веб-фарм == кластер?


Д>э.... а мы под кластерами точно одно и то же понимаем?


У нас с тобой вообще наблюдается поразительное несходство в понимании чего бы то ни было.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[41]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 02.05.06 12:23
Оценка:
Здравствуйте, IT, Вы писали:

IT> У нас с тобой вообще наблюдается поразительное несходство в понимании чего бы то ни было.


Бывает...
ну что ж, попробуем с другой стороны. В чем принципиальное отличие веб-ферм от кластеров, с твоей точки зрения?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[42]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 02.05.06 12:51
Оценка:
Здравствуйте, Дарней, Вы писали:

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


Может ну его? Приводить ссылки на вики и цитировать Lingvo мне не хочется. Доказывать что-то уже порядком надоело. Давай завяывать, давай? Ну пожалуйста!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Файловые системы, файлы, приложения - устаревшие кон
От: Дарней Россия  
Дата: 02.05.06 14:31
Оценка:
Здравствуйте, IT, Вы писали:

IT>Может ну его? Приводить ссылки на вики и цитировать Lingvo мне не хочется. Доказывать что-то уже порядком надоело. Давай завяывать, давай? Ну пожалуйста!


Нет там ничего в подтверждение твоего утверждения...
Ну если очень хочется, давай завязывать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[44]: Файловые системы, файлы, приложения - устаревшие кон
От: IT Россия linq2db.com
Дата: 02.05.06 14:36
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Нет там ничего в подтверждение твоего утверждения...


... в твоём понимании.

Д>Ну если очень хочется, давай завязывать.


Ok, завязали.
Если нам не помогут, то мы тоже никого не пощадим.
Re[34]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 02.05.06 17:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Хм. Не очень ясно, что же ты имеешь в виду. Я попробую развернуть здесь эту критику поподробнее:

S>- отсутствие внятной концепции метаданных. Классический SQL вообще не содержал средств работы с метаданными. Клиентское приложение должно было получить знания о таблицах/view и их колонках эзотерическим путем). Справедливости ради стоит отметить, что в новых версиях стандарта SQL работа с метаданными таки предусмотрена
Вопрос только насколько они действенны. Современная база данных это не только данные, но и поведение. Узнать о том, что данное поле заполняется автоматом с помощью триггера, можно только просмотрев реализацию триггеров. А информация о том что поле read only, или в каких случаях оно является read only, вполне полезно.
S>- малое внимание к связям. FK трактуются как декларативные ограничения, к которым довольно сложно получить доступ, в то время как это на самом деле first-class citizens. Фактически, объявление FK вводит новый тип данных — "ссылка на таблицу", и это должно быть очевидно и легкодоступно.
По поводу того, что нет информации о связях, согласен на все +1000. Но IMHO ты не совсем прав. Реляционка нуждается в ad-hoc запросах так как "ссылка на таблицу" недостаточное условие универсальности реляционки.
Ну например такой запрос вполне жизненен.
select *, ISNULL(organization.Name, citizen.Family) from document outer join organization on (document.signer = organization.id and document.sign_org=1)
outer join citizen on (document.signer = citizen.id and document.sign_org=0)
where document.signed is not null

FK — как "ссылка на таблицу" — недостаточен. Нужно что-то более полиморфное.
В принципе, в OODB это решается через наследование. Но тут легко получить, как ты выражаешься, выстрел в ногу. В случае оперативной памяти, мы легко получаем ссылку на экземпляр и его RTTI. В случае СУБД, экземпляр как таковой не инстанцирован, и получение экземпляра, или его ссылки — затруднено. IMHO Лучшим выходом в случае СУБД является явное указание конкретных типов который может адресовать ссылка. Указание же типа предка, подразумевает более широкий поиск возможного типа ссылки что не есть гуд.

S>- 100% отсутствие информации о структуре бинарных объектов. Тут уже точно пошла жесткая необходимость рыться в исходниках клиентского приложения для понимания сути blob.

S>Работы по поддержке пользовательских типов вместо blob и переносе хотя бы части семантики внутрь БД не слишком скоординированы. Насколько я знаю, попытки стандартизовать UDT есть, но реальная картина в мире СУБД печальна: каждый производитель тянет одеяло на себя. Кстати, стоит отметить полную бесперспективность данного подхода в отстутствие управляемой среды: исполнение пользовательского кода в контексте сервера, который должен обеспечивать высокую надежность — самоубийство.
Данные могут быть полуструктурированы(короче говоря, меняющеяся от blob'a к blob'у схема).

GZ>>2. Недостаток РСУБД. Недостаточная эффективность реляционной модели. Вряд ли что эффективней работает на строгоструктурированными данными чем РСУБД, но так как мы имеем данные огромного объема даже этого механизма не хватает. В ответ на это появились вычислимые поля на триггерах, материализованные вьюхи, временные таблицы и прочая лабуда.

S>Я бы не был так категоричен. Сама по себе реляционная модель не может обладать никакой эффективностью. Есть средства эффективной реализации некоторых выражений реляционной алгебры. Например, это индексы. Важно понимать, что индексы не являются частью реляционной модели.
Зависит от обстоятельств. Иногда оптимизаторы пользуются индексами как отношением.
S>Материализованное view — это паллиатив, попытка реализовать сразу несколько типов индексов, не встроенных в движок. Временные таблицы — это вообще нонсенс; это попытка обойти либо ограничения выразительности языка, либо ограничения оптимизатора. И если со вторым еще как-то можно смириться — оптимизаторы неуклонно совершенствуются, и нужда явно указывать способ хранения промежуточных результатов снижается, то проблема с первым напрямую связана с убогостью SQL. К этому пункту мы еще вернемся.
+1 Во первых, ты забыл вернуться к убогости SQL.
Во вторых, ты темповую таблицу меришь по реализации в MSSQL. Там ублюдочная реализация. Темповая таблица — это некоторый промежуточный результат для получения других конечных результатов и которая не требуют транзакционности. Данные для темповой таблицы могут быть собраны как внутри СУБД, так и с внешней стороны. А после этого ты можешь сделать несколько взаимосвязанных с этими промежуточными данными запросов. В MSSQL время жизни таких промежуточных данных — запрос. В Oracle — сессия. Во втором случае пользы больше. MARS, в принципе, должен решать эту проблему для внутренних данных, но не для внешних. И то, не полностью

S>Вместо расширения декларативной модели, комитет изобретает частные затычки — например, CTE. О, классно, мы теперь можем делать рекурсивные запросы, ура! Если бы SQL позволял писать table-valued функции с табличными параметрами, мы получили бы то же самое в качестве побочного эффекта. Увы и ах.

Меня волнует один вопрос. А как описывать/использовать статистику для рекурсивных запросов?

S>Это неверно. Инкапсуляция вовсе не означает криптологию: она фактически запрещает строить код, статически завязанный на подробности реализации, а вовсе не получать информацию о внутреннем устройстве кода. Ну, вот например, допустим компилятор С++ видит в некотором месте вызов метода A::a(). Соответствие областей видимости компилятор проверит первым делом, так что внешний код скомпилируется только если a() public, и т.п. Но сразу после выполнения этой проверки компилятор может забыть все эти модификаторы доступа. Если внутри этого метода всего лишь идет обращение к полю экземпляра, пусть даже и приватному, компилятор имеет полное право устранить вызов путем инлайнинга и выполнять прочие модификации. С точки зрения С++, private прячет интимности от кода, но не от компилятора. С точки зрения управляемой среды, оптимизатор всего лишь имеет права "врача, священника, и мужа" по отношению к коду хранимых сущностей, т.е. соответствующий reflection permission. Это никак не нарушает инкапсуляцию.

Я абсолютно согласен. Это было просто утверждение о реализации большинства OODB.

GZ>>6. Недостаток OOСУБД. Слишком сильная привязанность к таблицам и месту хранения. Во многом это усуглубляет недостаток РСУБД из пункта 2 полученный в наследство. Даже скажу, очень сильно усуглубляет.

S>Вот это я не очень понимаю. Это же неудачное стечение двух совершенно различных обстоятельств: отстутствие достаточно декларативного языка запросов, и отсутствие оптимизатора, который мог бы воспользоваться избыточной информацией в индексах.
Проблема в том, что объект в оперативной памяти может быть достаточно большим. Его основная цель быть полноценным экземпляром. Это процесс бесплатный если сравнить с падением производительности при чтении большого объекта в таблице. Поэтому, конечный тип может быть эфективнее если он сборный из двух и более таблиц. Вторая проблема — наследование. Join — отнюдь не самая легкая операция в СУБД, если хранить предка и потомка раздельно. В тоже время, если их хранить вместе, также невесело. На каждый тип свой запрос и свой проход по данным. При требовании, что объект поднятый с БД должен быть полноценным экземпляром подразумевает избыточность действий и данных.

GZ>>7. Недостаток OOСУБД. Объект который имеет состояние, и управляет им тяжел и неудобен в сопровождении. После того, как я перестал использовать в бизнес-объектах функционал реализующий работу с их состоянием, чессно-слово, обрел нирвану. Поэтому желательно разделение бизнес-объекта и бизнес-сервиса. Таким образом это улучшает сопровождаемость кода.

S>Я не уверен, что эта нирвана связана с неудобством прямого управления состоянием.
Здесь выйгрыш в том, что код более гибкий. На СУБД — у нас одна обработка. На клиенте, который объект получил через web-сервис, другая обработка. В каждом слое приложения можно сделать свою обработку бизнес-объекта в соответсвии с целью, которая заложена в бизнес-логику слоя. При этом, они зависимы только по интерфейсу бизнес-объекта, а не по методам его получения или методам работы с хранилищем.
S>Вообще, конечно же, статическая трактовка данных, принятая в RDBMS, сильно упрощает жизнь. Хотя это вовсе не 100% упрощения, и проблемы с сопровождением все равно есть. В самом оптимистичном случае, когда вносимые изменения не требуют модификации фактологической модели (т.е. мы, к примеру, все еще считаем "телефон" скалярным атрибутом сущности "клиент", а не заменяем это на связь многие-ко-многим), все равно есть риск нарваться на несовместимость логики, когда данные находятся в состоянии, валидном с точки зрения предыдущей модели, но недостижимом в новой модели.
Гы-гы. Собственно с помощью компонентной объектной модели можно скрыть факт о связи многие к многим, и о несовместимости логики за интерфейсом. Возможности не бесконечны но все таки более эффективны, чем при РСУБД.

GZ>>9. Предыдущий пункт сильно противоречит ad-hoc запросам в РСУБД в которых ты можешь взять любую таблицу, и сджоинить с любой другой таблицей. Правда при этом надо учитывать фактор индексов, без которых данная операция будет безбожно тормозить.

S>На практике, имхо, 99% джойнов непосредственно связаны с foreign key. Поэтому можно сосредоточиться на оптимизации именно этих запросов, а все остальное трактовать как дополнительные критерии отбора, применяемые к результатам этих нативных операций. Фишка именно в том, что потребность джойнить именно любую таблицу с любой возникает крайне редко. "Адхокность" запросов, я уверен, можно сильно ограничить без особого ущерба для функциональности. Более того, возможно, что наличие подобных ограничений принесет больше пользы, чем вреда, принуждая разработчика к повышению качества проектирования приложений.
Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.

GZ>>9. Все что можно уже выдумано до нас. В частности компонентность и модификаторы компонентности.

S>?
GZ>>10. Все что можно уже выдумано до нас. В частности версионификация. Объекты легко адаптируют в компонентной программе сразу для нескольких клиентов.
S>?
Фактически — это одно и тоже. Уже давно языки пытаются вынудить показывать интерфейс, а не реализацию. Реализация скрыта. Соответсвенно, клиенту подставляется тот интерфейс который ему нужен, а не тот который может обеспечить реализация в последней версии.

GZ>>12. Для оптимизатора запросов важна подробная информация.

S>Ну, с этим никто не спорит. Вообще здесь, как и много где еще, работает правило Парето: 80% успеха обеспечивается 20% усилий.
S>В частности, для RDBMS оказывается, что даже минимальной статистики (типа количества уникальных значений ключа индекса) достаточно для выбора планов, близких к оптимальным. Следующий шаг — построение гистограмм распределений — позволяет добиться еще некоторого сокращения лишних операций. Дополнительная семантическая оптимизация на основе данных о констреинтах позволяет улучшить планы в граничных случаях. В принципе, уже этой информации достаточно оптимизатору для того, чтобы почти не оставить шансов человеку на улучшение запросов.
То что ты описал, в принципе, оставляет шансы для человека. Данные редко изменяют свою статистику. А вот учет кэша страниц в оперативной памяти — это уже каюк.

S>Вменяемый ODBMS оптимизатор должен справляться не хуже. Все, что ему нужно — доступ к телу используемых методов. Все равно в итоге идет обращение к полям экземпляров и классов; поэтому особенной разницы в оптимизациях нет. С одной стороны, все кажется сложным — типичный "объектный" запрос будет иметь значительно более сложное AST, чем типичный реляционный.

Тут возникает следующий вопрос. Сможем ли мы перевести большинство методов в селективные предикаты? SQL с одной стороны много не позволяет. Хотя в нем можно делать предикаты о которых не существует статистики, но это редкость. Будет ли это редкостью в коде OODB, еще вопрос.

S>С другой стороны, есть очень хороший шанс использовать кэш. В частности, если посмотреть на статистику Jit для Януса, то окажется, что в этом приложении обработано всего ~2600 методов. Новые методы будут появляться крайне редко (относительно количества вызовов этих методов), а, значит, можно не выполнять дорогостоящий анализ каждый раз.

IMHO Тут может случиться казус с семантической оптимизацией. В данных условиях, подозреваю, что будет много повторяющихся предикатов, которые можно будет поубивать. И скорее всего, нужно будет убивать промежуточные объекты, основной смысл которых предоставить путь от таблицы к таблице.
Re[36]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 04.05.06 08:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

GZ>>По поводу того, что нет информации о связях, согласен на все +1000. Но IMHO ты не совсем прав. Реляционка нуждается в ad-hoc запросах так как "ссылка на таблицу" недостаточное условие универсальности реляционки.

S>С точки зрения реляционки, все (почти) в порядке. Все будет полностью в порядке только при расширении трактовки понятия Foreign Key так, чтобы оно могло ссылаться не только на хранимую таблицу, но и на произвольное реляционное выражение.
Не понял???? Ты предлагаешь вернуться к ad-hoc запросам?

S>Это мы уже забредаем на территорию ODBMS. Реляционка пренебрегает такими концепциями, как наследование и полиморфизм.

Ага. Вместо этого она предлагает ad-hoc запросы и трансформацию схемы.

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

Жуть.

S>Запрос, приведенный тобой выше, будет записан значительно короче, но при выполнении автоматически раскрыт в

S>
S>select *, ResponsibleParty.Name from document outer join 
S>(
S>  select id, Name from organization
S>  union 
S>  select id, Family from citizen
S>)
S>where document.signed is not null
S>

Да уж. А запрос-то неприятный. У меня большие подозрения что оптимизатор не сможет развести union сквозь outer join(точнее не подозрения, на всякий случай проверил на MSSQL2005). А соответсвенно, не сможет включить в оптимизации планы в которых идет outer join(document, organization) и outer join(document, citizen) + union(res1,res2). При маленькой таблице document — это был бы лучший план. А в данном случае мы всегда обязаны поднимать и конкатенировать всех наследников.Запрос достаточно показателен.
Я имел ввиду что в OODB в качестве reference будет object, и как результат мы поднимем всю базу данных. И второе, к типу может быть подцеплен новый подтип. При этом это сильно может повлиять на работу запросов незаметно для разработчика.

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

А смысл? Способ получения может быть не только внутренним, но и внешним.
S>Если бы это была не таблица, а ссылка на реляционное выражение, то у оптимизатора оставался бы шанс как-то уменьшить стоимость запроса.
Недетерменировано? Даже в случае с внутренними данными у нас получается все равно — чистая эвристика. Оптимизатор находит что такой подзапрос был, следовательно можно использовать именно его данные. Чудно. Но остается вопрос того, что исходные данные на момент второго запроса могли измениться. Как поступить оптимизатору, непонятно.

GZ>>Меня волнует один вопрос. А как описывать/использовать статистику для рекурсивных запросов?

S>Точно так же, как и для обычных join. А что тебя беспокоит?
Пока сам не разобрался. Пока придавлю эту тему.

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

S>Неа. В хорошей ODBMS должны реально инстанцироваться лишь немногие объекты.
Имеется ввиду ООП.

S>Это все происходит от того заблуждения, что основной операцией является разрешение ссылки. Конечно, если не давать описывать более осмысленные операции, то во-первых придется руками указывать СУБД какой объект поднимать, а во-вторых ей придется поднимать полный объект, т.к. она не знает, что именно я собрался с ним делать.

S>Вот, например, РСУБД при удачном стечении обстоятельств может вообще обходиться без чтения таблицы ("инстанцирования кортежей"), если для выполнения запроса хватает данных в индексе. Точно так же должна работать ODBMS — достаточно дать ей доступ к коду. Тогда она сможет строить код, который работает в основном с данными на диске, но так, чтобы конечный результат был неотличим от полного перебора честных инстансов с соответствующими вызовами.
Тут вопрос не в работе оптимизатора. Тут вопрос в самой системе хранения. С маленькими неширокими таблицами — sql работает быстрее. Проблема в том, что при table scan стоимость в прямой зависимости от объема объекта. Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.

GZ>>Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.

S>Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
Чего-то я здесь его не увидел.
select otdel from otdel, (select avg(employer.age) as avg_age, employer.otdel 
from employer group by employer.otdel) emp, employer boss
where otdel.id=emp.otdel and otdel.boss=boss.id and emp.avg_age>boss.age

Так?

GZ>>Тут возникает следующий вопрос. Сможем ли мы перевести большинство методов в селективные предикаты?

S>Ну, во-первых они не должны иметь побочных эффектов, иначе — сразу InvalidOperationException.
GZ>>SQL с одной стороны много не позволяет.
S>Во-вторых, главное — выкусить "индексируемую" часть предиката, а остальное оставить в виде residual и честно вычислять.
А если у нас что-то типа этого:
IEnumerable<IEnumerable<T>> GetEnumerator(int i)
{
while (i!=0)
{
switch (i)
{
    case 1:
       enumer=GetNewEnumFrom1(ref i);
       yield return enumer;
       break;
    case 2:
       enumer=GetNewEnumFrom2(ref i);
       yield return enumer;
       break;
......
}
}

Все функции не обновляют состояния но функции GetNewFrom1 и GetNewFrom2 содержат разные подзапросы. Внедрить в движок операцию ветвления конечно можно, но статистики по нему не получишь. И трансформировать его безопасно, нужно методы придумывать(я по крайней мере о таких не слышал). Так что получается перечень побочных эффектов несколько больше. Или я до чего-то недопер?

GZ>>IMHO Тут может случиться казус с семантической оптимизацией. В данных условиях, подозреваю, что будет много повторяющихся предикатов, которые можно будет поубивать.

S>А что значит "поубивать"?
Упрощение.
GZ>>И скорее всего, нужно будет убивать промежуточные объекты, основной смысл которых предоставить путь от таблицы к таблице.
S>Ты имеешь в виду сбор мусора?
Упрощение.
При семантической оптимизации(в некоторых источниках его причисляют к логической, что наверно правильней) рассчитываются диапазоны предикатов и при пересечении сокращается их число. То есть a>10 and b>=20 and a>b можно сократить до a>20 and b=20. Таким же образом могут сокращаються и промежуточные таблицы. При этом могут учитываться навешанные на данные констрейнты(но так мало кто умеет делать).
Re[37]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.05.06 00:58
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>Не понял???? Ты предлагаешь вернуться к ad-hoc запросам?
А мы от них никуда и не уходим. Напомню, что тут пока речь про реляционку и ее развитие, а не про то, чем ее заменить. Это просто логическое развитие реляционной алгебры, точнее ее реализации в рамках SQL.

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

GZ>Жуть.
Ничего хуткого. Напомню: мы говорим про сверхмалые объемы редкоменяющихся данных. О, кстати — тогда ж можно сделать на Селковских диапазонах! И это все в предположении, что список классов не помещается полностю в памяти, и нам надо что-то оптимизировать. В жизни это будет обход дерева в памяти, и работать оно будет со скоростью света.
GZ>Да уж. А запрос-то неприятный. У меня большие подозрения что оптимизатор не сможет развести union сквозь outer join(точнее не подозрения, на всякий случай проверил на MSSQL2005). А соответсвенно, не сможет включить в оптимизации планы в которых идет outer join(document, organization) и outer join(document, citizen) + union(res1,res2).
Это очень странно. Эта оптимизация известна от зари времен. возможно, надо покрутить вокруг Union All. Но это все неважно — мы-то говорим о нашем оптимизаторе, а он прекрасно поймет, что ID глобально уникальны, и развалит запрос именно на union(join(A, B1), join(A, B2)).
GZ>Я имел ввиду что в OODB в качестве reference будет object, и как результат мы поднимем всю базу данных.
Ну естественно — если в качестве типа reference поставить object, оптимизатор присядет. Хотя я думаю, что и это вопрос разрешимый.
GZ>И второе, к типу может быть подцеплен новый подтип. При этом это сильно может повлиять на работу запросов незаметно для разработчика.
Этого я не боюсь. Нормальный tool с показом планов запросов является предметом первой необходимости для разработчика и DBA уже очень давно. Глупо надеяться, что в более сложной ODBMS удастся обойтись без него.

GZ>А смысл? Способ получения может быть не только внутренним, но и внешним.

С точки зрения RDBMS ничего внешнего нет. А если и есть — это тривиальный частный случай, когда действительно нужна временная таблица.
S>>Если бы это была не таблица, а ссылка на реляционное выражение, то у оптимизатора оставался бы шанс как-то уменьшить стоимость запроса.
GZ>Недетерменировано?
Все детерминированно. У тебя же не возникает проблемы с view?
GZ>Даже в случае с внутренними данными у нас получается все равно — чистая эвристика.
Никаких эвристик. Просто работа не с данными, а с выражением.

GZ>Тут вопрос не в работе оптимизатора. Тут вопрос в самой системе хранения. С маленькими неширокими таблицами — sql работает быстрее.

GZ>Проблема в том, что при table scan стоимость в прямой зависимости от объема объекта.
Проблема только в том, что table scan должен быть нужен как можно реже. Кроме того, даже при необходимости делать table scan можно избежать необходимости инстанцировать полные объекты.
GZ>Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.
В случае bookmark lookup матожидание количества зачитанных страниц примерно совпадает с количеством букмарков

GZ>>>Если учесть полиморфизм ссылок(то о чем говорил вначале), то я согласен с тезисом что ad-hoc запросы избыточны и ненужны. IMHO Единственными пользователями ad-hoc запросов являются сами разработчики, и то, только те которые знают SQL.

S>>Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.
GZ>Чего-то я здесь его не увидел.
Чего ты не увидел?
GZ>
GZ>select otdel from otdel, (select avg(employer.age) as avg_age, employer.otdel 
GZ>from employer group by employer.otdel) emp, employer boss
GZ>where otdel.id=emp.otdel and otdel.boss=boss.id and emp.avg_age>boss.age
GZ>

GZ>Так?
Все правильно.
GZ>А если у нас что-то типа этого:
GZ>
GZ>IEnumerable<IEnumerable<T>> GetEnumerator(int i)
GZ>{
GZ>while (i!=0)
GZ>{
GZ>switch (i)
GZ>{
GZ>    case 1:
GZ>       enumer=GetNewEnumFrom1(ref i);
GZ>       yield return enumer;
GZ>       break;
GZ>    case 2:
GZ>       enumer=GetNewEnumFrom2(ref i);
GZ>       yield return enumer;
GZ>       break;
GZ>......
GZ>}
GZ>}
GZ>

GZ>Все функции не обновляют состояния но функции GetNewFrom1 и GetNewFrom2 содержат разные подзапросы.
Никто не спорит — можно и огурцом зарезаться. Подобный код приведет к потере эффективности, потому что его придется честно исполнять. Аналогом этому являются циклы и курсоры в MS SQL. Ими тоже можно довести сервак до кондратия. Ну, только в ОДБМС это будет работать несколько шустрее благодаря компиляции в нативный код, а не интерпретации скрипта.
GZ>Внедрить в движок операцию ветвления конечно можно, но статистики по нему не получишь. И трансформировать его безопасно, нужно методы придумывать(я по крайней мере о таких не слышал). Так что получается перечень побочных эффектов несколько больше. Или я до чего-то недопер?
Самое главное, что мы можем проинлайнить все эти GetNewEnumFrom1, и попробовать свернуть их во что-то человеческей
GZ>При семантической оптимизации(в некоторых источниках его причисляют к логической, что наверно правильней) рассчитываются диапазоны предикатов и при пересечении сокращается их число. То есть a>10 and b>=20 and a>b можно сократить до a>20 and b=20. Таким же образом могут сокращаються и промежуточные таблицы. При этом могут учитываться навешанные на данные констрейнты(но так мало кто умеет делать).
А, ну, семантика конечно тоже. Я про это читал. Но то, что я читал относительно семантических оптимизаций по отношению к ООДБМС — детский лепед. Люди тщательно пытаются придумать способ сообщить системе, что у менеджера зарплата выше 1000 уев, чтобы она при выполнении запросов типа select * from employee where salary < 0 их не сканировала.
Семантика играет огромную роль в распределенных базах, где сама отправка лишнего запроса — удовольствие дорогое. В обычном случае должна помогать все та же статистика. Семантические оптимизации, конечно, могут помочь откусить частные случаи (типа когда мы ищем null в not null поле). Относительно поглощения предикатов — не уверен, что оно будет встречаться в ОДБМС чаще, чем в RDBMS. Там разве что будут всякие "проносы эквивалентности", когда из ( a=b and b=с) делается (a=с and b is not null).
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[38]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 05.05.06 09:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

GZ>>Не понял???? Ты предлагаешь вернуться к ad-hoc запросам?

S>А мы от них никуда и не уходим. Напомню, что тут пока речь про реляционку и ее развитие, а не про то, чем ее заменить. Это просто логическое развитие реляционной алгебры, точнее ее реализации в рамках SQL.
Эффективность FK — на технологическом уровне легко увеличить. А вот эффективность custom sql запроса — труднее. И сразу встанет вопрос корректности такого custom sql запроса. Надеюсь каскадное удаление мы не отменяем?

S>О, кстати — тогда ж можно сделать на Селковских диапазонах!

Меня Селковские диапазоны уже бесят. Весьма дурной алгоритм. Лучше уж dewey или ordpath. Там возможности оптимальной работы с индексом больше, и линейное добавление объектов.

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

GZ>>Да уж. А запрос-то неприятный. У меня большие подозрения что оптимизатор не сможет развести union сквозь outer join(точнее не подозрения, на всякий случай проверил на MSSQL2005). А соответсвенно, не сможет включить в оптимизации планы в которых идет outer join(document, organization) и outer join(document, citizen) + union(res1,res2).
S>Это очень странно. Эта оптимизация известна от зари времен. возможно, надо покрутить вокруг Union All. Но это все неважно — мы-то говорим о нашем оптимизаторе, а он прекрасно поймет, что ID глобально уникальны, и развалит запрос именно на union(join(A, B1), join(A, B2)).
Ага. Ты правильно указал что RDBMS не пользуется информацией о глобальной уникальности ключей. Еще они, что они не пользуются информацией о том, что связь является строго 1 к 1 и нечасто пользуются информацией, о том что наличие связанного ключа обязательно. Как результат outer join не переводится в inner join что сужает оптимизацию.

S>Ну естественно — если в качестве типа reference поставить object, оптимизатор присядет. Хотя я думаю, что и это вопрос разрешимый.

Вот именно. О том, что этот вопрос нужно решать я и говорю.

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

S>Этого я не боюсь. Нормальный tool с показом планов запросов является предметом первой необходимости для разработчика и DBA уже очень давно. Глупо надеяться, что в более сложной ODBMS удастся обойтись без него.
Решать концептуальную проблему только тулзами, по моему не очень хорошо. Решить вопрос в принципе легко. Нужно просто указать какие объекты могут быть подписантами, а какие нет. И не на уровне наследования, а атрибутивно.

S>Все детерминированно. У тебя же не возникает проблемы с view?

С обычными view? Возникает. Допустим, у нас есть 5 запросов. Часть запроса одинакова для всех, и достаточно тяжелая. Эту одинаковую для всех часть в качестве отношения выгружаем в нетранзакционную таблицу. Осталные делаются относительно данной таблицы. Вероятность того, что для двух запросов оптимизатор окажется умнее человека, и будет сгенерирован два различных запроса более эффективных чем данный способ велика. Для пяти запросов ничтожна.

S>Проблема только в том, что table scan должен быть нужен как можно реже.

Зависит от многих обстоятельств.

S>Кроме того, даже при необходимости делать table scan можно избежать необходимости инстанцировать полные объекты.

Да я не говорю о инстанцировании полных объектов. Я говорю именно о доступе к данным. Если тебе нужно пройтись table scan по одному полю, и у тебя объект размером со страницу, то у тебя будет стоимость операций ввода-вывода в два раза больше чем в случае если объект занимает полстраницы.

GZ>>Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.

S>В случае bookmark lookup матожидание количества зачитанных страниц примерно совпадает с количеством букмарков
Для больших данных да. По мере уменьшения таблиц, мат.ожидание уменьшается а КПД кэша страниц увеличивается.

S>>>Ну, на самом деле есть же тета-джойны, и от них никуда не уйдешь. "Выбрать те отделы, где средний возраст сотрудников выше, чем возраст начальника отдела". здесь использованы два FK и один предикат с неравенством. Впрочем, он в любом случае будет применен последним — после group by и join.

GZ>>Чего-то я здесь его не увидел.
S>Чего ты не увидел?
тета-джоины

S>Никто не спорит — можно и огурцом зарезаться. Подобный код приведет к потере эффективности, потому что его придется честно исполнять. Аналогом этому являются циклы и курсоры в MS SQL. Ими тоже можно довести сервак до кондратия. Ну, только в ОДБМС это будет работать несколько шустрее благодаря компиляции в нативный код, а не интерпретации скрипта.

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

S>Самое главное, что мы можем проинлайнить все эти GetNewEnumFrom1, и попробовать свернуть их во что-то человеческей

+1. Только я подумал, в теоретически и такое можно перевести в систему команд с множествами+ветвления. Правда систему команд придется увеличивать, и трансформация запроса ограничена.

S>Относительно поглощения предикатов — не уверен, что оно будет встречаться в ОДБМС чаще, чем в RDBMS.

Я уверен. В случае RDBMS — у человека полный запрос перед глазами. В случае ODBMS — запрос инкапсулирован по задействованным объектам. Требования для оптимизатора ODBMS выше чем для RDBMS, а управляемость человеком хуже.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[39]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.05.06 09:49
Оценка:
Здравствуйте, GlebZ, Вы писали:

S>>О, кстати — тогда ж можно сделать на Селковских диапазонах!

GZ>Меня Селковские диапазоны уже бесят. Весьма дурной алгоритм. Лучше уж dewey или ordpath. Там возможности оптимальной работы с индексом больше, и линейное добавление объектов.
Кинь в меня ссылкой на них. А то туплю
GZ>Ага. Ты правильно указал что RDBMS не пользуется информацией о глобальной уникальности ключей.
Это от того, что нет способа ей об этом сказать.
GZ>Еще они, что они не пользуются информацией о том, что связь является строго 1 к 1 и нечасто пользуются информацией, о том что наличие связанного ключа обязательно.
А вот это они делать должны.
GZ>Как результат outer join не переводится в inner join что сужает оптимизацию.
И это тоже должно делаться. Неужто MS SQL Server до сих пор не заменяет outer на inner? В конкретном случае проблема именно семантическая; ODBMS оптимизатор может просто сразу генерировать запрос с юнион от джойнов.

GZ>Вот именно. О том, что этот вопрос нужно решать я и говорю.

Один из вариантов решения: включать тип в ссылку. Это позволит иметь статистику и вообще не сканировать незадействованные объекты, а также улучшать все прочие планы.

GZ>Решать концептуальную проблему только тулзами, по моему не очень хорошо.

Здесь нет никакой концептуальной проблемы. Эффективность ОДБМС должна точно так же рулиться индексами, как и RDBMS. И точно так же никакая СУБД не станет сама придумывать эти индексы.
GZ>Решить вопрос в принципе легко. Нужно просто указать какие объекты могут быть подписантами, а какие нет. И не на уровне наследования, а атрибутивно.
Я в это не верю. В ООП крайне не рекомендуется делать ссылку "или на бузину, или на дядьку". Предполагается, что у объектов есть что-то общее. А ты фактически предлагаешь вместо того, чтобы явно это "что-то общее" определять, использовать везде ссылки на object и атрибутами размечать, кто на кого должен ссылаться. Мне не нравится такая реализация. Я бы предпочел, чтобы семантика в первую очередь определялась объектной моделью.

S>>Все детерминированно. У тебя же не возникает проблемы с view?

GZ>С обычными view? Возникает. Допустим, у нас есть 5 запросов. Часть запроса одинакова для всех, и достаточно тяжелая. Эту одинаковую для всех часть в качестве отношения выгружаем в нетранзакционную таблицу. Осталные делаются относительно данной таблицы. Вероятность того, что для двух запросов оптимизатор окажется умнее человека, и будет сгенерирован два различных запроса более эффективных чем данный способ велика. Для пяти запросов ничтожна.
Как раз наоборот. Вероятность того, что один и тот же план будет оптимален в пяти запросах, значительно ниже, чем в двух.

GZ>Да я не говорю о инстанцировании полных объектов. Я говорю именно о доступе к данным. Если тебе нужно пройтись table scan по одному полю, и у тебя объект размером со страницу, то у тебя будет стоимость операций ввода-вывода в два раза больше чем в случае если объект занимает полстраницы.

Это если у меня нет индекса по этому полю

GZ>>>Да и в случае bookmark lookup при поднятии 50 ссылок, при больших объектах более высока вероятность что придется поднимать 50 страниц.

S>>В случае bookmark lookup матожидание количества зачитанных страниц примерно совпадает с количеством букмарков
GZ>Для больших данных да. По мере уменьшения таблиц, мат.ожидание уменьшается а КПД кэша страниц увеличивается.
Картина также улучшается для малоселективных запросов: очевидно, что если полная длина таблицы = 500 страниц, bookmark lookup для 10000 записей все равно больше этих 500 страниц не зачитает (ну кроме опять же экстремального случая бесконечно большой по сравнению с размером кэша таблицы)

GZ>тета-джоины

Тета-джойн — это операция соединения по произвольному предикату. Вот так перепиши запрос:
select otdel from otdel 
inner join (select avg(employer.age) as avg_age, employer.otdel from employer group by employer.otdel) emp (on otdel.id=emp.otdel)
inner join employer boss on (otdel.boss=boss.id and emp.avg_age>boss.age)


S>>Относительно поглощения предикатов — не уверен, что оно будет встречаться в ОДБМС чаще, чем в RDBMS.

GZ>Я уверен. В случае RDBMS — у человека полный запрос перед глазами. В случае ODBMS — запрос инкапсулирован по задействованным объектам. Требования для оптимизатора ODBMS выше чем для RDBMS, а управляемость человеком хуже.
Угу. Но это как раз то, чего мы хотим получить — нормальный abstraction с минимальным penalty.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 05.05.06 13:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>>>О, кстати — тогда ж можно сделать на Селковских диапазонах!

GZ>>Меня Селковские диапазоны уже бесят. Весьма дурной алгоритм. Лучше уж dewey или ordpath. Там возможности оптимальной работы с индексом больше, и линейное добавление объектов.
S>Кинь в меня ссылкой на них. А то туплю
ordpath. Что касается dewey, то это облегченная версия ordpath без упорядоченности childs. В следующем номере rsdn будет статья.

S>Это от того, что нет способа ей об этом сказать.

+1
GZ>>Еще они, что они не пользуются информацией о том, что связь является строго 1 к 1 и нечасто пользуются информацией, о том что наличие связанного ключа обязательно.
S>А вот это они делать должны.
Oracle не умеет. MSSQL говорят иногда пользуется информацией о индексах. Надо проверять, знаю только по слухам.

GZ>>Вот именно. О том, что этот вопрос нужно решать я и говорю.

S>Один из вариантов решения: включать тип в ссылку. Это позволит иметь статистику и вообще не сканировать незадействованные объекты, а также улучшать все прочие планы.
+1.

GZ>>Решать концептуальную проблему только тулзами, по моему не очень хорошо.

S>Здесь нет никакой концептуальной проблемы. Эффективность ОДБМС должна точно так же рулиться индексами, как и RDBMS. И точно так же никакая СУБД не станет сама придумывать эти индексы.
Проблема не в индексах, а в количестве операций. И кстати, все дело движется к тому, что СУБД в будущем будет сам генерить индексы. Таких работ много.


S>Я в это не верю. В ООП крайне не рекомендуется делать ссылку "или на бузину, или на дядьку". Предполагается, что у объектов есть что-то общее. А ты фактически предлагаешь вместо того, чтобы явно это "что-то общее" определять, использовать везде ссылки на object и атрибутами размечать, кто на кого должен ссылаться. Мне не нравится такая реализация. Я бы предпочел, чтобы семантика в первую очередь определялась объектной моделью.

Ну можно декларативно обозначать, если класс реализует интерфейс ICanSign. К сожалению при написании OODBMS интерфейсы не были так популярны.

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

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

GZ>>Да я не говорю о инстанцировании полных объектов. Я говорю именно о доступе к данным. Если тебе нужно пройтись table scan по одному полю, и у тебя объект размером со страницу, то у тебя будет стоимость операций ввода-вывода в два раза больше чем в случае если объект занимает полстраницы.

S>Это если у меня нет индекса по этому полю
Ну, индексы это отдельная песня. Хотя в зависимости от кластеризованности таблицы относительно индекса, СУБД часто считают дешевле пройти через TableScan. На 2 индексах в or предикате его вполне можно получить.

S>Картина также улучшается для малоселективных запросов: очевидно, что если полная длина таблицы = 500 страниц, bookmark lookup для 10000 записей все равно больше этих 500 страниц не зачитает (ну кроме опять же экстремального случая бесконечно большой по сравнению с размером кэша таблицы)

+1

GZ>>тета-джоины

S>Тета-джойн — это операция соединения по произвольному предикату. Вот так перепиши запрос:
Oops. Я думал что ты берешь именно частный случай декартового произведения. Такое тоже есть в оптимизаторах, когда он самовольно решает что декартово произведение лучший способ исполнения запроса.
Re[19]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 05.05.06 13:36
Оценка:
Здравствуйте, Sinclair, Вы писали:
GZ>>Зависит от того, что мы имеем ввиду под хеш-индексом. Их достаточно много. Тот что здесь — имеетRe[18]: Настольная БД
Автор: GlebZ
Дата: 05.04.06
.

S>Че-то я почитал-почитал, так и не понял, как это хэш индекс даст упорядоченность ключей.
Sorry. Забыл про сообщения. Ключи упорядочены так как в значении содержится индекс ячейки в таблице, где лежат физический адрес строки.
Re[41]: Файловые системы, файлы, приложения - устаревшие кон
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.05.06 01:54
Оценка:
Здравствуйте, GlebZ, Вы писали:
GZ>ordpath. Что касается dewey, то это облегченная версия ordpath без упорядоченности childs. В следующем номере rsdn будет статья.
Спасибо.
S>>А вот это они делать должны.
GZ>Oracle не умеет. MSSQL говорят иногда пользуется информацией о индексах. Надо проверять, знаю только по слухам.
Я имею в виду — использовать наличие not null FK для конверсии outer join в inner. Тут даже индекс не нужен.

GZ>Проблема не в индексах, а в количестве операций.

Пойми, что операций не будет больше, чем для РДБМС с аналогичной структурой. Как раз вся идея в том, чтобы в случае отсутствия наследования ОБД превращалась в нормальную реляционную, с аналогичной эффективностью. И только введение лишних сложностей будет приводить к плавному снижению производительности.
GZ>И кстати, все дело движется к тому, что СУБД в будущем будет сам генерить индексы. Таких работ много.
Ну, идея-то конечно интересная. Но это все равно сводится к тулам.

S>>Я бы предпочел, чтобы семантика в первую очередь определялась объектной моделью.

GZ>Ну можно декларативно обозначать, если класс реализует интерфейс ICanSign. К сожалению при написании OODBMS интерфейсы не были так популярны.
Ну так это же совсем другое дело! Лично я считаю, что наличие интерфейсов — вещь безусловно правильная и необходимая. Только интерфейсы позволят делать интегрируемые решения. Типа добавил к серверу модуль "Advanced HR" — и у тебя аттестации и карьерные планы. Добавил "Project Management" — и у тебя люди могут участвовать в проектах; причем неважно, стоят у тебя Simple HR или Advanced HR. Добавил Customer Relations — и у тебя в заказах не строчки "физ. лицо", а ссылки на кастомеров с историей взаимоотношений...

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

А, вот ты что имеешь в виду. Это только в том случае, если это отношение в каждом из запросов нужно нам все в том же виде. Шансов на это в 5 запросах подряд — очень мало. Скорее всего мы будем делать join этого отношения с разными отношениями; и есть хороший риск использовать в каждом случае только часть данных. Если бы это было view, то оптимизатор в каждом случае бы мог это учитывать.
Кроме того, помни, что хранимое отношение отжирает дорогие ресурсы.

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

Не, я о логическом операторе, а не о физическом. Просто обычно оптимизаторы тета-джойн превращают в конвеер из естественного ('=') соединения (или декарта, если нет подходящего предиката) и фильтра. Именно это я и имел в виду — в приведенном примере оператор > скорее всего будет выполняться самым последним и безо всяких индексов.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: Файловые системы, файлы, приложения - устаревшие кон
От: GlebZ Россия  
Дата: 06.05.06 06:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

GZ>>Oracle не умеет. MSSQL говорят иногда пользуется информацией о индексах. Надо проверять, знаю только по слухам.

S>Я имею в виду — использовать наличие not null FK для конверсии outer join в inner. Тут даже индекс не нужен.
В случае наличия DEFFERED режима(то бишь отложенной проверки ограничений целостности) — это невозможно.

GZ>>Проблема не в индексах, а в количестве операций.

S>Пойми, что операций не будет больше, чем для РДБМС с аналогичной структурой. Как раз вся идея в том, чтобы в случае отсутствия наследования ОБД превращалась в нормальную реляционную, с аналогичной эффективностью. И только введение лишних сложностей будет приводить к плавному снижению производительности.
Операций не будет больше с аналогичной структурой. Но в RDBMS значительно проще разбить таблицу на две, и использовать их связынными 1:1.

GZ>>И кстати, все дело движется к тому, что СУБД в будущем будет сам генерить индексы. Таких работ много.

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

S>Ну так это же совсем другое дело! Лично я считаю, что наличие интерфейсов — вещь безусловно правильная и необходимая. Только интерфейсы позволят делать интегрируемые решения. Типа добавил к серверу модуль "Advanced HR" — и у тебя аттестации и карьерные планы. Добавил "Project Management" — и у тебя люди могут участвовать в проектах; причем неважно, стоят у тебя Simple HR или Advanced HR. Добавил Customer Relations — и у тебя в заказах не строчки "физ. лицо", а ссылки на кастомеров с историей взаимоотношений...

Ага. Только я бы еще рассмотрел вопрос миксинов. Фактически данную функциональность можно нормализовать в отдельную таблицу. Наверняка можно и логику выделить.

S>А, вот ты что имеешь в виду. Это только в том случае, если это отношение в каждом из запросов нужно нам все в том же виде. Шансов на это в 5 запросах подряд — очень мало. Скорее всего мы будем делать join этого отношения с разными отношениями; и есть хороший риск использовать в каждом случае только часть данных. Если бы это было view, то оптимизатор в каждом случае бы мог это учитывать.

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


S>Не, я о логическом операторе, а не о физическом. Просто обычно оптимизаторы тета-джойн превращают в конвеер из естественного ('=') соединения (или декарта, если нет подходящего предиката) и фильтра. Именно это я и имел в виду — в приведенном примере оператор > скорее всего будет выполняться самым последним и безо всяких индексов.

Не люблю я такие цикличные зависимости.
... << RSDN@Home 1.2.0 alpha rev. 0>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.