История изменений
Исправление foror, (текущая версия) :
ты, кстати, уже придумал как запретить простой select для чужих данных?
https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html
бд на хранимках --- это жесткая привязка к языку
Все моё приложение пишется на Java, никто же не бухтит, что Линух привязан к Си? Хочешь изменять приложение, изучай язык на котором оно создано.
Или если бизнес логику выбросить из БД от этого будет легче понять взаимосвязи между таблицами? Без знания бизнес логики, которая всегда пишется на определенном языке? Так можно тогда сделать проще, в постгресе например можно отключить все тригеры/констрейнты и даже внешние ключи и работать c БД как со sqlite.
плохо контролируемый мрак
Где там мрак? Наоборот хрен разрушишь консистентность если залезешь кривыми ручками. Но в прочем да, с тем подходом когда хранимки лежат отдельно от приложения - это мрак. Но у меня приложение прозрачно пересекается с хранимками.
как минимум средств разработки нормальных нет
Еще раз повторяю у меня приложение прозрачно пересекается с хранимками, выше приводил пример. В eclipse для кода хранимок работает автодополнение, рефакторинг, дебаг и все остальное, что работает для обычного Java кода приложения. Запускается PL/Java на той же JVM, что и приложение.
В Java коде все статичные методы помеченные как @Function/@Trigger/@MappedUDT автоматически преобразуются в код PL/Java. Преобразования композитных типов делается также автоматически через java.sql.SQLData интерфейс. Я ничего не пишу руками - PL/Java код генерируется автоматически. Мне в итоге нужно просто выполнить функцию:
SELECT sqlj.install_jar(
'file:'
'/buildroot/pljava-examples/target/pljava-code-1.5.0.jar',
'examples', true);
Исправление foror, :
ты, кстати, уже придумал как запретить простой select для чужих данных?
https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html
бд на хранимках --- это жесткая привязка к языку
Все моё приложение пишется на Java, никто же не бухтит, что Линух привязан к Си? Хочешь изменять приложение, изучай язык на котором оно создано.
Или если бизнес логику выбросить из БД от этого будет легче понять взаимосвязи между таблицами? Без знания бизнес логики, которая всегда пишется на определенном языке? Так можно тогда сделать проще, в постгресе например можно отключить все тригеры/констрейнты и даже внешние ключи и работать c БД как со sqlite.
плохо контролируемый мрак
Где там мрак? Наоборот хрен разрушишь консистентность если залезешь кривыми ручками. Но в прочем да, с тем подходом когда хранимки лежат отдельно от приложения - это мрак. Но у меня приложение прозрачно пересекается с хранимками.
как минимум средств разработки нормальных нет
Еще раз повторяю у меня приложение прозрачно пересекается с хранимками, выше приводил пример. В eclipse для кода хранимок работает автодополнение, рефакторинг, дебаг и все остальное, что работает для обычного Java кода приложения.
В Java коде все статичные методы помеченные как @Function/@Trigger/@MappedUDT автоматически преобразуются в код PL/Java. Преобразования композитных типов делается также автоматически через java.sql.SQLData интерфейс. Я ничего не пишу руками - PL/Java код генерируется автоматически. Мне в итоге нужно просто выполнить функцию:
SELECT sqlj.install_jar(
'file:'
'/buildroot/pljava-examples/target/pljava-code-1.5.0.jar',
'examples', true);
Исходная версия foror, :
ты, кстати, уже придумал как запретить простой select для чужих данных?
https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html
бд на хранимках --- это жесткая привязка к языку
Все моё приложение пишется на Java, никто же не бухтит, что Линух привязан к Си? Хочешь изменять приложение, изучай язык на котором оно создано.
Или если бизнес логику выбросить из БД от этого будет легче понять работу приложения без знания языка на котором оно написано? Так можно тогда сделать проще, в постгресе например можно отключить все тригеры/констрейнты и даже внешние ключи и работать c БД как со sqlite.
плохо контролируемый мрак
Где там мрак? Наоборот хрен разрушишь консистентность если залезешь кривыми ручками. Но в прочем да, с тем подходом когда хранимки лежат отдельно от приложения - это мрак. Но у меня приложение прозрачно пересекается с хранимками.
как минимум средств разработки нормальных нет
Еще раз повторяю у меня приложение прозрачно пересекается с хранимками, выше приводил пример. В eclipse для кода хранимок работает автодополнение, рефакторинг, дебаг и все остальное, что работает для обычного Java кода приложения.
В Java коде все статичные методы помеченные как @Function/@Trigger/@MappedUDT автоматически преобразуются в код PL/Java. Преобразования композитных типов делается также автоматически через java.sql.SQLData интерфейс. Я ничего не пишу руками - PL/Java код генерируется автоматически. Мне в итоге нужно просто выполнить функцию:
SELECT sqlj.install_jar(
'file:'
'/buildroot/pljava-examples/target/pljava-code-1.5.0.jar',
'examples', true);