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

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

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

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

"Это обоснованное беспокойство?"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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