DataSet v / s База данных

Question

При разработке приложений очень полезно иметь всю бизнес-логику в одном месте.Так почему же у нас иногда есть бизнес-логика в хранимых процессах?Можем ли мы получить все данные из БД, сохранить их в наборе данных и затем обработать?Какова будет производительность приложения в этом сценарии?

Answer 1

Так почему же у нас иногда есть бизнес-логика в хранимых процессах?

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

Answer 2

Подумайте об этом простом примере, и он должен ответить на ваш вопрос:

Если у вас была база данных с ГБ из данные по куче таблиц и вы хотел просто получить простой клиент записывать и присоединяться к их заказам имеет смысл вернуть клиенту приложение или веб-сервер ГБ данных просто получить 1 КБ, который вы на самом деле ищете для

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

Answer 3

Так почему же тогда мы иногда имеем бизнес логика в хранимых процессах?

Я думаю, обработка должна быть сделана там, где она более значима.

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

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

Можем ли мы получить все данные из БД и сохранить его в наборе данных, а затем обработать Это? Каковы будут показатели приложение в этом сценарии?

Не думаю, что имеет смысл хранить все данные из БД в памяти приложения.
Ответ зависит от того, сколько данных? это часто меняется? как ваше приложение ведет себя, если данные изменяются в базе данных?

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

Answer 4

Обе модели существуют.

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

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

Когда количество строк очень мало (и всегда будет), тогда это не имеет значения. SQL является довольно бедным языком программирования по сравнению с C # или java, когда речь идет о модульном тестировании, поддержке инструментов и т. Д., Поэтому, если у вас есть 100 строк в вашей базе данных (и никогда не будет намного больше!), Тогда, конечно, не стесняйтесь поместить их в некоторую структуру данных памяти - хотя даже там база данных все равно будет более эффективной и менее ошибочной в таких областях, как сортировка.

Answer 5

Так почему же у нас иногда есть бизнес-логика в хранимых процессах?

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