Все верно, данная проблема решается, к сожалению, только переопределением контроллера. Решение родными средствами фреймворка мне тоже найти не удалось.
@Fesor видимо вы не сталкивались с подобными ситуациями. Например, эксплоит-диллеры используют подобные технологии, для того, чтобы позволить покупателю эксплуатировать какую-то уязвимость, и при этом не раскрыть сути самой уязвимости. Если бы у них "не хватило тупости" как вы говорите, то первый же покупатель мог бы выложить этот эксплоит сразу же после покупки за пол цены, или владелец уязвимой системы купит против себя сплоит, задетектить уязвимость и закрыть ее.
@Fesor вы рассматриваете ситуацию, когда может быть защищен проект написанные например на symfony? Вы же понимаете, что закодировано будет все, и скорее всего большую часть в таком случае кода будет составлять совсем не проект? И zend guard - это не только и не столько обфускация.
@KOLANICH найти возможно, вопрос - каких сил и времени это будет стоить исследователю. Так то и байт-код можно зареверсить. Понятное дело, что трудозатраты различны, однако это все равно не plain source.
Люди платят за продукт, а не за качество. И php-проекты (таковые существуют) можно также однонаправленно "скомпилировать" подобно бинарникам c++, которые "все равно сломать" не получится, читать as is как js min-файлы. И Zend Guard тому решение.
@cac95 Можно средствами БД - наложить групповой уникальный ключ на пару (артист, группа). Можно средствами cgi (php или что там у вас), перед вставкой сделать выборку по одному из полей - артиста или группы, в зависимости от контекста. Я бы предпочел отдать это на растерзание базе и выбрал бы первый путь.
@cac95 В два запроса. Первый - вставка артиста, второй - вставка отношений "артист-группа". Либо можно попробовать через JOIN вставить, но я точно не помню, работает ли эта фишка.
@cac95 Если так, то по идеи все должно быть в порядке. У вас не однородные данные, поэтому запросы раздельные. Запросы по ключу (pk) не сильно занимают базу, поэтому все ок.