Безопасность данных должна быть выполнена на стороне базы данных?
Что касается «наименее эффективной работы для db», я думаю, что следующее было бы правильным и менее логичным вводом-выводом для вашей схемы. Поймите, однако, что вы НЕ МОЖЕТЕ знать наверняка, если не посмотрите на планы объяснения (ожидаемые и фактические).
Тем не менее, я рекомендую попробовать это - он обращается к таблице «alb» только один раз, тогда как ваш исходный запрос необходимо будет получить к нему доступ четыре раза (один раз, чтобы получить «базовую» запись альбома, а затем еще три для трех подзапросов).
select alb.titreAlb as "Titre",
(select count(*) from pays_album t2 where t2.idAlb = alb.idAlb) "Pays",
(select count(*) from pers_album t2 where t2.idAlb = alb.idAlb) "Personnages",
(select count(*) from juron_album t2 where t2.idAlb = alb.idAlb) "Jurons"
from album alb
where alb.titreAlb = "LES CIGARES DU PHARAON"
8 ответов
Не делайте этого. У нас недавно был ОЧЕНЬ неудачный опыт, когда "гуру базы данных" решил перейти к другой компании. Обслуживание всей логики в процедурах просто ужасно!!
Да, Вы собираетесь иметь некоторое повышение производительности, но это не стоит того. На самом деле производительность даже не является большим беспокойством во внутреннем приложении. Инвестируйте больше денег в хорошие серверы. Это окупится.
К сожалению, нет никакого "одного истинного ответа". Выбор, который необходимо сделать, зависит от нескольких факторов, как:
- Знакомство команды с данными решениями (т.е. если большинство их является удобной записью SQL, это может быть в базе данных, однако если большинство их более довольно C#, это должно быть в коде),
- "Политическая власть" каждой стороны
- и т.д.
Нет никакого решающего преимущества ни в каком направлении (поскольку Вы сказали, что увеличение производительности минимально), одной вещью иметь в виду является DRY (не Повторяйте Себя), принцип: не повторно реализуйте функциональность дважды (в коде и в DB), потому что хранение их в синхронизации будет кошмаром. Выберите одно решение и придерживайтесь его.
Хранимые процедуры обычно являются победой для безопасности. Упрощение отношений между Вашим приложением и базой данных сокращает количество мест, где у Вас могут быть ошибки; ошибки в коде, который соединяет интерфейсом с бизнес-логикой к базе данных, имеют тенденцию быть проблемами безопасности. Так, Ваш DBA не является неправильным относительно блокировки вещей вниз к хранимым процедурам.
Другое преимущество для блокировки приложения вниз к хранимым процедурам - то, что соединению с базой данных стопки приложения можно было заблокировать его полномочия вниз к определенным вызовам хранимой процедуры и ничему иному.
Преимущество для вовлечения DBA в логике защиты для Вашего приложения - то, что различные функции приложения и роли могут быть разделены в базе данных вниз к представлениям, так, чтобы, даже если динамический SQL и универсальные избранные операторы необходимы, повреждение от уязвимости SQL могло быть ограничено.
Оборот этого является, конечно, потерянной гибкостью. ORM, очевидно, будет быстрее для разработки к, чем постоянное согласование с DBA по параметрам хранимой процедуры. И, когда давление на те хранимые процедуры растет, все более вероятно, что сами процедуры обратятся к динамическому SQL, который будет так уязвим, как приложение составило SQL для нападения.
Здесь существует счастливый второй план, и необходимо попытаться найти его. Я недавно работал над проектами, которые были сохранены от довольно ужасных проблем Внедрения SQL, потому что DBA тщательно настроил базу данных, ее соединения и ее хранимые процедуры для "наименьшего количества полномочия", так, чтобы у любого пользователя базы данных был доступ только к тому, что они должны были знать.
Очевидно, поскольку Вы пишете код SQL в своей логике приложения, быть уверенными, что Вы последовательно используете параметризованные подготовленные операторы, что Вы санируете свой вход, что Вы помните интернационализировавший вход (существуют многие, много способов сказать одинарную кавычку по HTTP), и что Вы помните то, как Ваша база данных ведет себя, когда исходные данные являются слишком большими для ширины столбцов.
ПО МОЕМУ СКРОМНОМУ МНЕНИЮ:
Уровень прикладной службы-> прикладная логика и проверка
Уровень данных приложения-> логика данных и безопасность
База данных-> непротиворечивость данных
Вы будете укушены подходом sproc рано или поздно, я научился этому на горьком опыте.
Procs являются большими для операций выстрела, для которых нужна большая производительность, но часть CRUD является заданием уровней данных
Все это зависит от Вашего случая, вероятно, лучше не пойти путем SP и сделать все путь DDD (сделайте Модель предметной области в коде и использовании этим).
Однако, если у Вас есть база данных, которая не только используется Вашим приложением, но многими затем необходимо, вероятно, рассмотреть веб-сервисы. Всегда, база данных должна только быть доступной через один слой, который еще осуществляет бизнес-правила, Вы собираетесь закончить с "грязными" данными и санируете свои данные, позже намного большая боль, чем запись нескольких бизнес-правил заранее. Хорошей базе данных нужно установить проверочные ограничения и индексы, таким образом, она будет иметь некоторые бизнес-правила, нравится ли Вам это или нет.
И если необходимо иметь дело с миллионами и миллиардами записей, Вы будете рады иметь хорошего парня DB, который решает проблему для Вас.
Вы могли сделать это, но это - огромная боль, чтобы разработать против и поддержать. Возьмите его от кого-то, кто находится на проекте, где почти вся бизнес-логика кодируется в хранимых процедурах.
Для безопасности ASP.NET имеет пользователя и ролевое управление, испеченное в него так, Вы могли бы сохранять прохождения в базу данных, но и что? В обмен это становится намного более раздражающим, чтобы обработать и отладить систему и ошибки проверки, потому что они должны пузыриться от базы данных.
Поблочное тестирование является намного более трудным, так как платформы, доступные для поблочного тестирования sprocs, намного менее разрабатываются.
Надлежащее ООП и домен управляемый дизайн являются всем, но из окна.
И увеличение производительности будет крошечным если таковые имеются. Мы говорили об этом здесь.
Я рекомендовал бы, если Вы хотите сохранить свою исправность как разработчик, сражаться изо всех сил для хранения базы данных как слоя персистентности только
Мое мнение - то, что само приложение должно обработать аутентификацию и авторизацию. На стороне базы данных необходимо только обработать шифрование данных по мере необходимости.
Я создал основанные на хранимой процедуре приложения в прошлом. В Вашем случае там, возможно, способ сохранить аутентификацию на слое базы данных и иметь Вашу бизнес-логику в C#. Используйте представления для ограничения данных (Вы только видите строки, у Вас есть полномочия к). Эти представления могут использоваться в LINQ с той же простотой как таблицы. Вы устанавливаете свои обновления для случая с хранимыми процедурами.
Это позволяет linq, бизнес-логику в C# и общий слой аутентификации в базе данных, которая управляет доступом к данным.