Какой самый быстрый? Поиск данных

Question

Быстрее ли совершить одну поездку в базу данных и вернуть более 3000 строк, затем манипулировать ими в .net & LINQ или быстрее сделать 6 вызовов, возвращающих пару из 100 строк одновременно?

Answer 1

Это будет полностью зависеть от скорости работы базы данных, пропускной способности и задержки сети, скорости машины .NET, фактических запросов и т. Д.

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

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

Answer 2

Если вы знаете, какие 6 операторов SQL вы собираетесь выполнить заранее, вы можете объединить их в один вызов базы данных и вернуть несколько наборов результатов, используя ADO или ADO.NET.

http://support.microsoft.com/kb/311274

Answer 3

проблема, с которой я столкнулся, заключается в том, что мне нужно все это, мне просто нужно, чтобы она отображалась отдельно ...

Ответ на ваш вопрос: 1 запрос на 3000 строк лучше, чем 6 запросов на 500 строк. (учитывая, что вы возвращаете все 3000 строк независимо друг от друга)

Однако вы не хотите (хотите) отображать 3000 строк одновременно, не так ли? По всей вероятности, независимо от использования Linq, вы захотите выполнить агрегирующие запросы и заставить базу данных выполнять эту работу за вас. Надеемся, что вы сможете создать SQL (или запрос Linq) для выполнения всей необходимой логики за один раз.

Не зная, что ты делаешь, трудно быть более конкретным.

* Если вам, безусловно, необходимо вернуть все строки, изучите метод ToLookup () для вашего linq IQueryable . Это очень удобно для группировки результатов нестандартными способами.

Да, и я настоятельно рекомендую LINQPad (бесплатно) для опроса запросов с Linq. Он содержит множество примеров, а также показывает формы sql и lambda, чтобы вы могли ознакомиться с Linq <-> lambda form <-> Sql.

Answer 4

Скорость - только одно соображение среди многих.

Насколько гибок ваш код? Насколько легко пересматривать и расширять систему при изменении требований? Насколько легко другому человеку читать и поддерживать ваш код? Насколько переносим ваш код? что если вы перейдете на другую СУБД или другой язык программирования? Важны ли какие-либо из этих соображений в вашем случае?

Сказав это, отправляйтесь в одну поездку туда и обратно, если все остальные вещи равны или неважны.

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

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

Как уже говорили другие, это зависит.

Answer 5

Это для одного пользователя, или многие пользователи будут запрашивать данные? Один вызов базы данных будет лучше масштабироваться под нагрузкой.

Answer 6

Это зависит

1) если ваша реализация коннектора использует много объектов и у вас большие строки (например, BLOB-объекты, многоугольники и т. Д.), У вас есть проблема, вам нужно загрузить МНОГО данных. Однажды я оптимизировал код, у которого была эта проблема, и он просто загружал несколько мегабайт мусора все время через localhost, и мое программное обеспечение теперь работает в 10 раз быстрее, потому что я удалил предварительное кэширование с помощью опции

2) Если ваши строки небольшие, и у вас есть хорошие шансы, что вам нужно прочитать все 3000, вам лучше получить большой набор результатов

3) Если вы не используете подготовленные операторы, все запросы должны быть проанализированы! Большой результат может быть лучше.

Надеюсь, это помогло

Answer 7

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

Answer 8

Я всегда придерживаюсь правила «приноси то, что мне нужно» и ничего более ... проблема, с которой я столкнулся, заключается в том, что мне нужно все это, мне просто нужно, чтобы это отображалось отдельно.

Так сказать ... У меня есть таблица с userid и typeid. Я хочу отображать все записи с идентификатором пользователя и отображать их на странице в сетках, скажем, через typeid.

В данный момент я вызываю sproc, который "выбирает field1, field2 на вкладке, где userid = 1", затем на странице установите источник данных сетки в t из вкладки, где typeid = 2 выберите t;

Вместо вызова другого sproc "выберите field1, field2 на вкладке, где userid = 1 и typeid = 2" 6 раз.

??

Answer 9

Если вы говорите о запросе, который уже был выполнен SQL (оптимизирован SQL Server), работа с LINQ или SqlDataReader может фактически иметь такую ​​же производительность.

Единственное отличие будет в том, «насколько сложно будет поддерживать ваш код?»

LINQ ничего не запрашивает в базу данных, пока вы не запросите результат с помощью ".ToList ()" или ".ToArray ()" или даже ".Count ()". LINQ динамически создает ваш запрос, поэтому он точно такой же, как и у SqlDataReader, но с проверкой во время выполнения.

Answer 10

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

Если вы потянете 3000 строк не часто, это может сработать для вас в краткосрочной перспективе. Однако, если, скажем, 10 000 человек выполняют один и тот же запрос (игнорируя эффекты кэша), это может стать проблемой как для приложения, так и для базы данных.

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