Шаблон с 3 уровнями и большие объемы данных

Да, ваш инстинкт прав.

Держу пари, что ваш UI-клиент не хочет просматривать полмиллиона записей сразу. Google не возвращает каждое обращение на отдельной странице; вы тоже не будете.

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

Шаблон MVC прекрасен, но это не священное писание. Сделайте выбор, который подходит вашему приложению.

Я полагаю, вы не показываете сразу 500 000 записей во внешнем интерфейсе? Вы, наверное, делаете некоторую разбивку на страницы, верно? Таким образом, за один раз возвращайте из базы данных только одну страницу данных.

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

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

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

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

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

Вы можете построить абстракцию поверх класса SqlReader. Таким образом, вы не SqlReader нужно передавать напрямую, но вы все равно можете обрабатывать объекты по одному.

Итераторы Think.

Если я правильно понимаю, вы хотите «проанализировать» записи, а затем сохранить некоторые из них и избавиться от остальных. Что ж, в этом случае я думаю, что лучше всего будет справиться с этим в самой базе данных (PL / SQL или T / SQL). Такие требования должны быть высшим приоритетом, а не архитектура. Поскольку вы не отображаете просто анализ, лучше всего сделать это в самой процедуре.

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

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

Вопрос в том, ожидает ли пользователь нажать кнопку, обработать все 500 КБ записей и увидеть результат? Если так, готовы ли они сесть и посмотреть крутящуюся гифку или будет удовлетворительно получить какое-то уведомление, когда процесс будет завершен? Если обработка 500 КБ имеет первостепенное значение, нужно ли вносить изменения в вашу модель данных для поддержки этого процесса? Существуют такие методы обработки, как очереди сообщений Hadoop и , которые предназначены для такого большого объема, но нужно ли вам идти до такой степени? Возможно, вы сумеете оправдать ожидания своих пользователей, прежде чем терять голову из-за производительности.

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

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