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

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

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

Gt_

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

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

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

Gt_