Цитата(maximb @ 23.5.2005, 11:37)

Цитата(tux @ 23.5.2005, 11:28) Язык запросов, сглаживающий различия между различными СУБД, по определению должен обладать меньшими возможностями, чем язык запросов СУБД. Хотя, не спорю, в подавляющем большинстве случаев его вполне достаточно. За универсальность надо платить Понятно, что собственная реализация работы с БД (если все правильно сделано) может быть лучше чем универсальный подход, но в этом случае не надо забывать сколько времени и сил уйдет на эту собственную реализацию. + Суппорт, стоит внести небольшие изменения в модель данных или перейти на другую БД как придется переписывать массу запросов, что в Хибернейте решается простым переписыванием маппингов (и то это придется делать только в том случае если произошли изменения в модели)

не ... много слышал о Гибернейте, пока не читал така ка не надо.
Работаю с приложением - самостоятельно строящим SQL запросы.
НО!
простая штачка, (а таких много-много еще) - какую табличку ставить во from первой, а какие потом - ни один построитель запросов вам НЕ ДАСТ!
А от этого время выполнения запроса может отличаться в 10, 100, 1000 и более раз.
Ну и что теперь?

Цитата(Sleepy_PIP @ 24.5.2005, 22:14)

простая штачка, (а таких много-много еще) - какую табличку ставить во from первой, а какие потом - ни один построитель запросов вам НЕ ДАСТ! А от этого время выполнения запроса может отличаться в 10, 100, 1000 и более раз

Не верю! (с)

Ни один вменяемый оптимизатор не будет строить план выполнения запроса, основываясь на порядке перечисления таблиц во from предложении. Если действительно имело место расхождение "в 10, 100, 1000 и более раз", то очень хотелось бы узнать имя и версию СУБД, и по возможности увидеть планы запросов для разных вариантов перечисления таблиц. Если это была реальная промышленная СУБД, то единственное предположение, которое приходит в голову, это что у оптимизатора не было достаточно данных для выбора лучшей стратегии, чем ориентироваться на порядок таблиц в запросе (например, не было создано подходящего индекса или не была построена статистика).

Цитата

А может стоит использовать Hibernate Зачем изобретать велосипед

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

Проблема, которую необходимо решить, состоит в том, что в момент написания программы я не знаю, какие таблицы и view(из известного набора в сотни таблиц и тысячь view) будут использованы в запросе. В принципе, mapping для такого большого количества объектов сделать можно. А как дальше его использовать?

Т.е. у меня есть mappping и соответствующие объекты для всех таблиц и view, в результате установок параметров формы пользователем, я получаю несколько десятков параметров, по которым мне нужно построить запрос. Теперь я уже знаю, какие таблицы и поля я должен использовать, мне необходимо составить лишь запрос (строку, например) к базе данных. Запрос может быть совсем простым (на несколько строк), а можем быть более сложным - на десяток печатных страниц. Вложенные подзапросы используются очень активно, хранимые процедуры и функции не используются вообще. База - Oracle, поддержка дрегих баз не требуется.

Спасибо.

Цитата

Ни один вменяемый оптимизатор не будет строить план выполнения запроса

Кстати, Oracle работает быстрее, если использовать конструкцию в блоке where:

значение = переменная (100 = id)

вместо

переменная = значение (id = 100)

Но не в сотни раз

Странно. А почему?

Цитата(Chinook @ 25.5.2005, 20:59)

Кстати, Oracle работает быстрее, если использовать конструкцию в блоке where

Дык а план, план-то чего говорит?

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

Поэтому при любых странностях - сразу смотреть в план

Цитата(Stampede @ 25.5.2005, 21:19)

Цитата(Chinook @ 25.5.2005, 20:59) Кстати, Oracle работает быстрее, если использовать конструкцию в блоке where Дык а план, план-то чего говорит? Дело в том, что оптимизатор - это недетерминированная машина. На одной и той же базе, для одних и тех же запросов, но при разных объемах данных могут быть сгенерированы совершенно разные планы выполнения. Поэтому я бы не стал так уж категорически утверждать, что такой-то вариант работает быстрее. Не исключено, что при других условиях быстрее будет как раз наоборот. Поэтому при любых странностях - сразу смотреть в план

вот вот вот! уже ближе к истине. и на новой работе я с этим столкнулся в плотную.
НИ один оптимизатор (даже если вы натравите статистику) - не сработает лучше грамотного SQL спеца.
Это есть так и долго будет еще так.
А что уж тут говорить про построители запросос типа Хибернете, которые нифига о БД не знают! ...
Ну либо писатели не раскрыли сути процессов о том, как строить запросы к реальной БД.
В общем случае - Хибернейт - работает. Но упаси Боже это использовать на продакшене с реальными данными в несколько хотя-б гигов (а ИМХо может и меньше). ИМХО онли!.

Цитата(Sleepy_PIP @ 25.5.2005, 22:47)

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

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

Во многих больших и даже очень больших (в плане объема) OLTP системах большинство операций на самом деле совершенно тривиальны: снять с одного счета, записать на другой, подбить бабки в разных измерениях - фсе!

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

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

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

Так штааа...

В принципе, в правильно построенной OLAP базе все то же самое.

У нас как раз OLAP база, но уж очень сложная, как я уже говорил - тысячи таблиц/view. Ее бы тоже можно было бы причесать, но, во-первых, это делать пытаются, во-вторых, хоть админ у нас из физтеха(тоже русский) и весь с ног до головы в сертификатах, у него всего две руки и одна голова, в-третьих, очень сильно параметризированные отчеты, т.е. для оптимизации базы надо резко увеличить дублирование данных, а база и так уже занимает целую стойку компов. Да и приложение заточено под уже известные имена... Короче - начать и кончить.

Единственная надежда - свалить отсюда побыстрее

Цитата(Sleepy_PIP @ 25.5.2005, 22:47)

НИ один оптимизатор (даже если вы натравите статистику) - не сработает лучше грамотного SQL спеца. Это есть так и долго будет еще так. А что уж тут говорить про построители запросос типа Хибернете, которые нифига о БД не знают! ... Ну либо писатели не раскрыли сути процессов о том, как строить запросы к реальной БД. В общем случае - Хибернейт - работает. Но упаси Боже это использовать на продакшене с реальными данными в несколько хотя-б гигов (а ИМХо может и меньше). ИМХО онли!.

Это проблема легко решается средствами view, т.е. выносишь все сложные запросы в различные view, и собственно проблема решена, во всех виденных мной реализациях делалось именно так.
Добавлено @ 08:46

Цитата(Chinook @ 25.5.2005, 19:51)

Проблема, которую необходимо решить, состоит в том, что в момент написания программы я не знаю, какие таблицы и view(из известного набора в сотни таблиц и тысячь view) будут использованы в запросе. В принципе, mapping для такого большого количества объектов сделать можно. А как дальше его использовать?

Не совсем понял проблему обьясни по подробнее

Цитата

Не совсем понял проблему обьясни по подробнее

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

1. Есть какой-то набор таблиц/view.
2. Пользователь выбирает на странице параметры (много параметров). На основе данных параметров надо сформировать запрос к БД.

Т.е. в очень сильном приближении это выглядит так:

1. получем первый параметр п1, на его основе определяем, что используется таблица Т1
2. получаем второй параметр п2 - таблица Т2
3. третий п3 - Т3
4. четвертый п4 - надо сформировать select из таблицы Т4, Т5, Т6, Т7, параметрами запроса являются поля п5, п6, п7
5. получаем п7 - и т.д.

При этом какие таблицы использовать, мы узнаем только в процессе работы, т.к. эти данные выбает некая структура таблиц в базе данных(metadata). Если надо добавить новые значения параметров и новое поведение программы, то все это добавляется в БД, а не в код.

Но metadata говорит мне, что вот это, например, поля вывода (select), вот это таблица/view/подзапрос, а это where.

Т.е. сейчас это последовательность операторов if...else and switch. Это не очень приятно:

1. select a1, a2, a3 from a where a5 = 1000
2. Теперь выясняется, что надо еще использовать таблицу b. Я должен найти слово "from " и вставить вместо него "from b, ", дальше найти слово "where " и заменить его на "where b.b1 = a.a1 and ". Результат: "select a1, a2, a3 from b, a where b.b1 = a.a1 and a5 = 1000"
3. после этого выясняется, что в запросе участвует таблица с... И опять сначала.

А таких таблиц может быть, например, 30, половина из которых в подзапросах. Можно себе представить, как выглядит код. Именно формирование строки и нужно автоматизировать.

Впрочем, никто, кроме меня, такой необходимости не видит.

Цитата(Chinook @ 26.5.2005, 22:08)

Впрочем, никто, кроме меня, такой необходимости не видит

Да видим, видим. Тут важно понять вот какую вещь. У тебя есть юзер-интерфейсное представление запроса, а тебе надо преобразовать его в SQL эквивалент. Если пытаться это делать напрямую, то получится невообразимая каша - то, что имеет место в вашей системе. А если подойти к решению по-грамотному, то станет очевидно, что между этими двумя представлениями нужно ввести еще одно, промежуточное - программную модель запроса. После этого преобразование из одного в другое сведется к цепочке:

юзерское представление - программное представление - код SQL

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

И эта... ты там вообще хоть пробуешь что-нибудь? А ты уже неделю жалуешься, а делать - не делаешь.

Короче, держи нас в курсе - нам тоже интересно

Цитата

юзерское представление - программное представление - код SQL

Это понятно, только "программное представление" у нас делится на две части:
1. matadata, которые переводят запрос клиента (поля формы) в набор сущьностей БД, она уже разработана, но не написана.
2. конструктор, как я описал выше(причем их десятки для разных отчетов), который я хочу заменить на свой.

Цитата

И эта... ты там вообще хоть пробуешь что-нибудь?

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

А вообще-то меня тут все достало и я ищу другую работу :-)