Очистка данных на самом низком уровне обычно означает выполнение некоторой ссылочной целостности и работы с первичным и внешним ключами. Это должно быть сделано в хранимых процедурах (чтобы хранимые процедуры знали, что значение из последовательности / генератора A_seq должно быть помещено в первичный ключ таблицы A, и это также должно быть помещено в A_id в таблицу B и т. Д.). Например, может существовать некоторая хранимая процедура под названием SavePurchaseHead, SavePurchaseDetails, GetSegmentForCustomer, GetCustomerBalance, GetOverdueLevelForSegment и т. Д. Это делается главным образом для того, чтобы скрыть логику инструкций INSERT, UPDATE или JOIN sql внутри базы данных.
А теперь представьте, куда вы захотите поместить некоторые знания о бизнесе, например: «Клиент, просроченный на 5000 долларов США, не может совершить новую покупку, пока он не заплатит наличными»? Хранимые процедуры, как правило, являются плохой идеей для таких вычислений. Лучшее решение состоит в том, чтобы иметь какой-либо бизнес-сервис, такой как MakeNewPurchase, который будет принимать данные клиентов и данные о закупках, а также заниматься бизнесом. Эта услуга, вероятно, может начинаться с получения информации о клиентском сегменте, а затем с баланса клиента и сравнения его с уровнем просроченного сегмента. Если все будет в порядке, будут выполнены такие процедуры, как SavePurchaseHead и SavePurchaseDetails.
Таким образом, у вас будет несколько уровней знаний: клиентские приложения будут знать только, что для совершения покупки вам необходимо позвонить в службу MakeNewPurchase. Они будут говорить на «деловом языке». Плюс - важные изменения в бизнес-логике должны быть сделаны только в одном месте (уровень бизнес-логики) вместо пяти приложений. Слой бизнес-логики будет знать, как устроен бизнес, но будет недостаточно знаний о том, как составляется пользовательский интерфейс, и будет недостаточно знаний о том, как именно хранятся и оптимизируются данные. База данных будет иметь только знания о данных и как они хранятся. Это разделит обязанности между всеми уровнями, и, работая в команде разработчиков, это поможет вам поддерживать порядок через крошечные интерфейсы. И, как упоминалось ранее, одно приложение не повредит другому, «сломав» данные.
Две последние вещи - когда я говорю «сервис-ориентированное промежуточное программное обеспечение», я не имею в виду какую-то шумиху. Как я уже писал ранее, SELECT и UPDATE должны быть на уровне БД. «Промежуточное программное обеспечение» или «бизнес-уровень» (независимо от того, как вы это называете) должны быть в большей степени ориентированы на бизнес. На самом деле, веб-сервисы и WCF - это всего лишь инструменты. Независимо от того, как вы это сделаете - это можно сделать с помощью WCF, J2EE, PHP, WS- *, Borland Delphi или даже чистого C. Какая технология вы будете использовать, учитывает имеющиеся у разработчиков ресурсы, кривую обучения технологии, масштабируемость и ваши другие потребности. Но я думаю, что это должно быть сделано через какую-то сеть, и этот бизнес-уровень должен располагаться близко к базе данных.
Я надеюсь, что это также относится к вашему последнему размышлению о необходимости что-то сделать с вашими пятью приложениями в случае изменения БД. Посмотрите - необходимость изменения БД должна исходить из бизнес-потребностей. Если вам нужно сохранить некоторую дополнительную информацию - вам придется перепроектировать ее бизнес-сервис и, возможно, добавить некоторые поля в БД. Вам придется изменить базу данных и ваш бизнес-сервис. Существует большая вероятность того, что вам не придется изменять свои пять приложений, если вы разумно проектируете бизнес-уровень. Например, представьте, что вы захотите рассчитать оценку клиентов и использовать ее внутри себя, чтобы рассчитать хорошее предложение для ваших лучших клиентов - в таком случае вы, скорее всего, добавите одно поле в БД и измените некоторые услуги (добавьте службу для расчета оценки и измените расчет предложения сервис) без необходимости менять графический интерфейс. Однако, если однажды вы придете к выводу, что имя и адрес клиента слишком мало, и вы хотите собрать все его образовательные, здоровые, семейные, брачные, криминальные и кредитные данные - вам нужно будет не только изменить БД, но и изменить бизнес-уровень и предоставить пользователям ваших пяти приложений десятки новых экранов ввода для сбора таких данных ...