Re[6]: Объектность; Persistence; Hibernate : что дальше? - Философия программирования

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

C>Поэтому и нужно интегрировать ORM с системой запросов. Я показал один из возможных примеров, LINQ тоже вполне подойдёт тут.

Тогда вопрос, что останется от ОРМ?
Ну, права зачем нам не эффективные и нечитаемые циклы по коллекциям когда мы можем эффективно и декларативно вытащить все нужные данные?

VD>>Я слышал много речей защитников ОРМ-ов. Все они апеллировали к разумности применения ОРМ-ов. Но к сожалению, на практике все получается иначе. На мой взгляд, если кто-то начинает использовать в ОРМ-ах запросы, то он просто использует технологию не по назначению. Намного эффективнее тогда отказаться от самой идеи — смотреть на БД как на граф объектов и обрабатывать данные исключительно запросами.
C>Запросами очень удобно объекты получать, а потом навигацией по ним ходить на близкие расстояния. У меня в коде самый типичный случай — это обращение к parent'у элемента.

Ну, тода ты получаешь схему Линка в которой конечно есть зачатки ОРМ, но самые базовые. Скажем запрос вида:

from o in Orders where sum(o.Items.Amount) > 100 select o

можно и Линк-ом сделать. Причем он будет преобразован в банальный join или подзапрос и не приведет к рысканью по БД.
А вот если тоже самое сделать средствами ОРМ в купе с циклами и перебором свойств в обычном коде, то мы сразу получим все проблемы ОРМ-технологии о которых тут так много говорилось.

В общем, если рассматривать код вида o.Items.Amount как шорткат для запроса с join-ом или подзпроса, то все ОК. Но если смотреть на него как на императивную операцию, то ну его на фиг.

Подытоживая сформулирую основную идею. От ОРМ можно взять только саму идею отображения кортежей РБД в объекты ОЯП или кортежи же ФЯ, и отображение реляционных связей в нечто смахивающее на объектные коллекции. А вот идея прозрачной материализации объектов из персистентного хранилища (взятую из EJB или еще откуда-то) брать ни в коем случае нельзя, так как именно она и создает все проблемы в ОРМ.

Ну, и вывод: Запрос — оптимальный инструмент обработки данных. А задачей современных технологий обработки данных является создание максимального комфорта в создании и модификации запросов и в преобразовании результатов запросов в структуры данных удобные для обработки универсальными языками программирования. Насколько я понимаю Линк удовлетворяет всем описанным мной требованием, а стало быть необходимость фрэймворков вроде Кибернейта является очень сомнительной.

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

SLH>90% бизнес — задач сводится к созданию, сохранению, модификации и поиску информации.

Скажем скомпилированная программа состоит из множества тривиальных инструкций процессора (или виртуальной машины). Но ты же не смотришь на программу (и на процесс ее создания) как на выстраивание в столбик инструкций add, cmp, jamp и т.п.?

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

SLH>А вот что еще нужно бывает делать в области бизнес — приложений?

О... Это открытое множество. Перечислить его невозможно. Как пример, в некоторой компании — это может быть прогнозирование поведения клиентов на рынке. В другой — оптимизация бизнес процессов. В третьей сознание интерактивных систем поиска товаров покупателями. И т.д., и т.п.
В общем, это что угодно на не сохранение данных в БД (или ОРМ-е).

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

Уважаемые коллеги,
я уже давно наблюдаю за развитием бизнес — приложений, хотя и вижу только некую часть айсберга.
Значительная часть работы всегда сводится к сохранению информации и вытаскиванию её по неким запросам.
Некотрое время назад это делалось в реляционных базах данных, сейчас на смену им неспеша приходят те технологии, название которых перечислено в заголовке моего поста (через точку с запятой — именно потому, что это во многом — синонимы).
Меняются технологии, по которым построены интерфейсы — уже можно назвать two-layer architecture, three-layer architecture, multi-layer architecture, WEB-интерфейсы, теперь вот добавилась еще возможность писать silverlight-front приложения.
Мне это кажется неким тупиком, потому что вроде бы Hibernate во многом решает проблемы “сохранения — вытаскивания – поиска” данных, и получается что технология дошла до некой предельной точки, за которой развитие не будет происходить.
Не хочу в это верить, но не вижу никакой видимой перспективы, и хочу спросить о ней у более знающих людей.

... << RSDN@Home 1.2.0 alpha rev. 0>>

25.09.08 17:14: Перенесено модератором из 'О работе' — der Igel

Здравствуйте, SteeLHeaD, Вы писали:
SLH>В разработке бизнес — приложений. Приложения, которые позволяют записывать, модифицировать и искать информацию в удобной для пользователя форме — решают оченб большой класс бизнес — задач. Мне хочется понять, что придет на смену этому классу задач. или как он видоизменится.
Это утверждение справедливо. Вот только интерпретация "в удобной для пользователя форме" плохо формализована.
Вот тебе банальный пример: пользователь ищет информацию о том, как попасть из пункта А в пункт B. Его интересует наилучшее соотношение цена/скорость, но в пределах ограничений. То есть он не готов потратить год и дойти пешком, и он не готов заплатить $50000 за вертолет.

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

Сможет в этом помочь hibernate? Нет, даже гораздо более простой вопрос "где ближайший банкомат" вызовет затруднения. Потому, что гибернейт разрабатывался для очень узкого класса реляционных запросов, для spatial данных он плохо заточен.

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

Это всё мы говорим об очень популярных сейчас потребностях, связанных с поиском информации.

Даже в том узком сегменте, где рулят реляционные СУБД, гибернейту еще ого-го есть куда развиваться. И по функциональности, и по масштабируемости с быстродействием. Так что говорить о "венце всего" преждевременно.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

BZ>>сжатие данных, high-throuhput systems, cloud computing, игры...
L>cloud computing — область не для всех? По-моему это скорее область для никого, очередной базворд.

В каждом баззворде есть доля баззворда

Кое-где cloud computing рулит. Например, мы используем Amazon EC2 для того, чтобы запускать изредка очень тяжёлые отчёты. Cloud computing рулит — так как мы можем на Амазоне купить машинное время сотни-другой компьютеров на пару часов. Это нам обходится в десятки раз дешевле, чем устраивать свой собственнный дата-центр.

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

A>>Сохрани туда в 10000 раз больше данных и увеличь transaction rate в 100 раз и ты поймешь что тебе еще есть что изучить, а хибернейт загибается при первом дуновении ветра. Системы которые я описал существуют достаточно массово, т.е. это не только интернет сервисы но и большие бизнес системы в компаниях типа билайна или газпрома.

C>Да ладно, Hibernate прекрасно работает и в очень нагруженных системах.

очень нагруженных это сколько миллионов хитов в день в твоем понимании?

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

A> но с какого-то уровня развития системы становится проще не бороться, а выкинуть OORМ

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

_>Как-то вы абстрактно выражаетесь, некий тупик, точка.. а где тупик-то?
Тупик в том, что все — выучил я некий современный механизм сохранения в базу объектов — и все, больше учить нечего. То есть я вижу профессиональный тупик — я не понимаю, чем еще заниматься в ближайшие годы.
Если бы вслед за hibernation появилась следующая идеология (и технолгоия), которая позволяет решать еще такие то и такие то проблемы разработки, убрав в ней такие то и такие то узкие места — я бы понимал, чем заниматься.

... << RSDN@Home 1.2.0 alpha rev. 0>>

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

K>??? Он так и останется. Только одной технологии, которая бы решала весь этот класс задач нет.

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

C>>>Логарифмическое время доступа — это ерунда. Для всех практических случаев можно считать log(N)=C. Проблема тут чисто техническая — roundtrip до базы стоит очень дорого.
A>>log2(1M)=10
C>Примерно 20, вообще-то

Ой да. Позор мне — все константы забыл

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

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

BZ>>>если ты хочешь развиваться именно как программист — иди в области "не для всех"

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

BZ>интересная же работа может быть если ты сам разрабатываешь эти библиотеки. фишка как раз в том что тут у тебя no chances, а в областях "не для всех" ты сам пишешь для себя велосипед. поэтому и работа там более сложная и творческая

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

У нас вот вообще BDB

И никаких hibernate не было и, скорее всего, не предвидется

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

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

SLH>Мне это кажется неким тупиком, потому что вроде бы Hibernate во многом решает проблемы “сохранения — вытаскивания – поиска” данных, и получается что технология дошла до некой предельной точки, за которой развитие не будет происходить.

а затем придёт cloud computing и придётся жевать то же мочало сначала

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

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

SLH>>Мне это кажется неким тупиком, потому что вроде бы Hibernate во многом решает проблемы “сохранения — вытаскивания – поиска” данных, и получается что технология дошла до некой предельной точки, за которой развитие не будет происходить.

BZ>а затем придёт cloud computing и придётся жевать то же мочало сначала

Ну, cloud computing всего — навсего представляет собой другой способ взымания платы с пользоватлей... Так что там я не вижу технологичекого прорыва — это всего навсего что то типа идеи "безлимитки" при предоставлении интернет доступа или flat rate tarif'ов в телефонии.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

K>Но это совсем не означает что нет ничего другого.

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

SLH>Мне это кажется неким тупиком, потому что вроде бы Hibernate во многом решает проблемы “сохранения — вытаскивания – поиска” данных, и получается что технология дошла до некой предельной точки, за которой развитие не будет происходить.
SLH>Не хочу в это верить, но не вижу никакой видимой перспективы, и хочу спросить о ней у более знающих людей.

Как-то вы абстрактно выражаетесь, некий тупик, точка.. а где тупик-то?

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

BZ>>а затем придёт cloud computing и придётся жевать то же мочало сначала

SLH>Ну, cloud computing всего — навсего представляет собой другой способ взымания платы с пользоватлей... Так что там я не вижу технологичекого прорыва — это всего навсего что то типа идеи "безлимитки" при предоставлении интернет доступа или flat rate tarif'ов в телефонии.

почитай материалы о google farm и amazon elastic cloud. кстати, сейчас крупнейшие фирмы занимаются этим напрвлением — отмотай немного назад, здкесь приглашали на проект в этой области, реализуемый у нас в стране

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

SLH>Уважаемые коллеги,
SLH>я уже давно наблюдаю за развитием бизнес — приложений, хотя и вижу только некую часть айсберга.
SLH>Значительная часть работы всегда сводится к сохранению информации и вытаскиванию её по неким запросам.
SLH>Некотрое время назад это делалось в реляционных базах данных, сейчас на смену им неспеша приходят те технологии, название которых перечислено в заголовке моего поста (через точку с запятой — именно потому, что это во многом — синонимы).
SLH>Меняются технологии, по которым построены интерфейсы — уже можно назвать two-layer architecture, three-layer architecture, multi-layer architecture, WEB-интерфейсы, теперь вот добавилась еще возможность писать silverlight-front приложения.
SLH>Мне это кажется неким тупиком, потому что вроде бы Hibernate во многом решает проблемы “сохранения — вытаскивания – поиска” данных, и получается что технология дошла до некой предельной точки, за которой развитие не будет происходить.
SLH>Не хочу в это верить, но не вижу никакой видимой перспективы, и хочу спросить о ней у более знающих людей.

ИМХО Развитие ORM бдет дальше идти в сторону распределенности, кеширования, декларативности запросов, более гибкого маппинга и, самое главное, интеграции с другими технологиями. Фактически это развити "вширь", а не "вглубь".

SLH>Вот это то как раз и интересно! Просто я считаю некоторый класс задач — освоенным. А по поводу других классов задач — может быть, есть что то столь же мощное, как hibernate? Или наоборот — есть в этом направлении что то гораздо лучше, чем hibernate?

В каком направлении? В базах? Ну есть high-performance базы (BDB, KDB), есть базы, ориентированные на хранение временных рядов etc. Или в персисте объектов?

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

_>>Как-то вы абстрактно выражаетесь, некий тупик, точка.. а где тупик-то?
SLH>Тупик в том, что все — выучил я некий современный механизм сохранения в базу объектов — и все, больше учить нечего. То есть я вижу профессиональный тупик — я не понимаю, чем еще заниматься в ближайшие годы.

Сохрани туда в 10000 раз больше данных и увеличь transaction rate в 100 раз и ты поймешь что тебе еще есть что изучить, а хибернейт загибается при первом дуновении ветра. Системы которые я описал существуют достаточно массово, т.е. это не только интернет сервисы но и большие бизнес системы в компаниях типа билайна или газпрома.

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

K>В каком направлении? В базах? Ну есть high-performance базы (BDB, KDB), есть базы, ориентированные на хранение временных рядов etc. Или в персисте объектов?

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

L>Сохранять в базу — это единственное, чем вам приходится заниматьс?

90% бизнес — задач сводится к созданию, сохранению, модификации и поиску информации. А вот что еще нужно бывает делать в области бизнес — приложений?
Я не говорю, что это единственное моё занятие, я как раз интеерсуюсь что еще можно делать. И с использованием каких ЭФФЕКТИВНЫХ подходов.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

A>Сохрани туда в 10000 раз больше данных и увеличь transaction rate в 100 раз и ты поймешь что тебе еще есть что изучить, а хибернейт загибается при первом дуновении ветра. Системы которые я описал существуют достаточно массово, т.е. это не только интернет сервисы но и большие бизнес системы в компаниях типа билайна или газпрома.

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

??? Он так и останется. Только одной технологии, которая бы решала весь этот класс задач нет.

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

A>>Сохрани туда в 10000 раз больше данных и увеличь transaction rate в 100 раз и ты поймешь что тебе еще есть что изучить, а хибернейт загибается при первом дуновении ветра. Системы которые я описал существуют достаточно массово, т.е. это не только интернет сервисы но и большие бизнес системы в компаниях типа билайна или газпрома.

SLH>Это не очень массовая задача. Она очень инетерсная и требует других подходов, но вряд ли я столкнусь с разработкой приложений, в которых это нужно.
SLH>я говорю это не для того, чтобы поставить нас по разные стороны баррикад, просто переход на Hiberhane дает очень заметный эффект при повседневной работе программиста. И я хочу понять, какие еще революции в области бизнес — приложений могут произойти.

Как бы тебе сказать. Сейчас ты ей не занимаешься, но если тебе [к счастью, не дай бог (подчеркни одно из)] удастся написать успешную бисзнес систему, то следующее ее внедрение будет вдвое больше, потом еще вдвое больше, потом еще больше и ... и еще ... вот ты уже работаешь на 10000 юзеров, а не 20 юзерах. Это не разделенные рынки, он один и тот же, перетечь из одного в другой система может года за 3.

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

A>Сохрани туда в 10000 раз больше данных и увеличь transaction rate в 100 раз и ты поймешь что тебе еще есть что изучить, а хибернейт загибается при первом дуновении ветра. Системы которые я описал существуют достаточно массово, т.е. это не только интернет сервисы но и большие бизнес системы в компаниях типа билайна или газпрома.
Да ладно, Hibernate прекрасно работает и в очень нагруженных системах.

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

SLH>Я не говорю, что это единственное моё занятие, я как раз интеерсуюсь что еще можно делать. И с использованием каких ЭФФЕКТИВНЫХ подходов.

паттерны, архитектура, да мало ли чего на свете интересного

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

C>>Да ладно, Hibernate прекрасно работает и в очень нагруженных системах.
A>очень нагруженных это сколько миллионов хитов в день в твоем понимании?
У меня нет хитов — не веб-приложение. Однако, под нагрузкой спокойно тысячу транзакций (данные и запросы с устройств, в основном) в секунду кластер держит.

Для эксперимента некоторые части переписывали на JDBC — смотрели выгодно ли будет перейти с Hibernate на собственный ORM. Изменения в скорости составили всего порядка 15%.

В Hibernate есть несколько мест, где код писали тупые индусы. В основном там, где мало кто на них натыкается. Часть этих мест, на которые я лично всё-таки наткнулся — пришлось поправить и послать им патчи

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

Вот пример такого приложения: у вас есть десятки тысяч работающих стратегий, который добавляются, удаляются да еще и меняются. Ну и все подряд присылают запросы. Почти все изменения хочется персистить. Насколько быстро это будет с hibernate etc?

SLH>Ну, cloud computing всего — навсего представляет собой другой способ взымания платы с пользоватлей...
Который приводит к технологическим изменениям. Сначала был майнфрейм — один большой компьютер на всех. Потом, персональный компьютер для тебя одного. Потом сеть персональных компьютеров. Потом сеть ПК с выделенным сервером. Потом сеть ПК с выделенным сервером и виртуальным сервером. Сейчас все это де, плюс, облако. Появляются новые технологии, котоыре позволяют поддерживать старые конфигурации. Которые, увы, приходится изучать. А класс задач не меняется.

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

K>Вот пример такого приложения: у вас есть десятки тысяч работающих стратегий, который добавляются, удаляются да еще и меняются. Ну и все подряд присылают запросы. Почти все изменения хочется персистить. Насколько быстро это будет с hibernate etc?
Hibernate — это просто интерфейс к БД. Если БД справляется нормально, не использует слишком много грязных трюков (типа очень странных триггеров) — то скорее всего Hibernate будет работать вполне нормально.

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

C>В Hibernate есть несколько мест, где код писали тупые индусы. В основном там, где мало кто на них натыкается. Часть этих мест, на которые я лично всё-таки наткнулся — пришлось поправить и послать им патчи

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

C>Hibernate — это просто интерфейс к БД. Если БД справляется нормально, не использует слишком много грязных трюков (типа очень странных триггеров) — то скорее всего Hibernate будет работать вполне нормально.

А если я хочу оптимизировать количество копирований памяти по пути?

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

C>>Hibernate — это просто интерфейс к БД. Если БД справляется нормально, не использует слишком много грязных трюков (типа очень странных триггеров) — то скорее всего Hibernate будет работать вполне нормально.
K>А если я хочу оптимизировать количество копирований памяти по пути?
А зачем?

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

BZ>если ты хочешь развиваться именно как программист — иди в области "не для всех"

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

C>>В Hibernate есть несколько мест, где код писали тупые индусы. В основном там, где мало кто на них натыкается. Часть этих мест, на которые я лично всё-таки наткнулся — пришлось поправить и послать им патчи

A>Там не в этом проблема — есть общая проблема все OORM в том, что переход по обычно ссылке это константная операция, а в OORM в общем случае логарифмическая — т.к. базе нужно сходить по индексу и что-то получить.
Логарифмическое время доступа — это ерунда. Для всех практических случаев можно считать log(N)=C. Проблема тут чисто техническая — roundtrip до базы стоит очень дорого.

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

A>Это можно учесть во всех алгоритмах, но обычно про это все забывают и получается тормозилово страшное. Бороться с этим можно, но с какого-то уровня развития системы становится проще не бороться, а выкинуть OORM
Так ведь в результате получится ровно то, что будет, если оптимизировать использование ORM.

C>А зачем?

Быстрее хочется.

C>А зачем?

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

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

C>>А зачем?
K>Быстрее хочется.
А нужно ли?

Оно обычно важно только когда в транзакции нужно обработать очень большое число объектов. А это достаточно редкий use-case.

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

C>>А зачем?
K>Ну и вообще — иногде весь этот оверхед в виде маппинга обектов на базу абсолютно не нужен. Далеко не всегда нужно графы объектов поднимать из базы. Особенно когда очень хочется скорости.
Ну так ведь никто и не мешает напрямую работать. Если хочется — берёшь голый SQL Connection и работаешь. Никто же не запрещает.

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

C>Логарифмическое время доступа — это ерунда. Для всех практических случаев можно считать log(N)=C. Проблема тут чисто техническая — roundtrip до базы стоит очень дорого.
log2(1M)=10, это уже не то чем нужно пренебрегать. На счет roundtrip-а согласен.

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

A>>Это можно учесть во всех алгоритмах, но обычно про это все забывают и получается тормозилово страшное. Бороться с этим можно, но с какого-то уровня развития системы становится проще не бороться, а выкинуть OORM
C>Так ведь в результате получится ровно то, что будет, если оптимизировать использование ORM.
Только не факт что это проще.

C>Оно обычно важно только когда в транзакции нужно обработать очень большое число объектов. А это достаточно редкий use-case.

Речь шла о том что так называемые бизнес-приложения — разные. Иначе можно было бы сказать что кроме Visual Basic ничего не нужно, потому что большинство бизнес-приложений писали на нем

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

Ну вот, hibernate тут и не нужен. Хотя у высокопроизводительных баз данных и SQL-то не всегда присутствует

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

BZ>>если ты хочешь развиваться именно как программист — иди в области "не для всех"

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

понимаешь в чём дело — когда и создание GUI-программ для виндов было областью не для всех, когда вручную приходилось писать функцию окна и обработку всех событий. такие технологии сложны и автоматом означают малое кол-во программистов, их освоивших, и малое кол-во программ. написание типовых бизнес-приложений по определению не может себе такие технологии позволить — оно начинается тогда, когда появляются удобные RAD-средства разработки. и тут уже главным становится просто умение быстро гнать код. поэтому массовая разработка => невысокий уровень разработчиков

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

интересная же работа может быть если ты сам разрабатываешь эти библиотеки. фишка как раз в том что тут у тебя no chances, а в областях "не для всех" ты сам пишешь для себя велосипед. поэтому и работа там более сложная и творческая

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

SLH>>Это не очень массовая задача. Она очень инетерсная

BZ>если ты хочешь развиваться именно как программист — иди в области "не для всех"

Например?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

C>>Логарифмическое время доступа — это ерунда. Для всех практических случаев можно считать log(N)=C. Проблема тут чисто техническая — roundtrip до базы стоит очень дорого.
A>log2(1M)=10
Примерно 20, вообще-то

A>это уже не то чем нужно пренебрегать. На счет roundtrip-а согласен.
Да ну, разницу между select'ом по PK в таблице на 200 миллионов записей и 10 тысяч записей — заметить нельзя. Оверхед на roundtrip всё маскирует.

C>>Так ведь в результате получится ровно то, что будет, если оптимизировать использование ORM.
A>Только не факт что это проще.
Примерно так же и получается, только ORM ещё хотя бы снимает многие проблемы за счёт автоматизации.

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

BZ>>если ты хочешь развиваться именно как программист — иди в области "не для всех"

L>Например?

сжатие данных, high-throuhput systems, cloud computing, игры...

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

SLH>А вот интересно — как то класс "офисных" задач меняется со временем?

А как ты определяешь этот самый класс "офисных" задач?

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

BZ>>>если ты хочешь развиваться именно как программист — иди в области "не для всех"

L>>Например?

BZ>сжатие данных, high-throuhput systems, cloud computing, игры...

cloud computing — область не для всех? По-моему это скорее область для никого, очередной базворд.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

L>>cloud computing — область не для всех? По-моему это скорее область для никого, очередной базворд.

C>В каждом баззворде есть доля баззворда

C>Кое-где cloud computing рулит. Например, мы используем Amazon EC2 для того, чтобы запускать изредка очень тяжёлые отчёты. Cloud computing рулит — так как мы можем на Амазоне купить машинное время сотни-другой компьютеров на пару часов. Это нам обходится в десятки раз дешевле, чем устраивать свой собственнный дата-центр.

Фига се. А данные как туда попадают?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

C>>Кое-где cloud computing рулит. Например, мы используем Amazon EC2 для того, чтобы запускать изредка очень тяжёлые отчёты. Cloud computing рулит — так как мы можем на Амазоне купить машинное время сотни-другой компьютеров на пару часов. Это нам обходится в десятки раз дешевле, чем устраивать свой собственнный дата-центр.
L>Фига се. А данные как туда попадают?
У Amazon'а до нашего дата-центра примерно канал в 200Мбит

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

Cyberax wrote:
> Здравствуйте, Lloyd, Вы писали:
>
> C>>Кое-где cloud computing рулит. Например, мы используем Amazon EC2 для того, чтобы запускать изредка очень тяжёлые отчёты. Cloud computing рулит — так как мы можем на Амазоне купить машинное время сотни-другой компьютеров на пару часов. Это нам обходится в десятки раз дешевле, чем устраивать свой собственнный дата-центр.
> L>Фига се. А данные как туда попадают?
> У Amazon'а до нашего дата-центра примерно канал в 200Мбит

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

А какого вида расчеты и отчеты?

Posted via RSDN NNTP Server 2.1 beta

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

SLH>Не хочу в это верить, но не вижу никакой видимой перспективы, и хочу спросить о ней у более знающих людей.

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

И вот тут-то получается, что хибернет решает процентов 10-20 от всех бизнес-задач

А внешне все это обычный такой доступ к данным и их обработка...

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

S>Сможет в этом помочь hibernate? Нет, даже гораздо более простой вопрос "где ближайший банкомат" вызовет затруднения. Потому, что гибернейт разрабатывался для очень узкого класса реляционных запросов, для spatial данных он плохо заточен.

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

Здравствуйте, WFrag, Вы писали:
WF>Плохо в каком смысле? Условия на геоданные будут работать ровно так же, как и, например, больше/меньше для чисел.
А можно пример такого запроса? Я, может, что-то пропустил?

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

S>Здравствуйте, WFrag, Вы писали:
WF>>Плохо в каком смысле? Условия на геоданные будут работать ровно так же, как и, например, больше/меньше для чисел.
S>А можно пример такого запроса? Я, может, что-то пропустил?

Как-то так (выборка всех объектов в области заданной точки):

Point pos = new GeometryFactory().createPoint(new Coordinate(longitude, latitude));
Query query = session.createQuery("from Plant p where spatial.distance(p.point, :pos) < :dist");
query.setParameter("pos", pos, JTSGeometryType.TYPE);
query.setParameter("dist", 4.0 / Math.pow(2, zoom));
List<Plant> plants = (List<Plant>)query.list();

А работает это через вот эти стандарты: http://www.opengeospatial.org/standards/sfs

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

WF>

WF>Point pos = new GeometryFactory().createPoint(new Coordinate(longitude, latitude));
WF>Query query = session.createQuery("from Plant p where spatial.distance(p.point, :pos) < :dist");
WF>query.setParameter("pos", pos, JTSGeometryType.TYPE);
WF>query.setParameter("dist", 4.0 / Math.pow(2, zoom));
WF>List<Plant> plants = (List<Plant>)query.list();
WF>

Ух ты, здорово. А ближайший оно, надо полагать, будет искать так:

from Plant p order by spatial.distance(p.point, :pos)

?
WF>А работает это через вот эти стандарты: http://www.opengeospatial.org/standards/sfs
И где именно это работает? Ну там — на MS SQL? Oracle? DB2? Скорость работы как себя чувствует?
А route finding тоже там сделан? То есть учитывается расстояние по дороге, а не по прямой?

Я, кстати, не вижу связи между стандартом и приведенным кодом.

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

WF>>А работает это через вот эти стандарты: http://www.opengeospatial.org/standards/sfs
S>И где именно это работает? Ну там — на MS SQL? Oracle? DB2? Скорость работы как себя чувствует?
S>А route finding тоже там сделан? То есть учитывается расстояние по дороге, а не по прямой?
Работает там, где есть spatial-расширения. Я лично использую это в PostgreSQL с установленным PostGIS, и плугином к Hibernate (http://www.hibernatespatial.org/).

Написано, что поддерживается ещё MySQL и Oracle.

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

S>Ух ты, здорово. А ближайший оно, надо полагать, будет искать так:
S>

S>from Plant p order by spatial.distance(p.point, :pos)
S>

S>?
Лучше ещё задать bounding box — существенно ускорим запрос.

S>Я, кстати, не вижу связи между стандартом и приведенным кодом.
Это библиотека HibernateSpatial, она использует адаптированный к Java интерфейс.

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

>> У Amazon'а до нашего дата-центра примерно канал в 200Мбит

Данные раскладываются на узлы во время их запуска, а потом объединяются в кластер. Данных у нас не так много, а вот как раз процессорного времени нужно навалом.
K>А какого вида расчеты и отчеты?
Data mining, поиск корреляций.

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

S>Ух ты, здорово. А ближайший оно, надо полагать, будет искать так:
S>

S>from Plant p order by spatial.distance(p.point, :pos)
S>

S>?

На самом деле, тут неправильный ближаший — по прямой.

WF>>А работает это через вот эти стандарты: http://www.opengeospatial.org/standards/sfs

S>И где именно это работает? Ну там — на MS SQL? Oracle? DB2?

В MySQL условно, в Postres нормально, в Oracle/MS SQL должно (сам не работал, но декларируют, что расширение поддерживается).

S>Скорость работы как себя чувствует?

Не знаю, у нас объемы смешные, меньше 100к записей, да и задачи специфичные. Индекс какой-то там используется.

S>А route finding тоже там сделан? То есть учитывается расстояние по дороге, а не по прямой?

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

S>Я, кстати, не вижу связи между стандартом и приведенным кодом.

В стандарте описывается тип и операции над ним. У pos тип GEOMETRY, spatial.distance превращается в SQL-ный ST_Distance (описанный в PDF-ке OpenGIS Implementation Specification for Geographic information — Simple feature access — Part 2: SQL option).

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

WF>В MySQL условно, в Postres нормально, в Oracle/MS SQL должно (сам не работал, но декларируют, что расширение поддерживается).

Про MS SQL это я по вот этому сужу: http://www.microsoft.com/sqlserver/2008/en/us/spatial-data.aspx

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

C>Работает там, где есть spatial-расширения. Я лично использую это в PostgreSQL с установленным PostGIS, и плугином к Hibernate (http://www.hibernatespatial.org/).

О. А у меня-то самодельная поддержка была реализована (это был кусок моего кода где-то 2-летней давности), а уже плагин к Hibernate оказывается есть

C>Написано, что поддерживается ещё MySQL и Oracle.

В MySQL оно не так давно (полгода назад) было реализовано из рук вон плохо. Все операции — только на уровне bounding box, функции distance вообще не было (я ее сам дописывал для случая с точками), их индекс не позволял вставлять строки с NULL геометрией. То есть — шлак.

С PostGIS-ом никаких проблем — всё как надо работает.

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

C>>Работает там, где есть spatial-расширения. Я лично использую это в PostgreSQL с установленным PostGIS, и плугином к Hibernate (http://www.hibernatespatial.org/).
WF>О. А у меня-то самодельная поддержка была реализована (это был кусок моего кода где-то 2-летней давности), а уже плагин к Hibernate оказывается есть

Оно по внешнему виду слабо отличается

Пример из моего кода:

        public int getNumberOfNodesInProximity(int microLatitude, int microLongitude, int meters)
        {                
                Polygon box=geomteryFactory.createBox(microLatitude, microLongitude, meters);

                Criteria testCriteria=getSession().createCriteria(NodeBase.class);
                testCriteria.setProjection(Projections.rowCount());
                testCriteria.add(SpatialRestrictions.within("location", box, box));
                return (Integer) testCriteria.uniqueResult();
        }

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

SLH>Объектность; Persistence; Hibernate : что дальше?

Дальше — тупик.

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

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

SLH>Некотрое время назад это делалось в реляционных базах данных, сейчас на смену им неспеша приходят те технологии, название которых перечислено в заголовке моего поста (через точку с запятой — именно потому, что это во многом — синонимы).
SLH>Меняются технологии, по которым построены интерфейсы — уже можно назвать two-layer architecture, three-layer architecture, multi-layer architecture, WEB-интерфейсы, теперь вот добавилась еще возможность писать silverlight-front приложения.
SLH>Мне это кажется неким тупиком, потому что вроде бы Hibernate во многом решает проблемы “сохранения — вытаскивания – поиска” данных, и получается что технология дошла до некой предельной точки, за которой развитие не будет происходить.
SLH>Не хочу в это верить, но не вижу никакой видимой перспективы, и хочу спросить о ней у более знающих людей.

Тупик — это сам подход — OR-Mapping. А развитие будет идти в двух направлениях:
1. Создание действительно объектно-ориентированных БД/СУБД. Причем важнешим вопросоам тут бодет поддержка высокоуровневого языка запросов и бесшовная интеграция этого языка и традиционных средств разработки. К сожалению, данное направление на сегодня не поддержано серьезными производителями и фактически в упадке.
2. Интеграция языка запросов в традиционные языки. Тут конечно на сегодня флагман (в мире мэйнстрима) — это MS LINQ.

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

Одни из вариантов развития Кибернейта — это попытка сращивания его с языком программирования с целью анализа кода и формирования "умных" запросов вытаскивающих обрабатываемые данные минимальным количеством запросов к СУБД.

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

VD>1. Создание действительно объектно-ориентированных БД/СУБД. Причем важнешим вопросоам тут бодет поддержка высокоуровневого языка запросов и бесшовная интеграция этого языка и традиционных средств разработки. К сожалению, данное направление на сегодня не поддержано серьезными производителями и фактически в упадке.
Поэтому его заменили ORMы, из которых оно, скорее всего, и вырастет.

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

VD>Собственно развитие кибернейта должно по идее пойти как раз всторону расширения функциональности языков запросов (т.е. поддержка LINQ или его аналогов), к увеличению прозрачности для программистов (чтобы он не думал о кэшах), увеличение масштабируемости и как следствие уход от идеи обработки данных навигацией по объектам и переход к запросной системе.
А вот тут необязательно. Вполне возможно, что обычная сегодняшняя навигация просто будет представлена как частный случай общей системы запросов.

Я уже так делаю:

var prefect=student.getGroup().getPrefect()
перейдёт в
var prefect=student/group/prefect

Выборка всех старост групп, в которых учатся друзья студента может быть чем-то типа:
var prefects=group[hasFriendOfStudent(student)]/prefect

VD>Одни из вариантов развития Кибернейта — это попытка сращивания его с языком программирования с целью анализа кода и формирования "умных" запросов вытаскивающих обрабатываемые данные минимальным количеством запросов к СУБД.
Зачатки этого уже есть: http://www.cs.utexas.edu/~aibrahim/autofetch/

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

VD>>Собственно развитие кибернейта должно по идее пойти как раз всторону расширения функциональности языков запросов (т.е. поддержка LINQ или его аналогов), к увеличению прозрачности для программистов (чтобы он не думал о кэшах), увеличение масштабируемости и как следствие уход от идеи обработки данных навигацией по объектам и переход к запросной системе.
C>А вот тут необязательно. Вполне возможно, что обычная сегодняшняя навигация просто будет представлена как частный случай общей системы запросов.

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

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

VD>Сама по себе идея, скажем, взять список товаров входящий в заказ из некоторого свойства/коллекции заказа не крамольна и (при условии хорошей реализации и грамотного использования) может быть довольно эффективной. Проблем только в том, что "интеллектуальное большинство" выберет наиболее простой... в достижении способ получить данные. И тут начинает действовать эмпирическое правило... Формирование запросов требует некоторого усилия со стороны интеллекта, так что для неподготовленной личности намного проще добыть данные императивно (тупо по шаря по объектам в циклах).
Поэтому и нужно интегрировать ORM с системой запросов. Я показал один из возможных примеров, LINQ тоже вполне подойдёт тут.

VD>Я слышал много речей защитников ОРМ-ов. Все они апеллировали к разумности применения ОРМ-ов. Но к сожалению, на практике все получается иначе. На мой взгляд, если кто-то начинает использовать в ОРМ-ах запросы, то он просто использует технологию не по назначению. Намного эффективнее тогда отказаться от самой идеи — смотреть на БД как на граф объектов и обрабатывать данные исключительно запросами.
Запросами очень удобно объекты получать, а потом навигацией по ним ходить на близкие расстояния. У меня в коде самый типичный случай — это обращение к parent'у элемента.

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

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

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

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

>>> У Amazon'а до нашего дата-центра примерно канал в 200Мбит

Данные раскладываются на узлы во время их запуска, а потом объединяются в кластер. Данных у нас не так много, а вот как раз процессорного времени нужно навалом.
K>>А какого вида расчеты и отчеты?
C>Data mining, поиск корреляций.

Это к слову о "главных задачах при создании бизнес-софта — сохранении и модификации данных"

. Хороший пример того, что эти задачи далеко не главные.

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

K>>>А какого вида расчеты и отчеты?
C>>Data mining, поиск корреляций.
VD>Это к слову о "главных задачах при создании бизнес-софта — сохранении и модификации данных"

. Хороший пример того, что эти задачи далеко не главные.
Отчёты — это всё-таки уже отдельная история. Они без систем сохранения и модификации данных никому не нужны

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

VD>>Это к слову о "главных задачах при создании бизнес-софта — сохранении и модификации данных"

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

Не "не нужны", а "невозможны". Вот только добавить данные в БД можно простой строчкой "Insert into (x, y, z) values (a, b, c)". И ООП тут вовсе не нужен. А вот создать сложную систему анализа данных — это задачка еще та.

Здравствуйте, Cyberax, Вы писали:
C>Отчёты — это всё-таки уже отдельная история. Они без систем сохранения и модификации данных никому не нужны

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

... << RSDN@Home 1.2.0 alpha rev. 677>>

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

VD>Подытоживая сформулирую основную идею. От ОРМ можно взять только саму идею отображения кортежей РБД в объекты ОЯП или кортежи же ФЯ, и отображение реляционных связей в нечто смахивающее на объектные коллекции. А вот идея прозрачной материализации объектов из персистентного хранилища (взятую из EJB или еще откуда-то) брать ни в коем случае нельзя, так как именно она и создает все проблемы в ОРМ.

нечто смахивающее на объектные коллекции — это например что?

Если бы я знал ответ на этот вопрос, я бы, наверно, работал сейчас в Microsoft или Sun главным системным архитектором.

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

VD>>Подытоживая сформулирую основную идею. От ОРМ можно взять только саму идею отображения кортежей РБД в объекты ОЯП или кортежи же ФЯ, и отображение реляционных связей в нечто смахивающее на объектные коллекции. А вот идея прозрачной материализации объектов из персистентного хранилища (взятую из EJB или еще откуда-то) брать ни в коем случае нельзя, так как именно она и создает все проблемы в ОРМ.

_>нечто смахивающее на объектные коллекции — это например что?

Некий объект с виду похожий на обычную коллекцию, но несущий информацию о соединение (join) таблиц. Я бы запретил прямой перебор таких коллекций допустив только запросы к ним (чтобы подчеркнуть неверность подхода с перебором). Надо тебе получить все записи из такой коллекции — используй запрос вида "x from x.SomeQueribleCollection select x" и перебирай уже его результат.

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

VD>Некий объект с виду похожий на обычную коллекцию, но несущий информацию о соединение (join) таблиц. Я бы запретил прямой перебор таких коллекций допустив только запросы к ним (чтобы подчеркнуть неверность подхода с перебором). Надо тебе получить все записи из такой коллекции — используй запрос вида "x from x.SomeQueribleCollection select x" и перебирай уже его результат.

Если нет языка запросов, что в таком случае можно сделать?
Каким образом информацию о соединениях заливать в этот некий объект? используя DI?

(сорри за ламерские вопросы, я только учусь

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

VD>1. Создание действительно объектно-ориентированных БД/СУБД. Причем важнешим вопросоам тут бодет поддержка высокоуровневого языка запросов и бесшовная интеграция этого языка и традиционных средств разработки. К сожалению, данное направление на сегодня не поддержано серьезными производителями и фактически в упадке.
VD>2. Интеграция языка запросов в традиционные языки. Тут конечно на сегодня флагман (в мире мэйнстрима) — это MS LINQ.

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

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

Я думаю причина в том что не выработана единая точка зрения на обработку данных, объединяющая весь спектр от языков до баз данных.
Исходные пункты для выработки такой точки зрения:
— функциональное программирование
— dataflow
— event oriented approach http://www.springerlink.com/content/p02q133750553220/

ну и конечно надо быть готовым отказаться от многих устаревших догм.

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

BZ>>интересная же работа может быть если ты сам разрабатываешь эти библиотеки. фишка как раз в том что тут у тебя no chances, а в областях "не для всех" ты сам пишешь для себя велосипед. поэтому и работа там более сложная и творческая
LP>Странный образ мыслей, очень странный. При чем тут j2ee и "творческость" задачи? Конкретная библиотека или технология — это лишь средство, облегчающее реализацию определенной функциональности, и все. При этом программная система может быть чем угодно — от системы паспортизации до экспертной системы.

Ийех.

Вот средство — автомобиль Ока. Облегчает он реализацию функциональности... Какой именно?

Или, вот Роллс-Ройс. Тоже средство.

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

Вот наоборот — нет. Экспертная система через паспортную не выражается.

Собственно, выражение паспортной системы через экспертную и есть подход с использованием DS(E)L, по-моему.

PS
Реализация паспортной системы с помощью паспортной же частенько попадает на Daily WTF.

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

BZ>>>интересная же работа может быть если ты сам разрабатываешь эти библиотеки. фишка как раз в том что тут у тебя no chances, а в областях "не для всех" ты сам пишешь для себя велосипед. поэтому и работа там более сложная и творческая
LP>>Странный образ мыслей, очень странный. При чем тут j2ee и "творческость" задачи? Конкретная библиотека или технология — это лишь средство, облегчающее реализацию определенной функциональности, и все. При этом программная система может быть чем угодно — от системы паспортизации до экспертной системы.

T>Ийех.

T>Вот средство — автомобиль Ока. Облегчает он реализацию функциональности... Какой именно?

T>Или, вот Роллс-Ройс. Тоже средство.

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

Я не спорю, что для каждой задачи свой инструмент. Вот непосредственно ядро ЭС можешь делать на чем угодно. (кстати, пишут эти системы и на java.). То, что в проекте в качестве бизнес-платформы испоьлзуется J2EE абсолютно побоку.

... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>

От:	VladD2	www.nemerle.org
Дата:	26.09.08 23:31
Оценка:	58 (2)

От:	VladD2	www.nemerle.org
Дата:	26.09.08 21:28
Оценка:	56 (1) +1

	От:	SteeLHeaD
	Дата:	18.09.08 14:16
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	26.09.08 05:08
Оценка:	+2

	От:	Cyberax
	Дата:	21.09.08 21:13
	Оценка:	5 (1)

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	19.09.08 15:30
Оценка:	1 (1)

От:	kosmik	http://www.linkedin.com/in/kosmik
Дата:	18.09.08 15:31
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	19.09.08 11:00
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	21.09.08 20:27
Оценка:

От:	noetic	Систематизация автоматизации
Дата:	25.09.08 14:35
Оценка:

От:	thesz	http://thesz.livejournal.com
Дата:	04.03.09 15:39
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	04.03.09 17:39
Оценка:

	От:	LaPerouse
	Дата:	03.03.09 16:12
	Оценка:	+1

	От:	BulatZiganshin
	Дата:	20.09.08 12:07
	Оценка: