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

IB>>Это-то понятно. Тем не менее, вопрос был задан совершенно четко — что делать с тем, что непонятно, когда какие данные нужны и когда они будут загружены?
C>Использовать ленивую загрузку.
Не, ты не понял — в следствии ленивой загрузки мне по прежнему не понятно, что, когда и почему будет загружено.

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

C> Так как множество wire-протоколов баз данных — не threadsafe и не параллельные. Ну и JDBC-драйверы, соответственно, тоже не-threadsafe.
Причем тут протоколы? Меня это не парит совешенно, синхронизацией пусть база занимается, у нее это получается лучше всех.

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

IB>>>Вот в этом-то и заключается их фатальный недостаток и именно по этому, они являются тупиковой ветвю развития, так как работа эта вредная и бесполезная.
C>>Не, это RDB являются тупиковой ветвью, пережитком старого COBOLьного прошлого.

IT>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.

Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google. Это уже в ближайшие годы станет популярной и очень серьезной альтернативой RDB, особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают. Сейчас — они поднимаются по хайпу, скоро будут на пике.

Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее, практически весь геморрой, знакомый по RDB, отсутствует by design. Сочетание чрезвычайной простоты, и одновременно — большой гибкости. Обрати внимание, там чрезвычайно простая модель, много времени не займет. За полчаса будешь знать все. И не надо мне говорить про то, что там все запросы делаются через REST, а это медленно . К модели данных это не относится, а CouchDB демонстрирует пока только потенциал технологии.

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

C>>Использовать ленивую загрузку.
IB> Не, ты не понял — в следствии ленивой загрузки мне по прежнему не понятно, что, когда и почему будет загружено.
Ну отключаем ленивую загрузку и смотрим откуда исключения прилетят.

C>>А так ведь всё равно придётся, хоть ты с напрямую в сетевой провод биты насвистывай.
IB>Чтобы не пришлось, надо не насвистывать, а явно открывать и закрывать соединение с базой при каждом обращении — дешево и сердито, и никакой ручной синхронизации потоков с приседаниями вокруг сессий.
Ну да, и при этом теряем границы транзакций (потенциальные спецэффекты, привет!).

В Hibernate так при желании тоже делается — пишется LazyLoadingHandler, который каждый раз открывает новую сессию на один запрос.

C>> Так как множество wire-протоколов баз данных — не threadsafe и не параллельные. Ну и JDBC-драйверы, соответственно, тоже не-threadsafe.
IB>Причем тут протоколы? Меня это не парит совешенно, синхронизацией пусть база занимается, у нее это получается лучше всех.
У Андрея проблема в том, что с одним соединением идёт работа из нескольких потоков. Все известные БД на таком use-case'е глючат.

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

C> Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.
Есть. Фундаментальная причина заключается ровно в том, что OODB жестко привязывает поведение и структуру к данным, а срок жизни данных сильно больше навязанного им поведения, и за их время жизни интерпретация меняется по многу раз. Так что привязывать какое-то конкретное поведение к данным — дурная затея. Во-первых, меняя в десятый раз поведение данные нужно оставлять неизменными. Во-вторых, добавляя новое поведение, надо его просто добавлять, а не менять старое и на накручивать поверх старого, при этом данные должны быть по прежнему неизменными. Ровно эта же причина является и фатальным недостатком классических ORM, там это просто меньше чувствуется, так как данные все-таки реально отделены и лежат в базе, и ничто не мешает навернуть еще одну модель сверху, после того как старая перестала устраивать, но это все равно конкретный косяк, который их рано или поздно похоронит.
Ну возьми реальное приложение, которое работает с данными, на кой байт тебе там полноценный граф объектов? У такой модели хорошо получается только добираться до одного элемента по индексу, но на самом-то деле нужно фильтровать, объеденять, сортировать, агрегировать, причем самым произвольным образом, а на всех этих операциях ОО сосет как промышленный пылесос, по сравнению с моделью старика Кодда. В плоть до того, что для решения таких задач в насквозь объектный C# вкрячили функциональный LINQ, так похожий на SQL, что с двух шагов не отличить.
Мало кому интересен просто список товаров, интересен этот список отфильтрованный и отсортированный по самым причудливым критериям, например по принадлежности к конкретному заказу... Но самое забавное, что заказ и список элементов заказа, практически ни в одном юзкейсе не нужны одновременно, так какого байта в объекте Order делает коллекция OrderItems, потому что "объектно"?
Такая объектность может далеко завести, к примеру, работает у нас сейлз в B2B магазине, для него вполне возможен такой граф объектов Region->Customer->Orders->OrderItems->Product->Vendor... ->Region, упс, граф-то цикличный... Хуже другое, после сейлза пришел вендор-менеджер, а ему от кастомера плясать не интересно, ему граф-то нужен ровно обратный Vendor->Products->OrderItems->Order->Customer. И это мы еще на какого-нибудь логистика не посмотрели, у которого регионы и счета кастомера начинаются прямо от OrderItems и конкретный заказ ему не интересен ему важны все OrderItems до четырех часов сегодняшнего дня, чтобы доставку на завтра спланировать по всем адресам.
В OODB и в ORM-ном графе объектов, еще на этапе проектирования приложения нужно не просто обозначить ничего не обязывающую связь один ко многим, между заказом и продуктами в него входящими, а явно сказать, что коллекция объектов OrderItems принадлежит объекту Order, хотя в 99% юзкейсов не понадобится подгружать Order и OrderItems одновременно и, максимум в 50% юзкейсов, это утверждение о принадлежности вообще имеет смысл, так как отбирать эти OrderItems надо совсем по другому критерию.
Безусловно, это все решаемые проблемы, можно заранее протоптать все пути, можно применить LazyLoading, чтобы подгружать только нужную часть объектов. Закрыть глаза, на то что нигде не контролируется, что подгружается только нужная часть. Прикрутить навороченый двухуровневый кеш, с хитрым механизмом контроля когерентности, чтобы победить стоимость поднятия объекта при навигационном доступе. Использовать, при необходимости, DTO, так как нельзя просто передать объект куда хочется ввиду наличия LL, который уволочет на ту сторону всю базу... И так далее в том же духе, дедка за репку, одно тянет другое, хотя в итоге получается в принципе рабочее решение, которым правда не очень удобно пользоваться, так как пути жестко протоптаны — ну что тут поделаешь зато объектно....
И весь этот зоопарк костылей нужен вместо того, чтобы просто сказать базе — "дай мне пожалуйста всех вендоров, продукты которых мы продали в таких-то регионах, на сумму больше Z у. е." и получить от нее ровно ту информацию, которая нужна (к слову, в виде объекта), а не полный граф от вендора до кастомера.
Возникает только один вопрос — задлянафига нужен этот граф объектов в OODB?!

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

C>Ну отключаем ленивую загрузку и смотрим откуда исключения прилетят.
Нельзя, все встанет — это же ORM. )

C>Ну да, и при этом теряем границы транзакций (потенциальные спецэффекты, привет!).
С какого перепугу. Все траназакции в рамках этого самого коннекта, наоборот — это гарантия отсутствия спецэффектов. Нет никакой нужды границы транзакций размазывать.

C>В Hibernate так при желании тоже делается — пишется LazyLoadingHandler, который каждый раз открывает новую сессию на один запрос.
То есть написание LLHandler-а — это средство облегчения работы при использовании ORM? Я лучше это время потрачу на написание прикладного кода.. ))

C>У Андрея проблема в том, что с одним соединением идёт работа из нескольких потоков. Все известные БД на таком use-case'е глючат.
Так с соединением или с гибернейтовской сессией?

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

C>> Нет никаких фундаментальных причин по которым OODB не могут соперничать с RDB.
IB>Есть. Фундаментальная причина заключается ровно в том, что OODB жестко привязывает поведение и структуру к данным, а срок жизни данных сильно больше навязанного им поведения, и за их время жизни интерпретация меняется по многу раз.
Схема БД тоже жёстко привязывает структуру данных и поведение. Изменишь структуру данных — и поведение сломается. Не вижу НИКАКОЙ разницы.

IB>Ну возьми реальное приложение, которое работает с данными, на кой байт тебе там полноценный граф объектов? У такой модели хорошо получается только добираться до одного элемента по индексу, но на самом-то деле нужно фильтровать, объеденять, сортировать, агрегировать, причем самым произвольным образом, а на всех этих операциях ОО сосет как промышленный пылесос, по сравнению с моделью старика Кодда. В плоть до того, что для решения таких задач в насквозь объектный C# вкрячили функциональный LINQ, так похожий на SQL, что с двух шагов не отличить.
Ну и причём тут OODB, в котором всё точно такое же возможно?

IB>Такая объектность может далеко завести, к примеру, работает у нас сейлз в B2B магазине, для него вполне возможен такой граф объектов Region->Customer->Orders->OrderItems->Product->Vendor... ->Region, упс, граф-то цикличный... Хуже другое, после сейлза пришел вендор-менеджер, а ему от кастомера плясать не интересно, ему граф-то нужен ровно обратный
Ну и кто мешает? У меня в модели полно таких циклов. И всё работает.

IB>И весь этот зоопарк костылей нужен вместо того, чтобы просто сказать базе — "дай мне пожалуйста всех вендоров, продукты которых мы продали в таких-то регионах, на сумму больше Z у. е." и получить от нее ровно ту информацию, которая нужна (к слову, в виде объекта), а не полный граф от вендора до кастомера.
Слушай, ты вообще с OODB работал или только в теории говоришь? Так как всё это там делается ну точно так же, как и в RDB.

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

IT>>Это не более, чем слова, т.к. альтернативы RDB пока не существует. В отличии от ORM.

G>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google. Это уже в ближайшие годы станет популярной и очень серьезной альтернативой RDB, особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.

Я занимаюсь всем подряд. Решение о том, будет ли моё приложение web-based принимается в основном исходя из соображений какая аудитория будет у этого приложения. Если у него будут outside юзеры, то скорее всего это будет web-based. Иначе WPF. К сожалению. у веба есть порог функциональной сложности, связанный с передачей состояния между клиентом и сервером, когда сложность такого приложения начинает зашкаливать все разумные пределы.

G>Сейчас — они поднимаются по хайпу, скоро будут на пике.

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

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

C>>Ну отключаем ленивую загрузку и смотрим откуда исключения прилетят.
IB>Нельзя, все встанет — это же ORM. )
Почему? У нас просто получится решение, изоморфное решению без ORM.

Хотя если ты считаешь, что без ORM писать — это "всё встанет", то тут согласен.

C>>Ну да, и при этом теряем границы транзакций (потенциальные спецэффекты, привет!).
IB>С какого перепугу. Все траназакции в рамках этого самого коннекта, наоборот — это гарантия отсутствия спецэффектов. Нет никакой нужды границы транзакций размазывать.
Транзакции должны соответствовать одной единице работы.

C>>В Hibernate так при желании тоже делается — пишется LazyLoadingHandler, который каждый раз открывает новую сессию на один запрос.
IB>То есть написание LLHandler-а — это средство облегчения работы при использовании ORM? Я лучше это время потрачу на написание прикладного кода.. ))
Это просто как вариант решения. Писать, кстати, его не надо — на сайте Hibernate есть готовый в разделе примеров.

C>>У Андрея проблема в том, что с одним соединением идёт работа из нескольких потоков. Все известные БД на таком use-case'е глючат.
IB>Так с соединением или с гибернейтовской сессией?
С обоими.

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

G>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.
google — не удачный пример... Эти ребята все-таки пишут очень специфичный софт, для очень узкой области.

G> особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.
Меня терзают смутные сомненья. =)
Например, для отчетов оно все равно использует "table-oriented view engine", а различного рода отчеты — это 80%-90% большинства современных приложений.

G>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее,
Насколько я понял, ключевое отличие от RDB — нет жесткой схемы данных. Но как раз благодаря этой самой схеме, современные RDB и демонстрируют всю мощь своих оптимизаторов, поэтому такого рода базы, на современном этапе развития индустрии, потенциально гораздо более тормозные.

G>практически весь геморрой, знакомый по RDB, отсутствует by design.
Какой?

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

G>>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее,
IB>Насколько я понял, ключевое отличие от RDB — нет жесткой схемы данных. Но как раз благодаря этой самой схеме, современные RDB и демонстрируют всю мощь своих оптимизаторов, поэтому такого рода базы, на современном этапе развития индустрии, потенциально гораздо более тормозные.
Там можно стоить реляционные виды, на которых будет действовать стандартная реляционная алгебра, со всеми вытекающими последствиями.

G>>практически весь геморрой, знакомый по RDB, отсутствует by design.
IB>Какой?
Жёсткая схема.

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

C>Почему? У нас просто получится решение, изоморфное решению без ORM.
Мы уже выяснили, что без LL ORM не живет, а вот если делать без ORM то и без LL вполне можно обойтись.

C>Хотя если ты считаешь, что без ORM писать — это "всё встанет", то тут согласен.
Я считаю ровно наоборот.

C>Транзакции должны соответствовать одной единице работы.
Единице работы чего? И какие транзакции? Еденице бизнес-работы, должна соответствовать бизнес-транзакция, но бизнес-транзакция совсем не должна соответствовать транзакции в БД. Я бы даже сказал наоборот, должна не соответствовать.

C>Это просто как вариант решения.
Другие есть?

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

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

C>>Почему? У нас просто получится решение, изоморфное решению без ORM.
IB>Мы уже выяснили, что без LL ORM не живет, а вот если делать без ORM то и без LL вполне можно обойтись.
ORM вполне без LL прекрасно живёт, просто вырождается в решение аналогичное тому, что получится без ORM. Если это необходимо в каких-то случаях, то никто не запрещает использовать.

C>>Транзакции должны соответствовать одной единице работы.
IB>Единице работы чего? И какие транзакции? Еденице бизнес-работы, должна соответствовать бизнес-транзакция, но бизнес-транзакция совсем не должна соответствовать транзакции в БД. Я бы даже сказал наоборот, должна не соответствовать.
Насколько я понимаю, там как раз в одной единице бизнес-работы и была многопоточная (для ускорения) работа.

C>>Это просто как вариант решения.
IB>Другие есть?
Есть.

C>>С обоими.
IB>То есть, при работе с гибернейтовской сессией, я должен следить за доступом к ней из различных потоков?
Ровно так же, как ты должен следить за тем, что одно соединение с БД не используется из нескольких потоков.

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

C>Схема БД тоже жёстко привязывает структуру данных и поведение.
Не привязывает. Между структурой данных и поведением есть запросы.

C> Не вижу НИКАКОЙ разницы.
Сочувствую...

C>Ну и причём тут OODB, в котором всё точно такое же возможно?
При том, что из-за гораздо более суровых связей, сделать это весьма проблематично и нерентабельно, потому и не сделали.

C>Ну и кто мешает? У меня в модели полно таких циклов. И всё работает.
Конечно работает, у тебя же полный зоопарк — LL, кеши, DTO — только вот зачем это все?

C>Слушай, ты вообще с OODB работал или только в теории говоришь?
Я в практике говорю.

C> Так как всё это там делается ну точно так же, как и в RDB.
Ага. Так нафига мне объекты в OODB или граф объектов от ORM, если в приложении, для реализации конкретного юзкейса, мне нужны совсем другие объекты?

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

C>ORM вполне без LL прекрасно живёт, просто вырождается в решение аналогичное тому, что получится без ORM.
Это понятно, собственно об этом и речь. Чтобы использовать ORM с полноценным графом объектов мы вынуждены подключать LL.

C>Если это необходимо в каких-то случаях, то никто не запрещает использовать.
Но так как это самый частый сценарий, то возникает вопрос — нафига мне нужна ORM?

C>Насколько я понимаю, там как раз в одной единице бизнес-работы и была многопоточная (для ускорения) работа.
Ну и причем тут тогда транзакции? Ты от темы то не увиливай.

C>Есть.
Какие?

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

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

C>>Схема БД тоже жёстко привязывает структуру данных и поведение.
IB>Не привязывает. Между структурой данных и поведением есть запросы.
Которые есть часть поведения, и которые ломаются от изменения структуры данных.

C>>Ну и причём тут OODB, в котором всё точно такое же возможно?
IB>При том, что из-за гораздо более суровых связей, сделать это весьма проблематично и нерентабельно, потому и не сделали.
Нет, просто у RDB получилась фора примерно в 10 лет, которой они воспользовались. Cache' вон вполне себе нормально живёт, и рвёт RDB на многих задачах.

C>>Ну и кто мешает? У меня в модели полно таких циклов. И всё работает.
IB>Конечно работает, у тебя же полный зоопарк — LL, кеши, DTO — только вот зачем это все?
А без ORM оно не нужно?

C>>Слушай, ты вообще с OODB работал или только в теории говоришь?
IB>Я в практике говорю.
Что-то не очень похоже.

C>> Так как всё это там делается ну точно так же, как и в RDB.
IB>Ага. Так нафига мне объекты в OODB или граф объектов от ORM, если в приложении, для реализации конкретного юзкейса, мне нужны совсем другие объекты?
А зачем "совсем другие"?

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

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

C>Жёсткая схема.
Я так и понял.

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

C>>Там можно стоить реляционные виды, на которых будет действовать стандартная реляционная алгебра, со всеми вытекающими последствиями.
IB>Иными словами, пока нам производительность не критична, то можем наслаждаться гибкостью?
Примерно так. Ну и ещё имеем удобный формат для массивных map-reduce операций, на которых обычные RDB ничем не могут помочь.

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

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

G>>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.
IB>google — не удачный пример... Эти ребята все-таки пишут очень специфичный софт, для очень узкой области.

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

G>> особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.
IB>Меня терзают смутные сомненья. =)
IB>Например, для отчетов оно все равно использует "table-oriented view engine", а различного рода отчеты — это 80%-90% большинства современных приложений.

Во-первых, не только для отчетов. Во-вторых, посмотри внимательно, как именно устроен этот table-oriented view engine. Это имеет не очень много общего с таблицей. Короче, надо чуть больше времени потратить на разбирательство — посмотри как устроен map-reduce . Потом — ты пиши конкретно, что тебе кажется там плохо, я буду отвечать.

G>>Сам я близко смотрел CouchDB (http://incubator.apache.org/couchdb/). Ощущения от их модели данных — самые приятные, это нечто потрясающее,
IB>Насколько я понял, ключевое отличие от RDB — нет жесткой схемы данных.
Это важное отличие, но не ключевое. Ключевое отличие в том, что эта схема относительно без проблем масштабируется на ферму из тысяч серверов, и отлично держит "расщепленные сети".

IB>Но как раз благодаря этой самой схеме, современные RDB и демонстрируют всю мощь своих оптимизаторов, поэтому такого рода базы, на современном этапе развития индустрии, потенциально гораздо более тормозные.

На практике — они гораздо более быстрые за счет существенно лучшей масштабируемости. Короче, посмотри как устроены функции map и reduce в справочнике по API. Это примерно 15 минут. Это того стоит, времени потратим меньше. Потом — продолжим разговор.

G>>практически весь геморрой, знакомый по RDB, отсутствует by design.
IB>Какой?

1) Апгрейд схемы БД при изменении версии.
2) Репликация изменений схемы БД.
3) "Нормализация" и понижение производительности из-за обилия операций join. В CouchDB как ключ, так и значения могут быть составным типом произвольной сложности (это произвольные JSON-объекты). Это касается и "table-oreinted view" в том числе.
4) Второй аспект связанный с 3 — это наличие и толщина прослоек и ORM. Реляционная модель — это не та модель, в которой удобно работать в твоей проге. В модели CouchDB семантическая разница в моделях отсутствует, приводить их не надо.

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

G>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.
Не он один. У нас тоже что-то такое написали.

G>Это уже в ближайшие годы станет популярной и очень серьезной альтернативой RDB,
Это весьма специфичная штука.
У нее свои сценарии использования.
RDB оно может потеснить только в весьма узком сегменте задач.

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

G>особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.
Ну я занимаюсь.
Кое где нечто подобное воткнуть можно.
Но на RDB killer'а оно явно не тянет.

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

G>>Базы, основанные на map-reduce. Такими технологиями, обладает сейчас, например, google.
WH>Не он один. У нас тоже что-то такое написали.
Их сейчас все кому не лень пишут Мы вот используем Apache Hadoop на Amazon EC2 для построения некоторых отчётов. Очень круто — можно по запросу получить сотню готовых машинок на пару часов.

G>>особенно если ты занимаешься разработкой веб-приложений — я практически уверен, на это все факторы указывают.
WH>Ну я занимаюсь.
WH>Кое где нечто подобное воткнуть можно.
WH>Но на RDB killer'а оно явно не тянет.
Оно особо рулит там, где нужна работа с документами, и особенно с версироваными документами.