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

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

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

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

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

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

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

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

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

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

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

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

Я не думаю, что совместное использование Sprocs между несколькими приложениями имеет смысл.

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

Использование одной и той же архитектуры может работать в разных приложениях, но представьте, что вы пытаетесь использовать один и тот же уровень бизнес-логики в нескольких приложениях. "Но ждать!" вы говорите: «Это глупо ... если я использую один и тот же BLL, зачем мне отдельное приложение? Они делают то же самое!»

QED.

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

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

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

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

В идеале используйте одну процедуру, а не несколько версий. Если вам нужны версии для каждого клиента, подумайте о том, чтобы использовать 1 дБ для каждого клиента, а не 1 дБ для всех клиентов. Это также позволяет использовать некоторые интересные постановки баз данных на разных серверах (выделяйте более крупные / более загруженные серверы более крупным серверам, в то время как более мелкие могут совместно использовать оборудование)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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