Организция получения результатов поиска в СУБД
От: antonmo Россия clrus.ru
Дата: 24.07.06 02:51
Оценка:
Здравствуйте.
Может быть, кому-то и покажется вопрос простым, но для меня это очень важно.
Суть дела:
Дано:
Есть база данных МSSQL и куча таблиц с кучей записей.
Есть aspx страница, генерирующая и выполняющая запрос к вышеуказанной СУБД.
Задача:
Получить необходимое кол-во записей из БД, например первые 20 или четвертые 20.
Отобразить полученные записи на aspx странице. Если записей больше 20 разбить на несколько страниц.
Отобразить кол-во доступных страниц, на каждой из которых еще по 20 записей.

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

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


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

Результат: плюсы: неизменный размер базы данных
минусы: увеличение нагрузки на процессор (за счет неизменности объема данных и повторных запросах)
увеличение времени выполнения 2-го и более запроса.

Вот так я вижу эту задачу.
Очень хотел бы узнать ваше мнение по решению данной задачи. Ресурсы выч. системы не важны, чем больше эффективность, тем лучше.
Заранее благодарен.
Организция получения результатов поиска в СУБД
От: Аноним  
Дата: 24.07.06 06:31
Оценка:
>1) с помощью временных таблиц.

а почему вместо временных таблиц вьюшки не использовать?, а так первый вариант симпатичнее получаеться


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Re: Организция получения результатов поиска в СУБД
От: antonmo Россия clrus.ru
Дата: 25.07.06 22:10
Оценка:
Здравствуйте, VovanDr.

Совсем недавно начал работать с MSSQL, но знаю, что в Oracle существуют такие вещи, как
view и Materialized view. Первая — это просто запрос, а вторая это уже реальная таблица, обновляемая СУБД
автоматически, при появлении новых подходящих записей.

Если в MSSQL так, то возможно view будет и быстрей, но все же это не таблица и вычерпывание данных будет происходить при обращении к такому view из других требуемых таблиц. Я прав?
Re: Организция получения результатов поиска в СУБД
От: Аноним  
Дата: 26.07.06 07:46
Оценка:
1 -е решение с временной таблицей есть оч неудачное и к тому же опасное решение. Всегда в таких случаях есть вероятность того что юзер увидит уже устаревшие данные, а что он потом с ними сделает- эт уже никому неизвестно. Может руководству понести в виде отчета, или че-нить еще похуже.
В принципе ничего страшного в этом нет эадача вообщем довольно тривиальна и решалась не одним десятком людей.
Эта задача полностью лежит в плоскости MSSQL сервера и его технологии запросов, индексов и т.д.
Рекомендую посмотреть это: http://www.sql.ru/faq/faq_topic.aspx?fid=105. Ну и конечно внимательно смотреть на запросы, планы выполнения индексы БД.


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Re: Организция получения результатов поиска в СУБД
От: GlebZ Россия  
Дата: 26.07.06 09:04
Оценка:
Здравствуйте, antonmo, Вы писали:

Смотрим статью К вопросу об идентификаторах
Автор(ы): Иван Бодягин
Дата: 07.02.2004
Уникальная идентификация записей в таблице, является практически основой реляционных СУБД. Вообще в реляционной теории предполагается, что если две записи ни чем друг от друга не отличаются, то это явная избыточность, и количество таких записей можно сократить до одной. Собственно вопросам этой самой идентификации, каковых возникает на удивление много, и посвящен этот FAQ.
. Если это MSSQL 2005 — то MS SQL 2005: оконные функции
Автор(ы): Иван Бодягин (Merle)
Дата: 14.03.2005
Рассмотрена задача обеспечения серверной защиты реляционных данных на уровне отдельных строк.
. Если запрос сложный, то зачастую быстрее всего работает просто пролистывание и чтение с помощью DataReader'a на определенных строк. Нужно подбирать нужный способ.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Организция получения результатов поиска в СУБД
От: Dronopotamus Россия  
Дата: 26.07.06 09:31
Оценка:
Здравствуйте, antonmo, Вы писали:

A>Здравствуйте.

A>Может быть, кому-то и покажется вопрос простым, но для меня это очень важно.
A>Суть дела:
A>Дано:
A> Есть база данных МSSQL и куча таблиц с кучей записей.
A> Есть aspx страница, генерирующая и выполняющая запрос к вышеуказанной СУБД.
A>Задача:
A> Получить необходимое кол-во записей из БД, например первые 20 или четвертые 20.
A> Отобразить полученные записи на aspx странице. Если записей больше 20 разбить на несколько страниц.
A> Отобразить кол-во доступных страниц, на каждой из которых еще по 20 записей.

я бы для начала сделал так:
1) посылаем запрос, возвращающий только ключевые столбцы всех записей, без учета пейджинга
2) датаридером проматываем до нужной страницы, читаем ключевые значения
3) в цикле догружаем нужные поля для каждой записи
а вот если не хватит производительности...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Удар судьбы в лоб означает, что не возымели действия ее пинки под зад
Re[2]: Организция получения результатов поиска в СУБД
От: Dronopotamus Россия  
Дата: 26.07.06 09:37
Оценка:
Здравствуйте, Dronopotamus, Вы писали:

D>а вот если не хватит производительности...


то я бы первым делом убил цикл и догружал записи одним запросом
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Удар судьбы в лоб означает, что не возымели действия ее пинки под зад
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.