https://217.65.3.21/openforum/vsluhforumID3/57142.html Не использующие SQL системы обработки данных, такие как Hadoop и MapReduce, могут быть очень дешевыми и прекрасно масштабироваться. Тем не менее, по скорости написания запросов и простоте использования они проигрывают традиционным реляционным базам данных. И вот, ученые из Йельского университета (Yale University), кажется, сумели взять лучшее от обеих концепций: они создали (http://news.idg.no/cw/art.cfm?id=9D2C109A-1A64-6A71-CE90BD44D98F12B1) гибридную систему, отличающуюся высокой производительностью и практически неограниченной масштабируемостью.<br><br>HadoopDB анонсировал в своем блоге профессор Йельского университета Daniel J. Abadi. Система собрана из нескольких opensource компонентов, включающих PostgreSQL, Apache Hadoop и модуль сортировки Hive. Она принимает запросы, написанные как в формате MapReduce, так и в традиционной SQL форме. Обработка запросов осуществляется частично движком Hadoop, и частично некоторым числом экземпляров PostgreSQL, объединенных в shared-nothing кластер....<br><br>URL: http://tech.sl https://217.65.3.21/openforum/vsluhforumID3/57142.html#20 Mon, 27 Jul 2009 11:22:32 GMT А еще нужнее решение где нажал на одну кнопку "сделать зашибись" и все хорошо. Реально то вы что предлагаете ? За счет чего может стать проще но при этом не тормознутее ? Дело не в том что SQL плох, а в том что ООП для него уж больно неконкретен, на устранение этой неконкретности силы и уходят. Будет менее конкретное средство, будет может и проще, но менее оптимально, будет более конкретное - соответственно наоборот. Ничего в результате не меняется, разве что просто для того чтобы поиметь альтернативу, кому что ближе тот то пользовать и будет.<br> https://217.65.3.21/openforum/vsluhforumID3/57142.html#19 Sun, 26 Jul 2009 16:38:15 GMT &gt; хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы <br>&gt; знаете как это реализовать БЕЗ динамического изменения SQL?<br><br>А разве я говорил, что надо бороться с динамической генерацией запросов? Наоборот, я говорю, что нужно решение, где динамическая генерация запросов проще, логичней и не создает таких проблем с производительностью.<br><br>&gt; я написал что для первой тройки: Oracle, MS SQL server, DB2.<br><br>Это ж опеннет. Тут первая тройка, пожалуй, должная быть MySQL, PostgreSQL и SQLight. Ну или что-то в этом роде.<br> https://217.65.3.21/openforum/vsluhforumID3/57142.html#18 Sun, 26 Jul 2009 07:26:05 GMT &gt;Покажите мне, пожалуйста, как вы напишете функцию типа selectBy(fildName, fieldValue) без генерации <br>&gt;кода. <br><br>criteria.add(Expression.eq(fieldName,fieldValue));<br><br>хотя согласен, что критерия внутри себя будет строить SQL динамически. так вопрос - вы знаете как это реализовать БЕЗ динамического изменения SQL?<br><br>&gt;<br>&gt;&gt;вложенные запросы преобразуются оптимизатором в обычный join<br>&gt;<br>&gt;http://www.selikoff.net/blog/2008/12/10/memo-avoid-nested-queries-in-mysql-at-all-costs/ <br><br>я написал что для первой тройки: Oracle, MS SQL server, DB2.<br> https://217.65.3.21/openforum/vsluhforumID3/57142.html#17 Sun, 26 Jul 2009 07:21:59 GMT &gt; а такой (надуманно)?<br><br>select<br> a1.a as a1,<br> a2.a as a2,<br> a3.a as a3,<br>...<br> aN.a as aN,<br>from xxx x where x.fignja&gt;1<br>left join test1 a1 on a1.a=1<br>...<br>где N [1..X]<br><br>в том то и дело, что надуманно. Как часто ван нужны такие запросы? Мне понадобилось когда писал обработку данных на СУБД. и то потому что ленив и влом было имена столбцов и таблиц переписывать - написал хранимку, а таблицу задавал параметром.<br> https://217.65.3.21/openforum/vsluhforumID3/57142.html#16 Sat, 25 Jul 2009 15:09:47 GMT &gt; моя твоя не понимать.<br>&gt; 1. select * from table where name = 'Вася' вернет 10 строк.<br>&gt; 2. select * from table where name = 'Петя' вернет 20 строк (к примеру).<br><br>Покажите мне, пожалуйста, как вы напишете функцию типа selectBy(fildName, fieldValue) без генерации кода.<br><br>&gt;вложенные запросы преобразуются оптимизатором в обычный join<br><br>http://www.selikoff.net/blog/2008/12/10/memo-avoid-nested-queries-in-mysql-at-all-costs/<br><br>&gt; хотя есть множество нюансов которые грамотный ДБА должен знать<br><br>Причем тут DBA? Речь идет про запросы, например, из ORM. Логика определяется вешней программой, и на время написания ORM нельзя знать, что именно будет делать эта программа.<br> https://217.65.3.21/openforum/vsluhforumID3/57142.html#15 Sat, 25 Jul 2009 07:55:21 GMT &gt;но по сути это один и тот же параметризованный запрос. и генерации никакой нет.<br><br>а такой (надуманно)?<br>select <br> a1.a as a1, <br> a2.a as a2,<br> a3.a as a3,<br> ...<br> aN.a as aN,<br>from xxx x where x.fignja&gt;1<br>left join test1 a1 on a1.a=1<br>...<br>где N [1..X]<br><br>&gt;Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос <br>&gt;с динамическим фильтром - но как его реализовать без динамического описания <br>&gt;запроса (на любом языке не обязательно на SQL) мне не понятно. <br>&gt;<br><br>люди уже с самого начала реляционных баз курят эту проблему. Они говорят, что идеальный ORM без интеграции самого SQL в язык невозможен. А вынести SQL за пределы кода возможно лишь в единичных и очень примитивных случаях. Так что пока такой язык не появится, каждый будет делать так, как ему удобно, пусть и с костылями.<br> https://217.65.3.21/openforum/vsluhforumID3/57142.html#14 Sat, 25 Jul 2009 07:08:23 GMT &gt; Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью. <br><br>моя твоя не понимать.<br><br>1. select * from table where name = 'Вася' вернет 10 строк.<br>2. select * from table where name = 'Петя' вернет 20 строк (к примеру).<br><br>но по сути это один и тот же параметризованный запрос. и генерации никакой нет.<br><br>вложенные запросы преобразуются оптимизатором в обычный join, если это возможно. Потому для СУБД первой тройки скорость запроса с подзапросом и запроса через join одинакова (хотя есть множество нюансов которые грамотный ДБА должен знать).<br><br>Конечно я знаю вид запросов которые требуют динамической генерации. к примеру запрос с динамическим фильтром - но как его реализовать без динамического описания запроса (на любом языке не об https://217.65.3.21/openforum/vsluhforumID3/57142.html#13 Fri, 24 Jul 2009 16:17:44 GMT &gt; SQL в принципе не должен генерироваться из кода. SQL и есть код.<br><br>Приложениям надо где-то хранить данные. Индексированные данные, с которыми можно быстро проводить массивные операции. В основном это делается в реляционных базах данных, которые используют SQL. <br><br>Писать вручную запросы для каждого случая не практично. Если у вас одна функция требует 10 строк из БД, а другая - 20ть, но выбираются они по тем же принципам, то вы уже вынуждены частично генерировать SQL из кода. Но это страшно неудобно. Правда, со вложенными запросами это попроще, но тогда неизвестно что происходит с производительностью. <br><br>В любом случае, SQL не рассчитан на компьютерную генерацию, но она все равно имеет место.<br> https://217.65.3.21/openforum/vsluhforumID3/57142.html#12 Fri, 24 Jul 2009 07:06:56 GMT &gt; SQL поразительно плохо генерируется из кода.<br><br>SQL в принципе не должен генерироваться из кода. SQL и есть код. А большинство приложений имеют код на двух языках SQL + java (C#)<br>