LINUX.ORG.RU
решено ФорумTalks

Ленивые БД

 


0

4

Заранее хочу извиниться, но меня покусали anonimous на пару с phill, и я не могу не запостить свою гениальную идею.

Как мы знаем, реляционная БД, грубо говоря, представляет собой набор связанных таблиц. К таблицам можно делать запросы на SQL или SQL-подобном язычке. Мой вопрос/идея состоит в следующем: а что, если соответствующие поля в результате запроса будут не заданы статически на момент запроса, а сформированы, вычислены, в зависимости от параметров и структуры самого запроса? Ячейка таблицы, соответственно, будет содержать процедуру вычисления значения.

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

Есть ли такое? Не изобрел ли я какой-нибудь LINQ? Или же такое возможно просто на уровне современных СУБД? Нужно ли это вообще?

★★★★★

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

ViTeX ★★★★ ()
Ответ на: комментарий от ViTeX

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

buddhist ★★★★★ ()
Последнее исправление: buddhist (всего исправлений: 1)

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

gh0stwizard ★★★★★ ()

petrosyan mode

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

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

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

shimon ★★★★★ ()

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

imul ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

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

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

buddhist ★★★★★ ()
Последнее исправление: buddhist (всего исправлений: 1)
Ответ на: комментарий от true_admin

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

buddhist ★★★★★ ()
Ответ на: комментарий от selivan

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

ViTeX ★★★★ ()
Ответ на: комментарий от buddhist

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

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

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

deep-purple ★★★★★ ()

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

vertexua ★★★★★ ()
Ответ на: комментарий от vertexua

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

vertexua ★★★★★ ()
Ответ на: комментарий от true_admin

ORM
Map Reduce

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

true_admin ★★★★★ ()

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

Shadow ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от vertexua

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

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

vertexua ★★★★★ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от vertexua

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

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

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

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

deep-purple ★★★★★ ()

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

zloelamo ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.