Если роли нет, то увидеть полные данные невозможно. Если проверять в policy не роль, а CURRENT_USER и user создавший процедуру (с Definer Rights) имеет полный доступ, то и процедура будет иметь полный доступ.
Скорее всего данные маскируются при выборке результата из курсора, врядли oracle решился сломать внутренние механизмы. Это скорее для клонок не участвующих в групповых операциях.
SQL> select count(*), email from test.client_info group by email;
COUNT(*) EMAIL
---------- ---------------
1 ivan@xxxxx.com
1 ivan@xxxxx.com
они будут участвовать во всех операциях как закрытые или открытые в зависимости от наличия роли. Но это никак не влияет на колонки не упомянутые в policy.
Тут уже тонкое различие в терминологии, я подразумевал «нормальный проект», в котором кол-во костылей все таки не зашкаливает. Цена сложности — это скорее цена не текущих мелких костылей, а все таки необоснованных проектных решений. Например притащить библиотеку с собственным менеджментом памяти ради функции подсчета факториала.
Технический долг это не совсем «цена сложности». Технический долг постояно накапливается в развивающемся проекте. Это незакрытые TODO, сделанные наспех костыли и т.д. Единственный способ уменьшить долг — тратить некоторое время на упрощение и чистку кода. Но тут, как и везде нужна мера :)
Основоной посыл статьи не в абсолютных цифрах :). Сортировка требует времени. В вашем случае это время больше, чем выгода от перестановки предикатов. Почему это так — для ответа на этот вопрос нужно смотреть листинги работы JIT, как это сделать.
В этой программе (на примитивном уровне) показывается работа SQL оптимизатора. Предикаты сортируются по селективности — чем меньше мы записей выберем с участием этого предиката, тем раньше мы должны его применить.
Если в app.java поправить
//27 строка
if(random.nextBoolean()) { finder = finder.withAmount(0, 0); }
на
if(random.nextBoolean()) { finder = finder.withAmount(0, 1000000); }
и
//35 строка
if(random.nextBoolean()) { finder = finder.withCode(rr, rr + 5); }
на
if(random.nextBoolean() || true) { finder = finder.withCode(rr, rr + 5); }
мы ухудшим возможность отсечения ненужных строк по amount. Без сортировки предикатов amount так и останется первым и ухудшит общее время выполнения, а с сортировкой уйдет на вторую позицию.
Помимо этого, даже, существуют статьи показывающие преимущества в скорости языков с компиляцией налету (JIT — Just-in-time compilation), таких как Java и C#. Сравнить последние мы оставим тем, кто считает их быстрыми, но мы объясним почему это не так
Небольшой пример, использующий динамическую генерацию кода и JIT: Ищем на java, оптимизация во время исполнения. За счет генераци «плана исполнения запроса» на лету и JIT, скорость получилась сравнимая со статической оптимизацией.
Но это затруднительно, и для пресечения таких попыток можно использовать аудит.
«Не следует привлекать новые сущности без крайней на то необходимости»
Еще немного и С++ будет похож на смесь Brainfuck и PL/I
Если в app.java поправить
мы ухудшим возможность отсечения ненужных строк по amount. Без сортировки предикатов amount так и останется первым и ухудшит общее время выполнения, а с сортировкой уйдет на вторую позицию.