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

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

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

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

Что ж, ответ всегда: «в зависимости от обстоятельств». Вы хотите оптимизировать загрузку базы данных или загрузку приложения?

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

Спасибо

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

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

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

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

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

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

Единственная разница будет заключаться в том, "насколько сложно будет поддерживать ваш код?"

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

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

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

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

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

??

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

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

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

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

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

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

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

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

the problem I have here is that I need it all, i just need it displayed separately...

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

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

Не зная, что вы делаете, сложно говорить более конкретно.

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

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

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

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

По-разному

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

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

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

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