Являются ли хранимые процедуры хорошей идеей, когда сервер не находится под вашим контролем?

Question

Существуют ли способы обеспечения согласованности хранимых процедур на уровне программного обеспечения, чтобы быть уверенными, что они будут делать то, что от них ожидают?

Я не хочу использовать sprocs, потому что читать и изменять их так просто, если у вас есть административный доступ к компьютеру и копия Management Studio Express. Это обычная среда во многих установках, где клиенты владеют сервером, и предыдущий опыт научил меня, что клиентам (или конкурентам) нельзя доверять, чтобы они держали свои грязные руки подальше от базы данных.

Если хранимая процедура может быть изменена для выполнения каких-либо действий, кроме случаев, когда программное обеспечение выполняет постоянную проверку, ее можно сделать молча, чтобы делать то, чего не следует делать, и это не будет мудрым. Это заставляет меня чувствовать себя действительно неловко - знать, что я не контролирую то, что делает программное обеспечение.

Это действительная проблема?

Answer 1

Если честно, если у них есть права администратора, хранимые процедуры - это лишь один из многих способов испортить ваше программное обеспечение. Почему бы вам просто не дать понять клиенту, что они не поддерживаются, если они работают с хранимыми процедурами. Если у них возникнут проблемы, попросите их запустить сценарий, который выдает ваши хранимые процедуры в файл, и заставить их отправить его вам.

Любые изменения означают, что вы исправите их, но не по своим, а по их центру, поскольку они вызвали проблему.

С точки зрения проверки, единственное, о чем я мог подумать, - запустить хранимый процесс с известными данными и убедиться, что он возвращает то, что, как вы думаете, должен. Но это может быть трудно достичь в их базе данных.

Answer 2

Можно зашифровать хранимые процедуры, используя подсказку С ШИФРОВАНИЕМ - есть минусы, такие как хранимый процесс, который чрезвычайно сложно расшифровать.

Другой вариант - использовать инструмент ORM (или аналогичный), который генерирует код SQL динамически, например, Linq to SQL / Entities, NHibernate и т. Д.

Или вы можете просто убедиться, что клиент знает, что система больше не будет поддерживаться, если какие-либо изменения были сделаны на уровне БД - это может быть достаточным стимулом для того, чтобы они не вмешивались.

Answer 3

«Это действительная проблема?»

Да. Хранимые процедуры - это кошмар обслуживания, даже на локально управляемом сервере.

Тебе они не нужны. Создайте свое приложение так, как будто вы собираетесь использовать хранимые процедуры. Проектируйте узкие, короткие процедурные элементы, как будто они будут реализованы как хранимые процедуры. Затем реализуйте их на выбранном вами языке - он будет работать так же быстро, как и хранимая процедура. (В некоторых случаях быстрее.)

У некоторых людей есть анекдоты, утверждающие, что хранимые процедуры бывают быстрыми. Эти анекдоты никогда не являются непосредственным сравнением целенаправленной транзакции вне БД и хранимой процедуры. Анекдот всегда сравнивает какую-то разросшуюся ненужную программу с ревизией, в которой используются хранимые процедуры.

Это создает целевые транзакции, которые улучшают производительность. Это можно сделать и в вашем приложении.

Answer 4

Если вы предоставите им права администратора (общие), то вы не сможете их остановить. Тем не менее, есть несколько отличных инструментов, таких как RedGate SQL Compare, которые позволяют сравнивать 2 схемы базы данных (например, снимок того, чем он должен быть, с тем, что есть сейчас), и он мгновенно сообщит вам, есть ли какие-либо изменения, и что они.

Если вы знаете, что пользователь собирается добавить свои собственные вещи, скажите им некоторые основные правила, например, если они собираются добавить таблицы, добавьте некоторый префикс к имени таблицы, который будет определять его как свое. То же самое работает с сохраненными процессами ... если они добавляют новые, добавьте их с каким-то префиксом для их обозначения.

Если вы хотите дать им возможность изменять функциональность ваших хранимых процедур или добавлять столбцы к вашим таблицам, то вам нужно сделать предварительный дизайн. Вы можете взять каждую из ваших таблиц, например TableA, и добавить дочернюю таблицу TableA_User с отношением один к одному. Эта таблица содержит любые пользовательские данные, к которым вы можете предоставить им доступ, связанные с этой основной таблицей. Вы также можете дать им заранее определенные хуки для изменения функциональности вашей бизнес-логики. Например, каждый раз, когда вы добавляете новую строку типа «такой-то», вы можете вызывать заглушку хранимой процедуры, которая передает данные новой строки, и они могут изменять ее перед сохранением в базе данных. Очевидно, это быстро усложняется.

Лучший способ справиться с этим - оставаться отзывчивым с вашим клиентом. Если они хотят изменений, внедрите их быстро и получите за это деньги.

Answer 5

Конечно, это серьезная проблема. Если вас беспокоит изменение хранимых процедур, вам, вероятно, следует также позаботиться и о других частях базы данных!

Вы, безусловно, должны программировать более защищенно, чем обычно, против хранимых процедур. Всегда есть искушение рассматривать это как надежный носитель, когда у вас есть полный контроль над содержимым. Например: проверьте, соответствуют ли параметры тем, что вы ожидаете, прежде чем вызывать их, убедитесь, что длина полей соответствует ожидаемой и т. Д.

Я согласен с Паксом выше, что это лучше всего решать через контакт; если клиент «сломает» базу данных, ему придется заплатить за исправление позже.

Вы всегда можете проверить репрезентативную выборку длин хранимых процедур, при запуске или как угодно - вы можете раздражать пользователя, если что-то не совпадает.

Answer 6

Я использую хранимые процедуры в качестве «интерфейсов». Помимо преимуществ в производительности (хранимые процедуры почти всегда превосходят специальные запросы), это позволяет слабую связь между моей БД и кодом UI.

Answer 7

Я не совсем понимаю ваш сценарий. Почему ваши конкуренты имеют прямой доступ к вашей базе данных, чтобы они могли что-то испортить?

Как вы могли бы поддержать ваше приложение, если пользователи вносят изменения в вашу базу данных вручную без консультации с вами?

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

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