Мне кстати нужна такая штука, но, по-моему, это решается и средствами самих БД, я ещё не разбирался.

Мне что-то подобное вроде бы тоже понадобилось, но я по-другому взглянул на задачу, и все решилось проще.

PL/SQL (pgpl) позволяет делать и не такое. Расплата будет в том, что масштабируемость таких систем расчитывается из двух факторов: масштабируемость БД + посторонняя нагрузка (plain-запросы). В тех решениях, где plain-запросы составляют лвиную долю нагрузки, решение на PL/SQL будет проигрывать по производительности (а также больших требованиях в серверах), чем аналогичное решение на БД + standalone logic server.

petrosyan mode

SELECT * FROM table;
 +------------------------------------------+
 | Sorry, dude, I don't feel like selecting |
 +------------------------------------------+

Спасибо за ответ, совсем забыл про PL/SQL.

view?

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

Мусью, вы слышали, что такое views?

А можно пример? А то я в упор не понимаю о чём речь. Ты же ведь не о том чтобы в «select <FIELDS> from ..» опустить эти самые FIELDS?

Потом, есть такая штука как ORM. Это чтобы вообще с sql не возиться (теоретически)/

ТС просто переизобрёл views. Расходимся. :)

Очень наивный пример:

- Задано число K.

- Есть N = K + 1 значений, которые нам нужно получить в ответе на запрос: p0, ..., pN.

- Есть K полей, по которым поставлены условия: f0, ..., fK.

- Значение поля pi должно быть вычисляемым, в зависимости от заданного K.

На практике у меня: fj — некоторое вещество, с заданными термодинамическими, химическими потенциалами. Имеется набор данных, таблица, с этими значениями. Хотелось уметь сделать к этому набору запрос по нескольким веществам — {fK, xK} (где xK — концентрация), то есть по смеси веществ из таблицы, и получить в ответ множество {pN} = {\alpha_{ij}}, множество относительных летучестей.

http://www.tutorialspoint.com/postgresql/postgresql_views.htm

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

Ну виды не совсем то. В моём случае надо было тригерные функции писать на sql, но я пока не осилил.

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

SELECT (t1.fld1 + 200) fld1p200 FROM tbl1 t1

SELECT NOW() `now`

SELECT COUNT(t1.fld1) fld1cnt, SUM(t1.fld1) fld1sum FROM tbl1 t1 GROUP BY t1.fldN

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

CouchDB работает в некоторой мере похожим образом. Не в точности так, но ты подаешь на вход некие обьекты, их видят в реальном времени Map Reduce функции и строят нужные View

Прочитал внимательно, я сам подумал что ты переизобрел материализированные view, но ты переизобрел обычные

ORM
Map Reduce

Вот чесслово, меня убивает это огромное кол-во надстроек-прослоек для получения конечного результата. Более того, понапилют мильён строк на все это, а потом сидят и думаю как бы закешировать, как бы оптимизировать. Да никак, не поленись и напиши кастомный SQL-запрос. Но нет - «удобство» разработчика важнее, ага ))

Всё зависит от задач же. SQL это, имхо, в первую очередь плоские таблицы. Кроме таблиц с ключами есть и другие структуры данных которые могут лучше подойти. Хотя, конечно, их можно сэмулировать плоскими таблицами или специальными типами хранилищ.

надстроек-прослоек

Map Reduce

напиши кастомный SQL-запрос

facepalm

Oracle иди кури, включая его BI. Там много вкусного, бесконечно умного и бесконечно дорогого.

facepalm

аргументы?

Почему MapReduce надстройка над SQL?

Ах ты об ентом. А что тогда вот это: http://www.asterdata.com/resources/img/diagrams_product/SQLMRintegration.png

Где тут отсутствие прослойки над «классическим» SQL?

В данном случае SQL может транслироваться (наверное) в MapReduce, а не наоборот

плоские таблицы

ну вот я и вангую что «плоских таблиц» для задачи будет вполне достаточно, я даже могу писнуть запрос если ТС опишет задачу более подробно

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

который однозначно будет иметь место

Почему вдруг? Ну выполняю я распределенный MapReduce на каком-то Hive (который похож на SQL) поверх Hadoop. Он сработает с такой же скоростью как если бы я его написал руками в виде Java класса. Кроме редких случаев когда в Java коде будет что-то очень сложное и будут специфичные оптимизации

Нужно понимать КАК работают прослойки. Допустим у тебя есть язык X, который транслируется в язык Y, который транслируется в язык Z. Это делают соответствующие трансляторы за 3мс в памяти выдавая на выходе язык Z. После этого язык Z выполняется два дня. Какая разница с написанием этого всего сразу на языке Z, который наверняка более громоздкий иначе зачем нужен этот X

на языке Z, который наверняка более громоздкий иначе зачем нужен этот X

Вот именно, зачем нужен Х, когда за одну транзакцию/запрос ты уже получаешь результат, не используя оферхедные трансляторы на жаве-пыхе-etc, а уж если ты оверхедишь с пинанием данных туда-сюда, из транслятора в транслятор, с клиента на сервер и обратно, в цикле, то это вообще жесть. А сколько лишних данных возвращают некоторые из реализаций ORM я вообще молчу. А транслятор обязательно обкакается на какой-либо нестандартной задаче.

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

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

Ты изобрел view? Или я тебя не понял?