Процедуры в БД - это же ужас-ужас!!!
От: Эйнсток Файр Мухосранск Странный реагент
Дата: 14.01.19 03:18
Оценка: +6
http://rsdn.org/forum/philosophy/7333307.1
Автор: Географ
Дата: 25.12.18

процедуры в БД (если по хорошему делать)


Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
Re: Процедуры в БД - это же ужас-ужас!!!
От: _ABC_  
Дата: 14.01.19 04:26
Оценка: +1 -2
Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Что же в этом хорошего?

Ничего хорошего. Ты только не волнуйся.

ЭФ>База данных — самое немасштабируемое место в системе.

Не используй базы данных.
Re: Процедуры в БД - это же ужас-ужас!!!
От: LaptevVV Россия  
Дата: 14.01.19 04:27
Оценка: 6 (1) :)
ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
А ты читал Рефакторинг баз данных?
Я — нет...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Процедуры в БД - это же ужас-ужас!!!
От: scf  
Дата: 14.01.19 06:48
Оценка: 1 (1) +2 -3
Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>http://rsdn.org/forum/philosophy/7333307.1
Автор: Географ
Дата: 25.12.18

ЭФ>

процедуры в БД (если по хорошему делать)


ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.


По-хорошему где-то должен быть слой изоляции структуры БД от остальной системы. Единая точка входа для чтения и записи в таблицу, полезно при рефакторинге и оптимизации структуры БД, аудита, разграничения прав и т.п. Лично я предпочитаю микросервис, но слой хранимых процедур тоже приемлемый вариант. Главное, стараться не добавлять туда бизнес-логику.
Re[2]: Процедуры в БД - это же ужас-ужас!!!
От: Kswapd Россия  
Дата: 14.01.19 08:33
Оценка: +1 -2 :))) :)))
Здравствуйте, scf, Вы писали:

scf>По-хорошему где-то должен быть слой изоляции структуры БД от остальной системы.


Да, это с очевидностью следует из DIP (принципа инверсии зависимости, говорящий, что нетривиальные зависимости должны ссылаться только на абстрактные интерфейсы): высокоуровневый компонент (реализующий бизнес-логику) не должен зависеть от низкоуровневого (хранилища данных), зависимость должна быть обратной (например, от этого самого изолирующего слоя).

А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.
Re: Процедуры в БД - это же ужас-ужас!!!
От: vsb Казахстан  
Дата: 14.01.19 08:59
Оценка: +3
Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>http://rsdn.org/forum/philosophy/7333307.1
Автор: Географ
Дата: 25.12.18

ЭФ>

процедуры в БД (если по хорошему делать)


ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.


Согласен. Хранимки считаю только инструментом оптимизации для редких случаев.
Re: Процедуры в БД - это же ужас-ужас!!!
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 14.01.19 11:08
Оценка:
Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>http://rsdn.org/forum/philosophy/7333307.1
Автор: Географ
Дата: 25.12.18

ЭФ>

процедуры в БД (если по хорошему делать)


ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.


Ну вот нужно тебе использовать функции которых нет в SQL. Тут либо все тащить на клиента, либо писать хранимые процедуры например для регекспов
https://www.red-gate.com/simple-talk/sql/t-sql-programming/clr-assembly-regex-functions-for-sql-server-by-example/
и солнце б утром не вставало, когда бы не было меня
Re[3]: Процедуры в БД - это же ужас-ужас!!!
От: Gt_  
Дата: 20.01.19 12:05
Оценка: -1
K>Да, это с очевидностью следует из DIP (принципа инверсии зависимости, говорящий, что нетривиальные зависимости должны ссылаться только на абстрактные интерфейсы): высокоуровневый компонент (реализующий бизнес-логику) не должен зависеть от низкоуровневого (хранилища данных), зависимость должна быть обратной (например, от этого самого изолирующего слоя).

K>А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.


ерунда. как рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка, т.к. вермишель лишь в студенческих задачках гладко работает, а в реальных условиях не масштабируется и требует диких трудозатрат и костылей. в 80х и 90х наступали объектные субд, позволявшие хранить вермишель объекты в субд, потом были их подварианты с xml базами. когда объектные субд не взлетели начали натягивать ормы на реляционную модель. и это оказалось не работает, и ормы вышли из моды.
вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.

Gt_
Отредактировано 20.01.2019 12:08 Gt_ . Предыдущая версия .
Re: Процедуры в БД - это же ужас-ужас!!!
От: kov_serg Россия  
Дата: 20.01.19 17:28
Оценка: 1 (1) :)
Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>http://rsdn.org/forum/philosophy/7333307.1
Автор: Географ
Дата: 25.12.18

ЭФ>

процедуры в БД (если по хорошему делать)


ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.

А чего плохово
https://habr.com/ru/post/435390/
Re[4]: Процедуры в БД - это же ужас-ужас!!!
От: Kswapd Россия  
Дата: 20.01.19 18:56
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_>рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка


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

Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
Re[5]: Процедуры в БД - это же ужас-ужас!!!
От: scf  
Дата: 20.01.19 19:21
Оценка:
K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?

Для того, чтобы это можно было извлечь. Данные живут дольше, чем код, поэтому отдельное приложение, предназначенное для хранения данных, никуда не уйдет. Ну и вторая причина — чтобы можно было обновлять программу без потери данных
Re[6]: Процедуры в БД - это же ужас-ужас!!!
От: Kswapd Россия  
Дата: 20.01.19 19:27
Оценка:
scf>Для того, чтобы это можно было извлечь. Данные живут дольше, чем код, поэтому отдельное приложение, предназначенное для хранения данных, никуда не уйдет. Ну и вторая причина — чтобы можно было обновлять программу без потери данных.

В этом будущем гипотетическом компьютере программа обновляется прямо в RAM, без влияния на данные. Если нужно преобразовать данные, они копируются "рядом" (памяти хватит на всё!), а старая версия, если не нужна — удаляется. И всё без участия дисков.
Re[7]: Процедуры в БД - это же ужас-ужас!!!
От: _ABC_  
Дата: 20.01.19 19:59
Оценка: +1
Здравствуйте, Kswapd, Вы писали:

K>В этом будущем гипотетическом компьютере программа обновляется прямо в RAM, без влияния на данные. Если нужно преобразовать данные, они копируются "рядом" (памяти хватит на всё!), а старая версия, если не нужна — удаляется. И всё без участия дисков.

Ну вот когда этот гипотетический компьютер перестанет быть гипотетическим, тогда и поговорим...
А пока будем говорить о реалиях.
Re[3]: Процедуры в БД - это же ужас-ужас!!!
От: Ромашка Украина  
Дата: 20.01.19 20:33
Оценка:
Здравствуйте, Kswapd, Вы писали:

K>А если попытаться заглянуть в будущее, то дисков не будет, их заменит RAM. "The Database Is a Detail" (Роберт Мартин). Приложению нужны не диски, а RAM. Приложению нужны не таблицы и не KV-хранилища, а данные, организованные в нормальные программные структуры — массивы, очереди, стеки, деревья и т.п. Существование баз данных — временный преходящий этап, который закончится с нынешней эпохой дефицита RAM и вымиранием дисков (как до того вымерли ленты). Закладывать бизнес-логику внутрь базы данных недальновидно ещё и по этой причине.


Блин, где я это слышал??? Нет, ну говорил же кто-то... или не говорил... или делал??? Черт, вспомнил... Ну, у меня для тебя плохие новости — это DB2, оно уже сдохло.


Всё, что нас не убивает, ещё горько об этом пожалеет.
Re[5]: Процедуры в БД - это же ужас-ужас!!!
От: Gt_  
Дата: 21.01.19 05:59
Оценка: 3 (1)
K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?

Мартин в коме последние годы? in-memory storage в оракле уже лет пять реализован. причем "хранение" в памяти переделано на колончатое.

Gt_
Re: Процедуры в БД - это же ужас-ужас!!!
От: elmal  
Дата: 22.01.19 04:18
Оценка: +2
Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.

Там хорошего ровно одно. Эти процедуры размещены близко к данным, выполняются на той же машине, что и данные. За счет чего для какой то логики не нужно гонять данные по сети. И потенциально для некоторых случаев это позволяет добиться гораздо большей скорости.
Re[3]: Процедуры в БД - это же ужас-ужас!!!
От: Ziaw Россия  
Дата: 22.01.19 05:05
Оценка: 3 (1) +2
Здравствуйте, Kswapd, Вы писали:

K>"The Database Is a Detail" (Роберт Мартин).


Это настолько детская ошибка, что мне удивительно как то, что Мартин от нее до сих пор громко не отказался, как и то, что ее регулярно транслируют.

Я тут еще накидаю:

Presentation Layer Is a Detail.
Network Protocol Is a Detail.
Programming Language Is a Detail.

По факту же, попытка полностью абстрагироваться от деталей реализации хранилища заметно дороже, чем переписывание системы на другое хранилище при необходимости. Абстрагироваться стоит только там, где это не вредит качеству кода и не рушит производительность.
Re[4]: Процедуры в БД - это же ужас-ужас!!!
От: SomeOne_TT  
Дата: 22.01.19 06:24
Оценка:
Здравствуйте, Gt_, Вы писали:

Gt_>вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.


Вот это сейчас всерьез было, сравнивать рсубд со спарком, в котором хорошим тоном является денормализация данных?
Re[5]: Процедуры в БД - это же ужас-ужас!!!
От: Gt_  
Дата: 22.01.19 07:33
Оценка:
Gt_>>вот и сейчас похоже история делает еще один круг. на острие прогресса — бигдате популярен spark framework. все основные концепции рсубд туда перекочевали — логика выполняется там где хранятся данные, вместо табличек датафреймы, практически всегда плоские таблички. синтаксис работы с датафрейм по сути sql, с select, sum, join, так же как в рсубд датафрейм скорее декларативная конструкция, которую на ходу оптимизатор превращает в реальный план доступа к данным.

SO_>Вот это сейчас всерьез было, сравнивать рсубд со спарком, в котором хорошим тоном является денормализация данных?


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

Gt_
Re[2]: Процедуры в БД - это же ужас-ужас!!!
От: Gt_  
Дата: 22.01.19 07:38
Оценка:
ЭФ>>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
E>Там хорошего ровно одно. Эти процедуры размещены близко к данным, выполняются на той же машине, что и данные. За счет чего для какой то логики не нужно гонять данные по сети. И потенциально для некоторых случаев это позволяет добиться гораздо большей скорости.

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

Gt_
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.