Comments 36
Интересный способ. А не проще ли после пересоздания процедуры заново выдать гранты? Тут надо только позаботиться чтобы никто не был забыт.
Проще, конечно, но тут два момента:
1. Есть ли гарантии, что мы не забудем раздатьвсем сестрам по серьгам всем нужным юзерам?
2. Критично ли, что какое-то время данная процедура будет недоступна части посетителей сайта?
1. Есть ли гарантии, что мы не забудем раздать
2. Критично ли, что какое-то время данная процедура будет недоступна части посетителей сайта?
Кстати, не желаете перенести статьяю в блог mysql?
postgresql наше всьо
В постгресе тоже не всё хорошо.
Особенно, в части работы с перлом.
Особенно, в части работы с перлом.
Поработайте с ораклом из перла :)
может, у вас другие задачи и другие данные, но мне с постгресом намного удобнее работать, чем с mysql хотя бы даже из perl.
чтобы не быть голословным — простите, но что мешало разработчикам mysql написать нормальный парсер sql, который бы не требовал чудовищных
delimiter $$$
без которых очень сложно представить себе триггеры и хранимые процедуры.
или, допустим кодировку клиента. почему–то нельзя было сделать это менее мудацким образом, чем set names или DBI:mysql:database=db;mysql_read_default_group=perl;mysql_read_default_file={$root}/etc/my.cnf
а давайте еще посмотрим на то, что происходит с dbh после возникновения ошибки в mysql…
не буду холиварить, но как–то немного необъективно
чтобы не быть голословным — простите, но что мешало разработчикам mysql написать нормальный парсер sql, который бы не требовал чудовищных
delimiter $$$
без которых очень сложно представить себе триггеры и хранимые процедуры.
или, допустим кодировку клиента. почему–то нельзя было сделать это менее мудацким образом, чем set names или DBI:mysql:database=db;mysql_read_default_group=perl;mysql_read_default_file={$root}/etc/my.cnf
а давайте еще посмотрим на то, что происходит с dbh после возникновения ошибки в mysql…
не буду холиварить, но как–то немного необъективно
А что вам не нравится в perl+pgsql?
UFO just landed and posted this here
я стараюсь не использовать хранимые процедуры вабще. Возможно просто я не сталкивался с проблемой, где они бы стали решением.
Не хочу холивара, но все же, почему не попробовать перейти на PGSQL? Меня долго заставляли, но после переезда, я теперь проекты на MySQL больше не пишу. Я понимаю, конечно, если проект существует несколько лет и сложно перевести его на другую СУБД, но ведь «Все в трауре, миллионные потери, разработчики проекта уволены, занавес.» — не пара ли?
CREATE OR REPLACE… вам в помощь.
Хотя есть свои нюансы, конечно.
CREATE OR REPLACE… вам в помощь.
Хотя есть свои нюансы, конечно.
Для грамотных — пардон, «пара» — ошибка, «но после переезда, я теперь» — здесь запятая не нужна. Нетрезв, дико извиняюсь.
Не переживайте за нас, никого не уволили.
Эти подробности исключительно художественный вымысел ;)
А базы самые разные, как и задачи.
Плюсы и минусы есть в каждой СУБД, какую не выбери.
Эти подробности исключительно художественный вымысел ;)
А базы самые разные, как и задачи.
Плюсы и минусы есть в каждой СУБД, какую не выбери.
Странные люди. Топик про то, как в MySQL сделать то-то и то-то. Набегает толпа народа с воплями «А Postgres лучше!», «А IBM DB/2 наше всё!». Кого ебёт ваше всё? Имеем топик про MySQL — спасибо, интересно, прочла. Мнение тех, кто пишет на Paradox как-то не в кассу, собственно.
Резюме: два хака для поддержки тривиальной функциональности. Знаете, что и в каких выражениях скажет о Вас человек, который будет поддерживать всё это через пол года? :)
Может стоит поискать другие подходы к решению этой проблемы? А ещё лучше — что-то изменить в рабочем процессе, чтобы эта проблема даже не возникала.
Я не работал со stored procedures и не особо заморачивался правами юзеров, так что могу сильно промахнуться, но вот несколько вариантов навскидку:
В общем, подробности реализации могут быть самые разные, это уж Вам виднее, как лучше это сделать. Но любой другой вариант будет лучше этих хаков, IMHO.
Может стоит поискать другие подходы к решению этой проблемы? А ещё лучше — что-то изменить в рабочем процессе, чтобы эта проблема даже не возникала.
Я не работал со stored procedures и не особо заморачивался правами юзеров, так что могу сильно промахнуться, но вот несколько вариантов навскидку:
- — вместо выставления прав доступа к процедурам выставить их на таблицы/колонки в базе (ведь на самом деле именно данные а не код требуется защищать)
- — подумать, может вообще не стоит разделять права пользователей A и B, а вместо этого ввести некую роль (аккаунт R), которым будут пользоваться оба пользователя
- — если уж использовать эти хаки, то хотя бы автоматизировать их применение — повесить какой-нить триггер который при создании юзером A процедуры X' будет автоматически копировать её код поверх кода процедуры X (вызываемую юзером B) в таблице proc и делать ALTER
- — сделать две процедуры — X и X', при этом процедура X' будет реальным кодом, а X обёрткой вокруг неё (если stored procedures умеют вызывать друг друга :)); тогда юзер A будет менять (через DROP/CREATE) процедуру X', а юзер B запускать не меняющуюсь процедуру X
В общем, подробности реализации могут быть самые разные, это уж Вам виднее, как лучше это сделать. Но любой другой вариант будет лучше этих хаков, IMHO.
Знаете, что и в каких выражениях скажет о Вас человек, который будет поддерживать всё это через пол года?
А знаете, что скажет ему менеджер, когда программист потеряет гранты на какие-то процедуры, используемые в 24x7 проекте?
Может стоит поискать другие подходы к решению этой проблемы?
Буду только рад, если кто-то мне подскажет эти подходы. Серьёзно.
К сожалению, изучение документации особо не помогло.
А ещё лучше — что-то изменить в рабочем процессе, чтобы эта проблема даже не возникала.Если требование рабочего процесса — использование хранимых процедур, как прикажете его изменить?
Я не работал со stored procedures и не особо заморачивался правами юзеров
Пастернака не читал, но осуждаю. ©
Дальше могли бы не продолжать в таком случае.
вместо выставления прав доступа к процедурам выставить их на таблицы/колонки
Мускул не позволяет устанавливать права на колонки. Выставление прав на таблицы ничего не даст, поскольку всё равно должен быть юзер, как-то их модифицирующий. Написание процедуры, инкапсулирование в ней работы с нужными таблицами и колонками значительно снижает возможности по случайной или намеренной модификации данных.
подумать, может вообще не стоит разделять права пользователей A и B, а вместо этого ввести некую роль (аккаунт R), которым будут пользоваться оба пользователя
Какая разница? Имеем то же самое.
если уж использовать эти хаки, то хотя бы автоматизировать их применение
А кто сказал, что автоматизация не используется?
Автоматизация описанного не относилась к теме данной статьи.
сделать две процедуры
Подход имеет право на существование, но
1. вдвое увеличит количество функций проекта.
2. при первой же необходимости изменить набор параметров процедуры или их типы приведет к описанной в статье проблеме.
В общем, как я писал выше — могли бы не продолжать, если не занимались предметной областью.
подробности реализации могут быть самые разные
Пока я не услышал ни одного конструктивного предложения, кроме банального — автоматизации описанного мной процесса.
Но любой другой вариант будет лучше этих хаков
К сожалению, пока я не знаю ни одного нормального варианта в рамках MySQL, который бы помогал избежать хака. Был бы — я бы только радовался, поскольку не пришлось бы изобретать эти хаки.
Описанный хак — он от бессилия перед немощью Мускула.
Sign up to leave a comment.
Хранимые процедуры в MySQL