Как хранить огромное количество строк данных при обработке. В REST это допустимо?

Question

Ищу совет ......

Я анализирую старый C# веб-метод для перезаписи в REST. В старом методе я заметил, что один частный метод вызывается несколько раз (почти 25+). Этот закрытый метод подключается к базе данных и просто вызывает простой оператор выбора с простым условием где. Это возвращает одну строку.

В моем новом методе я планирую выбрать все содержимое таблицы (приблизительно 400 строк) и сохранять на стороне. net всякий раз, когда какие-либо данные, необходимые из этого результирующего набора, думают о его запросе. написав LINQ или лямбду. Это правильный способ хранения этого огромного набора данных во время выполнения этого основного метода? Это правильный подход? Как я могу оптимизировать? Могу ли я сохранить эти данные в состоянии c с данными?

Answer 1

Для вашего сценария я бы порекомендовал следующий подход:

Создание хранимой процедуры

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

1. Отделение логики базы данных c от бизнес-логики c. В идеале ваш код. NET должен состоять только из бизнес-логики c.
2. Если вы уже не используете параметризованный запрос в своем операторе SELECT, в противном случае хранимая процедура предлагает:
   • Лучшая защита против SQL Атаки с использованием инъекций
   • Нижний сетевой трафик c (отправка имени хранимой процедуры против Dynami c Запрос)
   • SQL, способный оптимизировать хранимую процедуру в плане кэшированных запросов лучше чем Dynami c Запрос. Оптимизация плана запроса
3. Извлечение записей с помощью хранимой процедуры будет работать лучше, чем использование foreach / LINQ / Lambda в C#. База данных оптимизирована для поиска данных и имеет больший объем памяти и лучшую загрузку ЦП для обработки этих операций поиска данных. Это особенно верно, если у вас есть правильный индекс БД по вашим критериям поиска. Мы рассмотрим это в следующем разделе.

Ссылка: Dynami c SQL против хранимой процедуры

Создайте некластеризованный индекс для вашего критерии поиска

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

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

Answer 2

Ну, это зависит.

Вызов Sql Выбор сервера, где 25 раз на один метод не очень хорошая вещь. Каждый внепроцессный вызов требует гораздо больше времени по сравнению с локальным (несмотря на то, что ADO Net кэширует соединение независимо от того, что он делает)

Кеширование 400 строк выглядит не таким уж большим делом, если оно одинаково установлено для каждых 25 звонки. Он достаточно мал, чтобы эффективно обрабатывать запрос C# linq.

Однако как насчет масштабируемости? Сервер Sql может эффективно обрабатывать сотни тысяч строк с использованием индексов, специального кэширования и т. Д. c.

Давайте представим, что база данных увеличивается, и у вас есть 4M строк, которые нужно проверить, чтобы получить одну строку. Я не думаю, что хорошо иметь 4M записи, которые будут прочитаны C# и отфильтрованы локально в памяти.

Таким образом, вы должны проверить данные и код, который написан.

Лучший способ состоит в том, чтобы смешать два подхода в один.

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

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