Мне нужно знать, недостатки делают бизнес-уровень в процедурах

Question

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

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

Причина, по которой он хочет это сделать, заключается в том, что у нас есть несколько систем с различными платформами (веб-приложение в .NET с VB.NET и другое настольное приложение, разработанное в Power Builder - Sybase).

Спасибо!

Answer 1

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

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

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

Answer 2

Pro веб-сервисы, логика con базы данных:

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

Pro логика базы данных, con web services:

1. Если база данных полностью принадлежит вашему приложению, возможно, использование логики является приемлемым выбором.
2. Меня не очень беспокоит страх переключения баз данных, потому что это происходит реже, чем изменения среднего уровня. Моды промежуточного программного обеспечения приходят и уходят, но данные - это жемчужина любого бизнеса.
3. Веб-сервисы также имеют свои недостатки. Перевод XML в объекты и обратно - пустая трата циклов ЦП. Вызовы в памяти на несколько порядков быстрее, чем сетевые. Одна и та же поездка к вашему «простому» сервису сегодня может составить 200 мс, но начните добавлять их, и довольно скоро ваш SLA исчезнет.

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

Answer 3

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

Edit: other user-contributed points:

• сложнее и дороже в масштабе

Answer 4

Я бы пошел на веб-сервис по нескольким причинам:

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

Answer 5

Определение бизнес-логики

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

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