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

Ленивые БД

 


0

4

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

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

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

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

★★★★★

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

ORM
Map Reduce

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от 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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.