К чему преимущества состоят в том, чтобы каждый приблизиться для отображения конечных пользователей приложения пользователям базы данных?
Если у вас есть сценарий типа IF ... THEN ... ELSE, я думаю, что правильным направлением было бы использование оператора CASE, например:
SELECT CASE WHEN CalculationMethod = x AND ((Price * coefficient) < Amount) THEN Amount
ELSE (Price * coefficient) END CalculatedAmount
Вы можете прочитать об этом здесь: https://docs.microsoft.com/en-us/sql/t-sql/language-elements/case-transact-sql?view=sql-server-2017
An Предложение IIF работает очень хорошо, когда существует только одна ветвь принятия решений, но если вам нужно выбрать несколько вещей из оператора CASE, это путь.
9 ответов
В дополнение к более простому администрированию существуют преимущества производительности опции 3 на веб-серверах; это позволяет объединять соединений - т.е. небольшое число физических соединений с базой данных может быть снова использовано непрерывно для обслуживания большого количества пользователей приложения. Это известно как "доверяемая подсистема" модель - т.е. Ваш сервер приложений проверяет внешних вызывающих абонентов, но затем сам сервер приложений используется в качестве идентификационных данных для вызова вниз. Самая большая проблема здесь - то, что для аудита и т.д. необходимо продолжать говорить дб, кто внес текущее изменение (вещи как USER_NAME(), SUSER_SNAME() прекратите быть полезными) - и конечно, это относительно легко имитировать.
Если бы веб-сервер использовал безопасность на пользователя, то это не было бы возможно - и таким образом, необходимо было бы по существу отключить организацию пула подключений. Действие установления соединения является (относительно) дорогим, таким образом, это оказало бы значительное влияние на производительность. Вы не хотели бы иметь в наличии соединение (в расчете на пользователя) между запросами, когда это приведет к огромному пулу и большому количеству открытых соединений (также дорогой).
"На роль" сайт опции между ними - но редко, чтобы роли были действительно взаимоисключающими, который делает это трудно для реализации.
С клиентскими приложениями, которые говорят непосредственно с базой данных, опция 1 является самой простой поддержать, так как Вы не должны распределять специальные банковские реквизиты клиенту. Объединение аналогично не является проблемой, так как машина клиента только действует как 1 пользователь.
Некоторые причины, почему N к 1 отображению так широко используется, могли быть возможно из-за,
В стандартной разработке программного обеспечения базу данных рассматривают как простой репозиторий а не вне.
Программисты приближаются к базе данных как к черному квадрату, и права доступа рассматривают как одно действие времени.
Программисты рады отладить код и проблемы твердости вместо того, чтобы волноваться об определениях роли безопасности и обслуживании на уровне базы данных.
В типовом приложении, где существует экран "User / Role maintenance", предоставленный администраторскому пользователю, легко иметь таблицы как ПОЛЬЗОВАТЕЛЬ, SECURITY_ROLE, USER_SECURITY_ROLE и т.д. для поддержания информации о пользователе приложения вместо того, чтобы создать пользователя, записи безопасности в самой базе данных.
В случае не четко определенные роли в бизнес-модели (Двойные роли, настраиваемые права доступа и т.д.) легко реализовать безопасность на прикладном уровне, а не на базе данных.
Ре 2), потребности безопасности/разрешения приложения обычно имеют намного более прекрасную гранулярность, чем может быть обеспечено уровнями безопасности базы данных, если Вы не помещаете большую часть своей прикладной логики в базу данных. Простой пример - то, что, в то время как два пользователя, возможно, должны обновить таблицу заказов, можно создавать их собственный порядок, и другой может быть администраторский пользователь, редактирующий чужой порядок. Они оба потребность вставляют/обновляют полномочия на таблице. Вы могли реализовать это ограничение с помощью хранимых процедур, но это - действительно обходное решение - оба пользователя все еще должны обновить таблицу, так будет нуждаться в учетной записи с теми полномочиями.
Я предпочитаю использовать тот же счет дб на всех конечных пользователей приложения и реализовывать роли приложения и полномочия за пределами дб.
Очевидно, для веб-приложения, где пользователи могут зарегистрировать себя, 1) не практично. У меня есть сайт с 500,000 или больше пользователей - я хотел бы это много учетных записей дб?Я так не думаю!
Я проявляю минималистский подход (который я уверен, что многие спорили бы с), где пользователю дб выполнение приложения под были нужны минимальные полномочия для функционирования, но не больше. Это означает, что пользователь дб не может внести изменения схемы, таблицы отбрасывания, базы данных восстановления, и т.д.
Отдельная учетная запись используется во время разработки для модификации схемы, которая имеет необходимые полномочия.
каждый кажется самым разумным для большинства приложений. № 2 кажется неправильным мне. В этом случае у меня были бы группы, и пользователи могут вписаться в группу.
Я хотел бы добавить, что метод № 1 требует кода, который создает пользователей приложения для выполнения в соответствии с учетной записью DB, которая может смешать с полномочиями. Мне это - ненужный риск.
Поскольку роли базы данных (объектом, CRUD, и т.д.) обычно не относятся к именам пользователей, если они не разработчики базы данных. И AD и база данных имеют роли, но между двумя существует то же несоответствие. Единственные промежуточные защитимые отображения были бы для ролей администратора, но даже который неаккуратен.
Этой проблемой является результат общего недоразумения, созданного термином "интегрированная защита", которая действительно только заканчивает тем, что означала "единственный вход в систему" (т.е. пользовательская проверка), и возможно создать еще один флот ролей и групп в AD так, чтобы на AD администраторов могла быть возложена ответственность за безопасность базы данных - не обычно что-то, которое они хорошо обучены в, хотя я уверен, существуют исключения.
Существует что-то, чтобы быть сказанным для опции 2, если Вы находитесь в среде, где приложение сталкивается к Интернету и также внутренним пользователям, у которых есть больше полномочий.
Таким образом, Вы могли выполнить Интернет, стоящий перед сервером (серверами) приложений под менее привилегированным (с точки зрения доступа таблицы) учетная запись на DB, и внутренние пользователи могли получить доступ к отдельному серверу с дополнительным доступом. Преимущество состоит в том, что, даже если интернет-маршрут направления полностью поставлен под угрозу, он все еще не имеет полномочий смешать с таблицами, к которым внутренние пользователи нуждаются в доступе.
Опция 1 и 2 работала бы хорошо, если бы Ваша система аутентификации поддерживала делегацию (например, аутентификация Windows, Kerberos) - потому что затем сервер приложений не должен был бы содержать или сохранить свои собственные учетные данные, это могло просто исполнить роль клиента. Это на самом деле было бы значительно лучше, чем опция 3 (потому что, если сервер поставлен под угрозу, взломщик может только использовать полномочия в настоящее время подключенных пользователей, они не могут получить доступ к целой базе данных). Однако редко, чтобы у Вас была способность использовать эту функцию.
В обычном Интернете установка 3 является единственным реалистическим выбором.
Править: ни одна из этих опций не устраняет Вас от выполнения дальнейшего управления доступом с бизнес-логикой на уровне приложений, таким образом, это не корректно, чтобы сказать, что это - преимущество опции 3, как некоторые ответы предположили. Уровень приложений все еще знает, кто его клиент находится во всех случаях.
Я не знаю о Oracle, но в SQL Server, Вы хотите объединить соединения и лучший способ сделать, который должен сделать, чтобы отдельный пользователь соединился. Каждый различный пользователь использует различную строку подключения, и это может замедлить вещи, потому что существующие соединения не могут быть объединены и снова использованы для различных пользователей.
При выполнении N их приложение логика защиты должна пойти в середине их. Вы не хотите должными быть возвращаться к базе данных каждый раз, когда Вы хотите проверить и видеть, есть ли у кого-то полномочия к области. И полномочия в большей части приложения обычно более конкретны, чем может быть обеспечено безопасностью базы данных.