почему же, могу. как раз к моей профессиональной деятельности относится. но на все твои вопросы знает ответ гугл, поэтому могу тебе только ликбез устроить в двух словах.
во-первых, защищенность данных зависит от субд. если она дырявая, то никакой sql тебе не поможет.
назови конкретную систему, или делай обзор по всем, начиная от berkley db заканчивая oracle и sybase.
поэтому пункт первый — обзор секьюрити репортов. они есть на соответствующих сайтах. защищаемся ежедневной проверкой обновлений и сразу же их устанавливаем.
тут главное правило — никакого виндовса.
во-вторых данные можно защищать от несанкционированного доступа, а можно защищать их целостность.
идешь бесплатно читаешь стандарт:
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txtв первом случае — механизмы авторизации и аутентификации. логины, пароли, ip-адреса, per-db access, per-table accces, per-column access. стандарт предусматривает всякие grant-revoke, в конкретной системе могут быть свои дополнительные механизмы.
во втором — механизмы поддержки целостности на уровне субд. первичные, композитные, внешние ключи, триггеры, хранимые процедуры и все такое. в стандарте это различные contraints.
тут если копать глубже — упираешься в проектирование бд и теорию реляционных бд. в неправильно спроектированной базе не может быть целостности данных. а если база еще и объектная — то упираемся в фрейворк и разработку корпоративных приложений со всей вытекающей архитектурой, чтобы обеспечить целостность и безоспасноть на уровне приложения.
и всё же?
