Здравствуйте, MasterZiv, Вы писали:
MZ>Konstantin wrote:
>> Ну а как без пейджинга решить вопрос постраничного листания ?
MZ>А никак не надо решать вопрос постраничного листания. MZ>Постраничное листание -- это бесполезная трата машинного MZ>времени и сил листающего человека. MZ>Если ему что=то нужно, ему нужно дать возможность сформировтаь MZ>набор критериев для выборки и соответственно делать выборку.
MZ>А листания никому не нужны.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Konstantin, Вы писали:
K>>Ну просто я сейчас пытаюсь максимально ускорить работу базы, чтобы когда пойдет реальная работа, ничего не переделывать. И ищу вот такие узкие места.
W>А, так вы и есть разработчик? Тогда настоятельно советую изучить статью, указанную Anton Batenev.
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, MasterZiv, Вы писали:
MZ>>Konstantin wrote:
>>> Ну оказалось, что ускорить можно с помощью WHERE id > 700000. И это >>> весьма радует. Так что...
MZ>>Ты знаешь априори этот id > 700000 ? вместо 700000 для другой страницы MZ>>что ставить будешь ?
MC>Как ни странно — максимальный прочитанный ID (при листании на 1 страницу вправо) или минимальный прочитанный ID (при листании на 1 страницу влево).
Плюс, можно построить список этих стартовых id. При удалении перестраивать. При добавлении дописывать.
Konstantin wrote:
> Удаления будут нечастыми и можно построить значения стартовых id для > каждой страницы. Причем даже с помощью хранимой процедуры прямо на сервере.
Тогда твоё счастье. Тогда ты можешь пойти и дальне -- сделать достаточно
статичный список страниц с диапазоном или перечнем ID-ов на каждой странице.
Да как бы пробовал. Успешно в общем.
> Они, понимаешь ли, ленятся "сформировтаь набор критериев", их пейджинг > вполне устраивает. Темные, что тут говорить.
Ну, тут очень хорош простой метод: если другого метода получить данные
не будет, им ПРИДЁТСЯ формулировать критерии. Или придумывать свои новые,
что ещё лучше.
Anton Batenev wrote:
> Расскажи это, например, команде гугля, которая сделала постраничный > вывод результатов поиска. Ну или команде RSDN, которая сделала пэйджинг > в списках сообщений — эти ответят на чистом русском
RSDN — отвратительный сайт. С навороченным и дурацким интерфейсом.
Если бы не NNTP, меня бы тут вообще не было бы.
Про google уже написал.
Здравствуйте, MasterZiv, Вы писали:
MZ>wildwind wrote:
>> Пробовал?
MZ>Да как бы пробовал. Успешно в общем.
>> Они, понимаешь ли, ленятся "сформировтаь набор критериев", их пейджинг >> вполне устраивает. Темные, что тут говорить.
MZ>Ну, тут очень хорош простой метод: если другого метода получить данные MZ>не будет, им ПРИДЁТСЯ формулировать критерии. Или придумывать свои новые, MZ>что ещё лучше.
Методы твои понятны. Напомнило:
Пользователи не приняли систему. Всех пришлось уничтожить.
Здравствуйте, MasterZiv, Вы писали:
MZ>Konstantin wrote:
>> Удаления будут нечастыми и можно построить значения стартовых id для >> каждой страницы. Причем даже с помощью хранимой процедуры прямо на сервере.
MZ>Тогда твоё счастье. Тогда ты можешь пойти и дальне -- сделать достаточно MZ>статичный список страниц с диапазоном или перечнем ID-ов на каждой странице.
Хммм... А что если сделать отдельную таблицу, которая будет только ID содержать ? Там row format будет fixed и по идее позиционирование будет моментальным.
Konstantin wrote:
> Хммм... А что если сделать отдельную таблицу, которая будет только ID > содержать ? Там row format будет fixed и по идее позиционирование будет > моментальным.
Я не знаю, что такое fixed row format и кто его придумал.
Есть индексы, с ними надо работать. А fixed row format -ы это хачки
какие-то MYISAM-овские.
