I dont knowИнтересует, как по фен-шую
Это большой вопрос. В последнее время в моде application roles, но в любом случае ответ начинается с вопроса "какое приложение мы строим и как оно должно работать".

I dont knowВ чём принципиальные отличия этих подходов,
В безопасности.

I dont knowкаковы плюсы и минусы их использования?
Плюс первого подхода: интересно и круто. Ощущаешь себя творцом, настоящим программистом и вообще занят настоящим делом, о котором будешь рассказывать, пыжась от гордости.

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

I dont knowС какими проблемами можно столкнуться?
Да в общем смотря как делать. Программист - зверёк такой, он проблему где угодно сумеет организовать.

I dont knowразве это не безопасно?
Однажды, давным-давно, у меня была халтура - вытащить данные из базы некоего приложения. Данные лежали в файлах, файлы были зашифрованы. Я полез разбираться, как работает приложение. На нём висела офигенно запутанная защита, которая эти файлы на лету расшифровывала при считывании и зашифровывала при записи. Я понял, что разбираться в логике этого шифрования и писать дешифровщик - занятие на много недель.

В итоге я справился чуть меньше, чем за час. Я просто написал небольшое приложение, которое было предназначено управлять взламываемым. Оно запускало его, давало ему инициализироваться, взять ключи, настроить шифрование итп, после чего перехватывало управление и поступало максимально просто - в цикле считывала файлы данных через приложение (расшифровывавшее их), после чего записывало полученный блок мимо приложения (минуя обратную шифровку). И через 50 минут после начала работы у меня были в открытом виде нужные данные.

К чему я рассказываю эту историю... только идиот будет прямиком ломиться в защиту, нормальный человек будет искать слабость. Надёжность системы определяется надёжностью слабейшего звена. "Длинющий пароль и какой-нибудь хэш" в лучшем случае обеспечат отсутствие дырки в этом месте, но мало скажутся на общей безопасности - для которой нужно отсутствие дырок в каждом из 100500 звеньев.