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

C>>Чтобы не было "регэкспа" в БД.
S>А смысл?
Логика в одном месте, управляемая и версируемая в одной VCS, и т.д.

C>>Да. В обоих случаях "регэксп" будет обрабатывать ровно одинаковый объём.
S>Да, но этот объём обрабатывается в разных местах.
Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают.

S>Так-то можно и клиенту все данные на каждый чих отдавать — пусть ворочает локально.
Не совсем. У РСУБД есть индексы, которые позволяют ограничивать объём данных.

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

C>>Это не странная идея совершенно. Более того, по факту это сейчас то, что происходит в индустрии — она уходит от SQL и логики в БД в сторону использования БД как тупого хранилища, с которым легко работать из языков более высокого уровня.
S>Вы считаете, что это хорошо?
Да. SQL провалился как язык для работы с данными. Он само-ограничился областями, где не нужна высокая производительность и большие объёмы данных.

Здравствуйте, amironov79, Вы писали:
A>Мешают требования безопасности. Если разработчику бизнес-логики дать рефлекшен и кодогенерацию, то это как дать ему ключи от сервера. Или там рефлекшена нет, или на каждый чих надо выдавать права.
Ну, если честно, то это — надуманная проблема. У разработчика бизнес-логики и так есть доступ до более-менее всего. С учётом того, что он может инжектить в код произвольный SQL, который исполняется под правами "сервис-аккаунта", то что он такого не может сделать с базой, что мог бы при помощи кодогенерации?
A>Либо у вас там какое-то супер железо, либо данных кот наплакал.
Нет, простое, обычное современное железо. О том и речь, что обычные бизнес-задачи, которые зарабатывают единицы миллионов долларов в год, прекрасно отрабатывают за скромные времена.
Ну, то есть можно, конечно, и такие задачи сделать через подъём всего подряд в память апп сервера, а потом реализовать отложенное исполнение на MQ-решениях, чтобы на каждую строчку происходил новый запуск джава-машины, и тогда апгрейд будет сутки бегать. Зато ентерпрайз, зато кластеры, зато паттерны, зато все при деле.

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

C>Логика в одном месте, управляемая и версируемая в одной VCS, и т.д.
Этот вопрос ортогонален месту исполнения кода. Обеспечение согласованного развёртывания базы и апп-сервера — да, это серъёзный вопрос; но средства для его решения существуют.
Нет смысла пытаться избегать этого вопроса — всё равно вместе с эволюцией кода эволюционирует и схема; если ваши инструментальные средства могут просохатить изменение кода в "хранимке", то они с тем же успехом просохатят и изменение структуры таблиц.

C>Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают.
Ну, может быть, вы и правы. Но что-то меня берут обоснованные сомнения. Не верю я в то, что блочный доступ через сеть используется в построении реальных промышленных СУБД-решений.

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

C>По-хорошему, API БД должен представлять из себя что-то типа ленивых списков, которые можно пересекать или ограничивать по построенным индексам.
Отож. Вопрос только в том, что мы считаем "встроенным индексом", и что он должен уметь в рамках "пересечения или ограничения".
C>Да. SQL провалился как язык для работы с данными. Он само-ограничился областями, где не нужна высокая производительность и большие объёмы данных.
Ну, вам виднее.

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

S>Ну, если честно, то это — надуманная проблема. У разработчика бизнес-логики и так есть доступ до более-менее всего. С учётом того, что он может инжектить в код произвольный SQL, который исполняется под правами "сервис-аккаунта", то что он такого не может сделать с базой, что мог бы при помощи кодогенерации?

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

dbms_java.grant_permission('APPUSER', 'java.lang.RuntimePermission', 'getClassLoader', '');
dbms_java.grant_permission('APPUSER', 'java.io.FilePermission', '/tmp', 'read');
dbms_java.grant_permission('APPUSER', 'java.net.SocketPermission', 'sql-server:1433', 'connect,resolve');

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

A>>И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки?
S>Минимальное время, которое нужно, чтобы сделать select 1 из MS SQL — 10ms. Сколько бар-кодов можно сгенерировать за 10мс?

Чисто для корректировки: У меня получалось от менее 1 мс, до 5 мс. В среднем 3.

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

C>>Логика в одном месте, управляемая и версируемая в одной VCS, и т.д.
S>Этот вопрос ортогонален месту исполнения кода. Обеспечение согласованного развёртывания базы и апп-сервера — да, это серъёзный вопрос; но средства для его решения существуют.
И все они кривые.

S>Нет смысла пытаться избегать этого вопроса — всё равно вместе с эволюцией кода эволюционирует и схема; если ваши инструментальные средства могут просохатить изменение кода в "хранимке", то они с тем же успехом просохатят и изменение структуры таблиц.
В некоторой степени, да.

C>>Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают.
S>Ну, может быть, вы и правы. Но что-то меня берут обоснованные сомнения. Не верю я в то, что блочный доступ через сеть используется в построении реальных промышленных СУБД-решений.
Я уже давно не видел решений, которые НЕ используют. Даже простейший EC2 и тот использует EBS, который работает через сеть.

C>>Не совсем. У РСУБД есть индексы, которые позволяют ограничивать объём данных.
S>Ну так индексы-то тоже в каком-то смысле "логика". Просто к ней вы привыкли, и надёжность индексов такова, что никто в здравом уме не рассматривает сценарий "а что, если СУБД забудет проапдейтить индекс".
Индексы — это как-бы фундаментальная фича РСУБД. Без них они были бы бесполезны совсем.

C>>По-хорошему, API БД должен представлять из себя что-то типа ленивых списков, которые можно пересекать или ограничивать по построенным индексам.
S>Отож. Вопрос только в том, что мы считаем "встроенным индексом", и что он должен уметь в рамках "пересечения или ограничения".
Только ограничения в рамках индексированных данных (+главный ключ).

Я понимаю, что в теории РСУБД должны уметь оптимизировать запросы, вычисляя идеальный порядок join'ов, но на практике для больших OLTP-систем это просто не применимо. Всё что требует сложных join'ов будет работать слишком медленно.

Построение оффлайновых отчётов и анализ данных — это вообще отдельный разговор. Там вообще ничего нормального пока не придумали, что с SQL, что без.

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

A>Может выйти за пределы сервера базы в систему: работать с файлами, запускать процессы с правами системного пользователя, под которым работает субд.
Совершенно не факт, что СУБД работает под какими-то более широкими правами, чем тот же самый апп-сервер.

Думаю, там есть система прав доступа, которую надо настраивать. В том же oracle для работы с java надо гонять приложение и смотреть, какие права требуются, вплоть до разрешения подключиться к любому удаленному узлу:
A>

A>dbms_java.grant_permission('APPUSER', 'java.lang.RuntimePermission', 'getClassLoader', '');
A>dbms_java.grant_permission('APPUSER', 'java.io.FilePermission', '/tmp', 'read');
A>dbms_java.grant_permission('APPUSER', 'java.net.SocketPermission', 'sql-server:1433', 'connect,resolve');
A>

Ну да, конечно же там работает песочница — как и везде. Но ещё раз: что такого ценного вы видите на сервере СУБД, что более ценно, чем сама база данных?
Там самый главный файл — это собственно БД, только она денег и стоит. Человек, который может задеплоить произвольный код в сервер приложений, прекрасно дампнет вашу базу конкурентам безо всякой кодогенерации.

Основной риск — это code injection, когда злоумышленником выступает не программист, а внешний пользователь. Ну так опять же — drop table customers он вам заинжектит и через обычный DML, даже если прав на динамическое развёртывание кода у него нету.

Ну и опять же — тот же самый .jsp весь построен на том, что есть контейнер, который автоматически порождает .java по .jsp-разметке и компилирует её на лету. То есть у апп-сервера хватает прав на динамическое порождение кода; но это никого не пугает — ведь все пути порождения такого кода аккуратно закрыты: права "быренько создать bypasssecuritycheck.jsp" у самого jsp нету, поэтому обычной механики проверки прав на развёртывание вполне хватает.
Так и развёртывание встроенного в СУБД кода можно вынести из прикладного кода — когда .jsp означает не "java server page", а "java stored procedure", и вся эта ботва компилируется и развёртывается в БД контейнером, который полностью аналогичен резине или томкэту.

Основное препятствие тут — "это ещё не сделано"

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

S>Чисто для корректировки: У меня получалось от менее 1 мс, до 5 мс. В среднем 3.
Стесняюсь спросить — это на соседней машине, или в пределах одной машины?
Сам давно уже не сидел с секундомером.

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

S>>Чисто для корректировки: У меня получалось от менее 1 мс, до 5 мс. В среднем 3.
S>Стесняюсь спросить — это на соседней машине, или в пределах одной машины?
S>Сам давно уже не сидел с секундомером.

Разные сервера в одном здании.
Что интересно, я запускал тест на двух системах по разному подключённых к SQL-серверу (напрямую по 25Gbit ethernet, и по 1Gbit ethernet через роутер) — результаты +/- одинаковые. То есть сеть не сильно влияет на производительность таких запросов.

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

A>>Может выйти за пределы сервера базы в систему: работать с файлами, запускать процессы с правами системного пользователя, под которым работает субд.
S>Совершенно не факт, что СУБД работает под какими-то более широкими правами, чем тот же самый апп-сервер.

Здесь опять-таки вопрос разграниечения доступа. Под каким системным пользователем работает процесс, в котром иполняется процедура? Наверняка под каким-то пользователем, который имеет расширенные права с возможностью чтения всех data-файлов. В сервере же приложений разные модули могут работать под разными пользователями и даже на разных машинах.

S>Ну да, конечно же там работает песочница — как и везде. Но ещё раз: что такого ценного вы видите на сервере СУБД, что более ценно, чем сама база данных?
S>Там самый главный файл — это собственно БД, только она денег и стоит. Человек, который может задеплоить произвольный код в сервер приложений, прекрасно дампнет вашу базу конкурентам безо всякой кодогенерации.

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

S>Основной риск — это code injection, когда злоумышленником выступает не программист, а внешний пользователь. Ну так опять же — drop table customers он вам заинжектит и через обычный DML, даже если прав на динамическое развёртывание кода у него нету.

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

Вот, например, просит приложение выдать ему:

dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');

И как админу на это реагировать?

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

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

_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?


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

А правильно — это переделывать одну модель на две модели: read & write. Что бы бизнес правила использовали read model.
Но это сложно сделать, потому что встают вопросы согласования моделей. А архитектура приложения под это не заточено.

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

C>>Это уже не так критично как раньше. Особенно учитывая, что диски нынче тоже через сеть работают.
S>Ну, может быть, вы и правы. Но что-то меня берут обоснованные сомнения. Не верю я в то, что блочный доступ через сеть используется в построении реальных промышленных СУБД-решений.

Вам выше пытаются вдуть в уши. Разумеется, диски работают через сеть, только сеть та — Fibre Channel или нечто подобное.

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

A>Здесь опять-таки вопрос разграниечения доступа. Под каким системным пользователем работает процесс, в котром иполняется процедура? Наверняка под каким-то пользователем, который имеет расширенные права с возможностью чтения всех data-файлов. В сервере же приложений разные модули могут работать под разными пользователями и даже на разных машинах.

И у java и у clr есть security context, который может запретить коду делать вообще всё, кроме вычислений. Далее, хранимка может исполняться под указанным пользователем БД.

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

A>Вот, например, просит приложение выдать ему:
A>

A>dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');
A>

A>И как админу на это реагировать?

Знаете, у вас тут есть два малосочетаемых утверждения. Первое — что в конторе глупые или отупевшие от избытка работы админы, а второе — что по соседству с этими админами сидят чрезвычайно хитроумные программисты, которые пролезут через песочницу. Ситуация из каждого из этих утверждений может существовать в реальности, но не в одной конторе точно. Или — или. Это ведь не тред "как с помощью хранимок защититься от промышленного шпионажа".

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

С>И у java и у clr есть security context, который может запретить коду делать вообще всё, кроме вычислений. Далее, хранимка может исполняться под указанным пользователем БД.

Ну и? Я ниже тоже самое и написал. Вы сможете это все настроить, и предвидеть последствия того или иного разрешения?

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

A>>Вот, например, просит приложение выдать ему:
A>>

A>>dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');
A>>

A>>И как админу на это реагировать?

С>Знаете, у вас тут есть два малосочетаемых утверждения. Первое — что в конторе глупые или отупевшие от избытка работы админы, а второе — что по соседству с этими админами сидят чрезвычайно хитроумные программисты, которые пролезут через песочницу. Ситуация из каждого из этих утверждений может существовать в реальности, но не в одной конторе точно. Или — или. Это ведь не тред "как с помощью хранимок защититься от промышленного шпионажа".

Вопрос так не стоит. Вопрос следующий: как не открыть дыру с помощью хранимок?

Где я писал, что админы тупые? Наоборот, хороший админ сторонней организации пошлет вас лесом с подобными запросами. У него на сервере несколько баз, а тут вы такой красивый являетесь и говорите -- дай прав. Вы сможете его только административным ресурсом продавить. И зачем все это, если все тоже самое можно получить в приложении? Без всяких головоломок: собрали контейнер, установили, настроили, запустили. От базы только строка подключения нужна.

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

_>А правильно — это переделывать одну модель на две модели: read & write. Что бы бизнес правила использовали read model.
_>Но это сложно сделать, потому что встают вопросы согласования моделей. А архитектура приложения под это не заточено.

То есть писать код в базе изначально -- это неправильно? Так про это и топик.

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

С>>И у java и у clr есть security context, который может запретить коду делать вообще всё, кроме вычислений. Далее, хранимка может исполняться под указанным пользователем БД.

A>Ну и? Я ниже тоже самое и написал. Вы сможете это все настроить, и предвидеть последствия того или иного разрешения?

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

A>Где я писал, что админы тупые? Наоборот, хороший админ сторонней организации пошлет вас лесом с подобными запросами. У него на сервере несколько баз, а тут вы такой красивый являетесь и говорите -- дай прав. Вы сможете его только административным ресурсом продавить.

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

A>И зачем все это, если все тоже самое можно получить в приложении? Без всяких головоломок: собрали контейнер, установили, настроили, запустили. От базы только строка подключения нужна.

У меня вот есть встречный вопрос (той же степени осмысленности) — зачем писать на C# или Java, когда есть Хаскель?

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

С>Да, смогу. Другое дело, что я принципиально небыстро работаю. Безопасность в режиме "наговнякать ко вчера" не делается.

А надо это сделать здесь и сейчас, чтобы приложение заработало. Потому как библиотеки, которые нормально работают в standalone режиме, начинают просить дикие разрешения, когда их загружают в базу. Сиди, читай, думай, дыра это разрешение или не дыра? Зачем это всё, когда в отдельном приложении такой проблемы просто нет?

A>>Где я писал, что админы тупые? Наоборот, хороший админ сторонней организации пошлет вас лесом с подобными запросами. У него на сервере несколько баз, а тут вы такой красивый являетесь и говорите -- дай прав. Вы сможете его только административным ресурсом продавить.

С>И хорошо бы продавить. А то получится, как в российском бизнеса "бухгалтерия не пускает". Да идут они нахер, организация работает не для бухгалтерии.

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

A>>И зачем все это, если все тоже самое можно получить в приложении? Без всяких головоломок: собрали контейнер, установили, настроили, запустили. От базы только строка подключения нужна.

С>У меня вот есть встречный вопрос (той же степени осмысленности) — зачем писать на C# или Java, когда есть Хаскель?

Если хотите, пишите на хаскеле. Если откинуть вопрос "зачем", то на сервере приложений это можно без проблем устроить, будет еще один сервис в отдельном контейнере.

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

A>Причем здесь бухгалтерия? Админ отвечает за безопасность сервера, это его зона ответственности. С чего он должен пускать на сервер субд "какого-то хера с горы" со всякими извратными требованиями?

При том, что главный бухгалтер может и сесть, а вот сидящих админов я ещё не видел, хотя сажать их не мешало бы, вместе с техлидами, ПМ'ами и прочими. Чтобы не слишком быстро бежали по пути прогресса.

Пусть на тестовом сервере это и отлаживает. На staging'е. Как это — нет staging? На внедорожник у директора деньги есть, а на staging — нету?

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

A>>Причем здесь бухгалтерия? Админ отвечает за безопасность сервера, это его зона ответственности. С чего он должен пускать на сервер субд "какого-то хера с горы" со всякими извратными требованиями?

С>При том, что главный бухгалтер может и сесть, а вот сидящих админов я ещё не видел, хотя сажать их не мешало бы, вместе с техлидами, ПМ'ами и прочими. Чтобы не слишком быстро бежали по пути прогресса.

Нифига себе, до чего код в базе людей доводит. Теперь буду с опаской "PLSQL Developer" запускать...

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

A>Баз может быть несколько, и не ко всем базам из субд будет доступ, и при правильном подходе бизнес-программист в базе далеко не админ.
То же самое работает и для управляемого кода, исполняемого из-под СУБД.

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

A>Вот, например, просит приложение выдать ему:
A>

A>dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');
A>

A>И как админу на это реагировать?
Да как обычно — есть же инструкции по развёртыванию. Просит — почему не дать? Оно же для чего-то нужно.