Здравствуйте, 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>А вот тут необязательно. Вполне возможно, что обычная сегодняшняя навигация просто будет представлена как частный случай общей системы запросов.

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

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

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

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

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

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

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

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

Здравствуйте, 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>Поэтому и нужно интегрировать ORM с системой запросов. Я показал один из возможных примеров, LINQ тоже вполне подойдёт тут.

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

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

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

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

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

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

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

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

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

Здравствуйте, 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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