![]() |
|
![]() ![]() ![]() |
|
Karrde |
|
|||
Шустрый ![]() Профиль Группа: Участник Сообщений: 62 Регистрация: 11.11.2006 Репутация: нет Всего: нет |
Доброго времени суток. Не уверен, в эту ли тему...
Допустим, в базе хранится некоторый объем данных. Пользователь программы должен иметь доступ к любой из записей массива. Т.е. получается, желательно загружать весь массив структур в память программы? или всё таки брать как-нибудь по частям и выводить постранично, а при переходе на другую страницу выгружать следующий пакет данных из базы? Кто что посоветует? |
|||
|
||||
Earnest |
|
|||
![]() Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Экс. модератор Сообщений: 5962 Регистрация: 17.6.2005 Где: Рязань Репутация: 7 Всего: 183 |
Размер (данных) таки имеет значение.
Если всех данных не сильно много (влазит в виртуальную память; для Виндоус32, например, это порядка 1гб, чтобы без особых проблем было), то загружайте все, так проще. Если данные значительно больше, то организовывайте подкачку. -------------------- ... |
|||
|
||||
Akina |
|
|||
Советчик ![]() ![]() ![]() ![]() Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 20 Всего: 454 |
Фреймы.
В память загружается фрейм, который в несколько раз больше окна отображения. И производится отображение части фрейма. Как только текущее отображение начинает приближаться к границе фрейма, в фоновом режиме производится подчитывание данных так, чтобы текущее окно отображения опять было приблизительно в середине фрейма. Само собой далёкие от текущей области отображения блоки выгружаются. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
Pavia |
|
|||
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 418 Регистрация: 6.12.2008 Репутация: 11 Всего: 12 |
Karrde, При такой постановки задачи нет принципиальных различий для выбора между двумя мотодами. Но с учётом того что интерфейс СУБД развит в отличии от вашего я бы оставил бы все на стороне сервера.
|
|||
|
||||
_Y_ |
|
|||
![]() Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1651 Регистрация: 27.11.2006 Репутация: 8 Всего: 34 |
Я когда-то в древности (когда компьютеры были с большими номерами типа 286, 386
![]() Шекспир же заключался в том, что размер страницы варьировался, в зависимости от скоростей данного компа (процессора, обмена данными с диском), чем и достигалось максимальное (для данного конкретного колхоза) быстродействие. -------------------- Я вот в этом поучаствовал: http://sbor-nik.appspot.com/kick.jsp?id=sbor5737960678883328 (на правах саморекламы:) |
|||
|
||||
Karrde |
|
|||
Шустрый ![]() Профиль Группа: Участник Сообщений: 62 Регистрация: 11.11.2006 Репутация: нет Всего: нет |
Спасибо) Значит, всё таки буду делать постраничную обработку.
|
|||
|
||||
Karrde |
|
|||
Шустрый ![]() Профиль Группа: Участник Сообщений: 62 Регистрация: 11.11.2006 Репутация: нет Всего: нет |
Хм, я извиняюсь. Допустим, есть сервак, связанный с базой данных, и, соответственно, клиент. Может, серваку вообще лучше не хранить данные, просто на любые запросы читать из базы. а клиент выводит поступившие данные на форму(в таблицу, или ещё куда нить), и собственно списки данных не сохраняет. Всё, что надо клиенту для дальнейшей работы или дальнейших запросов, он может взять из формы. Или всё таки на одной из сторон лучше хранить хотя бы одну страницу данных в памяти?
|
|||
|
||||
![]() ![]() ![]() |
Правила форума "Алгоритмы" | |
|
Форум "Алгоритмы" предназначен для обсуждения вопросов, связанных только с алгоритмами и структурами данных, без привязки к конкретному языку программирования и/или программному продукту.
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, maxim1000. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Алгоритмы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |