Здравствуйте, Sinclair, Вы писали:

V>>Есть языки и/или расширения к имеющимся (к С++, например), которые переводят второе в первое.
V>>То бишь, параллелят, если данные уже в памяти.
S>Ничего не получится. На всякий случай напомню, что речь — про lazy load, и невинная итерация по коллекции orders скрывает за собой возможный раундтрип до СУБД.

Сосредоточься. Я говорил о компиллируемом коде на стороне БД.


V>>Ну, начнём с того, что постановка вопроса "удобства" во главу угла является ошибкой, бо это не первопричина, а следствие. Это удобство сегодня требуется из-за тотального разрыва в стеке технологий в случае "обычного SQL" и является лишь способом адаптации разработчиков к такому разрыву.
S>Это как раз первопричина. Нужно понимать, что данные — это факты. Трактовка этих фактов (бизнес-правила) меняются по пять раз в квартал. А вот сами данные остаются теми же самыми. И разрыв в стеке технологий тут совершенно ни при чём.

Весёлый ты. ))
"Ребята, нужно понимать, что береза — это дерево. А листья сбрасываются раз в год. Поэтому, снегири тут не при чём."

Умудрился дважды сам себе противоречить в одной фразе.
"данные остаются теми же"
"меняется код"
"но разрыв технологий не при чём"
При том что именно разрыв технологий делает каждое изменение логики чудовищно дорогим.
Стоимость изменения пары строк в БД сегодня равна стоимости изменения десятков тыщ строк на "обычном ЯП".
Т.е. твой разрыв технологий, который "не при чём", делает развитие базы совершенно неприличным по стоимости и тормознутости занятием.
Развитие кода БД медленное, реакция на изменения бизнес-логики страшно не оперативная, фактически ступор, по сегодняшним реалиям.


S>Разрыв в стеке технологий — это то, что сам SQL спроектирован плохо. Он же был рассчитан на одноразовые интерактивные запросы. Там почти что нет возможностей по декомпозиции

Да, SQL был придуман ровно тогда, когда придумывали командные языки консоли, типа REXX или взять историю современного Bash.
SQL был таким же "консольным" языком изначально.
Делать же "взрослый" язык из "консольного" чуть позже... Ну ты понял.

Пусть даже TSQL имеет и ф-ии и типы данных, а PL/SQL местами даже прекрасен, но они имеют в базе какашку.


S>из-за чего на нём невозможно писать мало-мальски сложную логику.

Т.е. из-за одного и того же косяка большего кол-ва языков 4-го поколения, а именно — исторически SQL был разработан как язык для непрофессионалов в области реляционной алгебры или реляционных исчислений. Он должен был быть приближен к обычному английскому.

Поэтому, о формальной строгости языка речи быть не могло.
Этот язык — просто набор неких "фраз".

Вот и выходит, что де-факто SQL всё-равно пользуют лишь специалисты. Но плюются от тех косяков, которые были заложены из-за ориентации не на них. ))


S>Потому-то создатели ентерпрайз-приложений и сбежали из хранимок в яву — то есть от клиент-сервера к трёхзвенке. После ужасов тридцатистраничных хранимок даже ява с её бесконечными factory bean кажется глотком свежего воздуха.

Ага, понимаешь проблематику?
А как ты тогда умудрился привести обновляемость (наверно, имелась ввиду скорость и стоимость такого обновления?) как аргумент в пользу SQL?


Де-факто всё с точностью до наоборот.
Грубо можно посмотреть на 1C — насколько мала трудоёмкость внесения туда изменений и как оперативно можно делать такие изменения в сравнении с "традиционной" схемой, когда ты реализуешь логику в базе, на серваке и клиенте. ))

Здравствуйте, Sinclair, Вы писали:

V>>Есть языки и/или расширения к имеющимся (к С++, например), которые переводят второе в первое.
V>>То бишь, параллелят, если данные уже в памяти.
S>Ничего не получится. На всякий случай напомню, что речь — про lazy load, и невинная итерация по коллекции orders скрывает за собой возможный раундтрип до СУБД.

Сосредоточься. Я говорил о компиллируемом коде на стороне БД.


V>>Ну, начнём с того, что постановка вопроса "удобства" во главу угла является ошибкой, бо это не первопричина, а следствие. Это удобство сегодня требуется из-за тотального разрыва в стеке технологий в случае "обычного SQL" и является лишь способом адаптации разработчиков к такому разрыву.
S>Это как раз первопричина. Нужно понимать, что данные — это факты. Трактовка этих фактов (бизнес-правила) меняются по пять раз в квартал. А вот сами данные остаются теми же самыми. И разрыв в стеке технологий тут совершенно ни при чём.

Весёлый ты. ))
"Ребята, нужно понимать, что береза — это дерево. А листья сбрасываются раз в год. Поэтому, снегири тут не при чём."

Умудрился дважды сам себе противоречить в одной фразе.
"данные остаются теми же"
"меняется код"
"но разрыв технологий не при чём"
При том что именно разрыв технологий делает каждое изменение логики чудовищно дорогим.
Стоимость изменения пары строк в БД сегодня равна стоимости изменения десятков тыщ строк на "обычном ЯП".
Т.е. твой разрыв технологий, который "не при чём", делает развитие базы совершенно неприличным по стоимости и тормознутости занятием.
Развитие кода БД медленное, реакция на изменения бизнес-логики страшно не оперативная, фактически ступор, по сегодняшним реалиям.


S>Разрыв в стеке технологий — это то, что сам SQL спроектирован плохо. Он же был рассчитан на одноразовые интерактивные запросы. Там почти что нет возможностей по декомпозиции

Да, SQL был придуман ровно тогда, когда придумывали командные языки консоли, типа REXX или взять историю современного Bash.
SQL был таким же "консольным" языком изначально.
Делать же "взрослый" язык из "консольного" чуть позже... Ну ты понял.

Пусть даже TSQL имеет и ф-ии и типы данных, а PL/SQL местами даже прекрасен, но они имеют в базе какашку.


S>из-за чего на нём невозможно писать мало-мальски сложную логику.

Т.е. из-за одного и того же косяка большего кол-ва языков 4-го поколения, а именно — исторически SQL был разработан как язык для непрофессионалов в области реляционной алгебры или реляционных исчислений. Он должен был быть приближен к обычному английскому.

Поэтому, о формальной строгости языка речи быть не могло.
Этот язык — просто набор неких "фраз".

Вот и выходит, что де-факто SQL всё-равно пользуют лишь специалисты. Но плюются от тех косяков, которые были заложены из-за ориентации не на них. ))


S>Потому-то создатели ентерпрайз-приложений и сбежали из хранимок в яву — то есть от клиент-сервера к трёхзвенке. После ужасов тридцатистраничных хранимок даже ява с её бесконечными factory bean кажется глотком свежего воздуха.

Ага, понимаешь проблематику?
А как ты тогда умудрился привести обновляемость (наверно, имелась ввиду скорость и стоимость такого обновления?) как аргумент в пользу SQL?


Де-факто всё с точностью до наоборот.
Грубо можно посмотреть на 1C — насколько мала трудоёмкость внесения туда изменений и как оперативно можно делать такие изменения в сравнении с "традиционной" схемой, когда ты реализуешь логику в базе, на серваке (приложений) и клиенте. ))