Повторное использование хранимых процедур SQL в разных приложениях

Question

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

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

Спасибо!

Answer 1

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

Answer 2

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

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

Это имеет несколько преимуществ:

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Часто эти хранимые процедуры вызывают централизованный или "главный" хранимый процесс, но этот метод оставляет место для изменений, специфичных для приложения, в будущем.

Answer 6

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

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

Answer 7

Всякий раз, когда у нас были хранимые процедуры, общие для нескольких приложений, мы создавали базу данных только для этих процедур (а также для представлений, таблиц и т. Д.). В этой базе данных (мы назвали ее "base") будет ответственный за нее разработчик (или группа) (сопровождение и тестирование).

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

Answer 8

Последняя часть вашего вопроса, я полагаю, ответила сама.

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

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

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

Answer 9

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

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

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

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

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

Это может быть проще в системах хранения данных / поддержки принятия решений; Я обычно работаю в системах OLTP, где производительность транзакций имеет первостепенное значение.

Answer 10

Многие хранимые процедуры не зависят от приложения, но некоторые могут зависеть от приложения. Например, хранимые процедуры CRUD (создание, выбор, обновление, удаление) могут проходить через приложения. В частности, вы можете добавить логику аудита (иногда это делается в триггерах, но есть предел того, насколько сложным вы можете стать в триггерах). Если в вашем магазине программного обеспечения есть стандартная архитектура какого-либо типа, для среднего уровня может потребоваться хранимая процедура для создания / выбора / обновления / удаления из базы данных независимо от приложения, в этом случае процедура является общей.

В то же время могут быть некоторые полезные способы просмотра данных, например, GetProductsSoldBySalesPerson и т. Д., Которые также не зависят от приложения. У вас может быть несколько таблиц подстановки для некоторых полей, таких как отдел, адрес и т. Д., Поэтому может быть процедура для возврата представления таблицы со всеми текстовыми полями. Т.е. вместо SalesPersonID, SaleDate, CustomerID, DepartmentID, CustomerAddressID процедура возвращает представление SalesPersonName, SaleDate, CustomerName, DepartmentName, CustomerAddress. Это также может быть использовано в разных приложениях. Система взаимоотношений с клиентами будет требовать имя клиента / адрес / другие атрибуты, как и система выставления счетов. Так что то, что выполняло все объединения и собирало всю информацию о клиенте в одном запросе, вероятно, будет использоваться во всех приложениях. По общему признанию, создание способов просмотра данных является областью представления, но часто люди используют хранимые процедуры для этого.

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