| 1.1, uZver (??), 10:30, 23/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
отличный проект. если оно еще линейно масштабируется, то вообще супер.
Единственно что не понятно, так это почему PostgreSQL (написанный на С или С++), а не Apache Derby (java)
| | |
| |
| |
| 3.6, uZver (??), 14:06, 23/07/2009 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Язык хорош. PostgreSQL - вообще отличная вещь.
Вопрос: нафига делать сборную солянку java + C особенно если есть возможность обойтись одной java? Зоопарк языков - ИМО не лучшее решение.
| | |
|
| 2.4, vbv (??), 11:59, 23/07/2009 [^] [^^] [^^^] [ответить]
| –6 +/– |
java - в топку и с ним derby.
А PostgreSQL - действительно нормальная бд. Потрируется и на форточки и на маки.
Производительность С кода во много выше java.
Относительно темы: Идея хороша, и данные решения имеют смысл только для узкого круга задач, т.к. на данный момент, как не крути, SQL - есть стандарт (который не везде соблюдается но тем не менее - работает). Полного перехода на новую систему можно не ждать. А вот исполнения сервером запросов поданных ему в скомпилированной форме возможно было бы интересно. т.е. 1. Делаем SQL запрос. 2. Просим СУБД вернуть компилированную форму - которую уже используем в проекте. Хотя, даже, ценность этого подхода вызывает сомнения, т.к. порядочные системы управления базами данных успешно кешируют запросы.
| | |
|
| 1.9, Gambler (ok), 00:34, 24/07/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
SQL поразительно плохо генерируется из кода. На мой взгляд, по одной этой причине надо искать альтернативу. Желательно, попроще.
| | |
| |
| 2.11, Аноним (-), 10:51, 24/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
Вы думаете альтернатива сама, волшебным образом будет решать проблему оптимизации ?
| | |
| 2.12, uZver (??), 11:06, 24/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> SQL поразительно плохо генерируется из кода.
SQL в принципе не должен генерироваться из кода. SQL и есть код. А большинство приложений имеют код на двух языках SQL + java (C#)
| | |
| |
| 3.13, Gambler (ok), 20:17, 24/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> SQL в принципе не должен генерироваться из кода. SQL и есть код.
Приложениям надо где-то хранить данные. Индексированные данные, с которыми можно быстро проводить массивные операции. В основном это делается в реляционных базах данных, которые используют SQL.
Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.
В любом случае, SQL не рассчитан на компьютерную генерацию, но она все равно имеет место.
| | |
| |
| 4.14, uZver (??), 11:08, 25/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью.
моя твоя не понимать.
1. select * from table where name = 'Вася' вернет 10 строк.
2. select * from table where name = 'Петя' вернет 20 строк (к примеру).
но по сути это один и тот же параметризованный запрос. и генерации никакой нет.
вложенные запросы преобразуются оптимизатором в обычный join, если это возможно. Потому для СУБД первой тройки скорость запроса с подзапросом и запроса через join одинакова (хотя есть множество нюансов которые грамотный ДБА должен знать).
Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос с динамическим фильтром - но как его реализовать без динамического описания запроса (на любом языке не обязательно на SQL) мне не понятно.
| | |
| |
| 5.15, pro100master (ok), 11:55, 25/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>но по сути это один и тот же параметризованный запрос. и генерации никакой нет.
а такой (надуманно)?
select
a1.a as a1,
a2.a as a2,
a3.a as a3,
...
aN.a as aN,
from xxx x where x.fignja>1
left join test1 a1 on a1.a=1
...
где N [1..X]
>Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос
>с динамическим фильтром - но как его реализовать без динамического описания
>запроса (на любом языке не обязательно на SQL) мне не понятно.
>
люди уже с самого начала реляционных баз курят эту проблему. Они говорят, что идеальный ORM без интеграции самого SQL в язык невозможен. А вынести SQL за пределы кода возможно лишь в единичных и очень примитивных случаях. Так что пока такой язык не появится, каждый будет делать так, как ему удобно, пусть и с костылями.
| | |
| |
| 6.17, uZver (??), 11:21, 26/07/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> а такой (надуманно)?
select
a1.a as a1,
a2.a as a2,
a3.a as a3,
...
aN.a as aN,
from xxx x where x.fignja>1
left join test1 a1 on a1.a=1
...
где N [1..X]
в том то и дело, что надуманно. Как часто ван нужны такие запросы? Мне понадобилось когда писал обработку данных на СУБД. и то потому что ленив и влом было имена столбцов и таблиц переписывать - написал хранимку, а таблицу задавал параметром.
| | |
|
| 5.16, Gambler (ok), 19:09, 25/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
> моя твоя не понимать.
> 1. select * from table where name = 'Вася' вернет 10 строк.
> 2. select * from table where name = 'Петя' вернет 20 строк (к примеру).
Покажите мне, пожалуйста, как вы напишете функцию типа selectBy(fildName, fieldValue) без генерации кода.
>вложенные запросы преобразуются оптимизатором в обычный join
http://www.selikoff.net/blog/2008/12/10/memo-avoid-nested-queries-in-mysql-at
> хотя есть множество нюансов которые грамотный ДБА должен знать
Причем тут DBA? Речь идет про запросы, например, из ORM. Логика определяется вешней программой, и на время написания ORM нельзя знать, что именно будет делать эта программа.
| | |
| |
| 6.18, uZver (??), 11:26, 26/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Покажите мне, пожалуйста, как вы напишете функцию типа selectBy(fildName, fieldValue) без генерации
>кода.
criteria.add(Expression.eq(fieldName,fieldValue));
хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы знаете как это реализовать БЕЗ динамического изменения SQL?
>
>>вложенные запросы преобразуются оптимизатором в обычный join
>
>http://www.selikoff.net/blog/2008/12/10/memo-avoid-nested-queries-in-mysql-at
я написал что для первой тройки: Oracle, MS SQL server, DB2.
| | |
| |
| 7.19, Gambler (ok), 20:38, 26/07/2009 [^] [^^] [^^^] [ответить]
| +/– |
> хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы
> знаете как это реализовать БЕЗ динамического изменения SQL?
А разве я говорил, что надо бороться с динамической генерацией запросов? Наоборот, я говорю, что нужно решение, где динамическая генерация запросов проще, логичней и не создает таких проблем с производительностью.
> я написал что для первой тройки: Oracle, MS SQL server, DB2.
Это ж опеннет. Тут первая тройка, пожалуй, должная быть MySQL, PostgreSQL и SQLight. Ну или что-то в этом роде.
| | |
|
|
|
|
|
|
|
