Должны ли базы данных использоваться только для сохранения

Question

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

Answer 1

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

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

Я вижу две причины поместить его на сервер приложений:

1). Масштабируемость. Сравнительно сложно добавить больше баз данных, если база данных слишком занята. Распределение данных между несколькими базами данных действительно сложно. Поэтому вместо этого перенесите бизнес-логику на уровень сервера приложений. Теперь у нас может быть много экземпляров сервера приложений, выполняющих бизнес-логику.

2). Ремонтопригодность. В принципе, код хранимой процедуры может быть хорошо написан, модульный и повторяемый. На практике кажется, что гораздо проще написать поддерживаемый код на языке OO, таком как C # или Java. По какой-то причине повторное использование в хранимых процедурах, кажется, происходит путем вырезания и вставки, и поэтому со временем становится трудно поддерживать бизнес-логику. Я бы признал, что с дисциплиной этого не должно быть, но дисциплины, похоже, сейчас не хватает.

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

Answer 2

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

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

Итак, это зависит.

Answer 3

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

Увы, большие собаки СУБД либо недостаточно компетентны, либо не желают поддерживать это, что делает этот идеал невозможным и делает своих клиентов заложниками своих основных дойных коров.

Answer 4

Я видел одно приложение, разработанное (довольно умным парнем) с таблицами в форме:

id | one or two other indexed columns | big_chunk_of_serialised_data

Доступ к этому в приложении прост: есть методы, которые будут загружать одно (илинабор) объектов, десериализацию по мере необходимости.И есть методы, которые сериализуют объект в базу данных.

Но , как и ожидалось (но, к сожалению, только задним числом), есть очень много случаев, когда мы хотим запросить БД вкаким-то образом за пределами этого приложения!Это можно обойти различными способами: специальный интерфейс запросов в приложении (который добавляет несколько уровней косвенности для получения данных);повторное использование некоторых частей кода приложения;рукописный код десериализации (иногда на других языках);и просто необходимость обходиться без полей, которые находятся в десериализованном фрагменте.

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