Page numbers in pagination - why?

Question

Database

I don't like page indexes in a paginated selection.
Those. these are the classic numbers 1,2,3,4,5 in this one:

<a href="#">&lt;&lt;</a> <a href="#">&lt;</a> <a href="#">1</a> <a href="#">2</a> <a href="#">3</a> <a href="#">4</a> <a href="#">5</a> <a href="#">&gt;</a> <a href="#">&gt;&gt;</a>

Navigator previous-next love. The transition to the first — love. And they, these page numbers, are not there.
I don’t understand why they are needed either (unless I look indirectly: wow, I’ve chosen more pages).
For example, I have a certain table with a list of cities in the world:
| Название | население | дата основания | ... |
Let's say there are page indexes. It is obvious that there are over 9000 pages. How should such an index look like so that it would be convenient for me to use it?
It seems to me that over 9000 page numbers separated by spaces will take 10 screens, no less, but I can go to the desired page with one click. But no one in their right mind probably does this anymore (excluding, of course, forums.kuban.ru, which is super popular in my city, although they have already switched to the range).
I immediately discard the option with page numbers in the html select (all indexes will fit, they won’t eat up a lot of space, but using a select with over 9000 is inconvenient, to put it mildly).
A variant of Google Yandex, when not all indexes are displayed, but only from a certain range, i.e.

<a href="#">&lt;&lt;</a> <a href="#">&lt;</a> <a href="#">90</a> <a href="#">91</a> <a href="#">92</a> <a href="#">93</a> <a href="#">94</a> <a href="#">95</a> <a href="#">96</a> <a href="#">97</a> <a href="#">98</a> <a href="#">99</a> <a href="#">100</a> <a href="#">&gt;</a> <a href="#">&gt;&gt;</a>

(it's simple, I click on the 100th page, and scroll the index into the range 100 - 110). But in this scenario, to go to page 678, I need to click 66 times. Damn, that's sad.
Okay, I probably need to understand why I even needed to go to a particular page. For example, on the 7th. Or on the 25th. Or on the 177th.
So far, I see two options:
1. Out of curiosity (really, what is there on page 177? Maybe Voronezh?). A kind of content surfing. Rave.
2. I know something about the contents of page 177 (last time there was Voronezh, though).
Since I know something about the content, then I can use a search or filter, and reduce the number of pages from over 9000 to maybe 1 or 2 or 3.? It is unlikely that the indexes of the pages on the page will help me (they added more cities and Voronezh crawled to page 179, damn it ... or was Volgograd at 177, and Voronezh at 166? ... or was it Vologda, and Voronezh was at 154? .. so, remember the indices , remember, the head is filled with necessary and useful knowledge ...). In general, in any case, I can’t do without a filter, so what for all these cutlets with numbers, if there is less sense from them than from flies.
Let's look at it all from the server (and DBMS) side.
To build indexes of pages in a page, I need to know the number of records. Moreover, without taking into account START, LIMIT restrictions passed to the request to limit the output to the page. So, okay, let's use select count(1) from ... where <фильтры> .... The table weighs 10 GB, oh, cheers, there is an index of some foreign key for just a gig, we will scan it.
Or additionally scan a gig just to draw page numbers - not a bang (thought the DBMS)? And with any change in the filter, scan again (and without a filter, as I already understood, in any case, it’s impossible for me to find my beloved Voronezh)? Or even when moving to the next page? (Oh, DBMS thought).
Probably it is possible to cache the counter somehow (for each set of filters). Probably it is possible, when moving to the next index in a get-request, to stuff this value (the number of rows selected on the first one) with a parameter as well. In any case related to caching, there is a possibility of missing out on fresh data for tables that are not only read from. Probably, you can somehow still go out of your way, in an attempt to reduce the load on the server. But: for what?
So, my version:

<a href="#">первая</a> <a href="#">&lt;предыдущая</a> <a href="#">следующая&gt;</a>

and filters.
When fetching, we simply ask for one record more than we need to display on the page. If all records are returned, then there is a next page (draw the link next>). If the START passed during the transition is not zero, then there is a previous one (and the first one). And you don’t need to separately calculate the number of rows every time the data is displayed, you don’t need to scan the gigabyte index (Yeah, the DBMS calmed down).
However, megatons of VKontakte - classmates - Facebook - Google Yandex with indexes on the page seem to hint ...

Answer 1

The page number approach is a common and quite normal option.
At the expense of the 10GB index and its "scan" - to search for such large amounts of information, external systems are often used (Apache Solr, Sphinx, etc.). Therefore, the Base will not strain.
Why do you need page 177? This is some kind of insanity ... “What if I need it, what if I know that there will be something valuable on it” ...
Your option has the right to life, but again, pagination is very dependent on the specifics of the site, its content and orientation.
"However, megatons of vkontaktov - classmates - facebooks - googleyandexes with indexes on the page seem to hint .." - I think that they know quite well what they are doing :)
Good luck.

Answer 2

>Okay, maybe you need to understand why I even needed to go to a specific page
you don’t need, but I, for example, remember that the link I needed was “somewhere between the 203rd and 207th page of the Win7 vs Ubintu discussion”
to owners of similar indexers should also be attached to the timestamps on the page numbers, for ease of orientation

Answer 3

imho pagination is an atavism that came from paper editions and table of contents. It is based largely on the inertia of thinking, and is completely unsuitable for modifiable content. But any other approach will be associated with the need to rebuild consciousness and will be taken with hostility. Please note that readers now use a scroll bar that does not show the actual page number, but only visually determines "closer to the center", or "somewhere in the beginning".
I am morally on the side of the author of the post, but I understand how hard it will be to implement this everywhere. =((

Answer 4

And at work I have a self-written system (not a web one), where there is no partitioning and navigation at all. We simply load the first 1000 records that match the filter conditions, and then draw something resembling a torn piece of paper in the last line of the tablet. And it's true, well, we have 150,000 positions of the same nomenclature. Why does the user need to view all 150 thousand eyes? He won't digest that. Most likely, he either knows the barcode (arrived on the invoice from the supplier), or the approximate name, or at least the product group. At first, users spat, saying “I could see all the products in adinesk, but here you have some kind of search”, but then they got used to it. I think the navigation of 100500 pages is all because the user doesn't know what they want. And this, perhaps, from the inability of developers to convey to users what the system is intended for.

Answer 5

If all records are returned, then there is a next page (draw the link next>)

You're not right. 100 entries are perfectly divisible into 10 pages of 10 entries, in your case the 10th page will have a "next" link and shouldn't.

Answer 6

Probably, we need to see who, where and how developed the idea of ​​content pagers.
In Google, I go through pages 5 to 15, see which page my site is on :)
On Rubord, for example, it’s customary to press “print version” (opens the contents of the ENTIRE branch on one page) and then search the page to find the right piece. Very often, I move through the pages by indicating it in the address bar (tin in fact).
Your idea from the first previous next can be improved further - for example, make one control, where by hover “offer” the transition to both the first, the previous, and the next or filter.

Answer 7

Each type of page has its own specifics. In addition to actually browsing, pagination is sometimes needed so that users can give each other links to specific pages. At the same time, it seems more logical to use as a starting point not the page number multiplied by the number of records, but the unique identifier of the entity by which the records are sorted and by which the index in the database is compiled. Links to such pages do not break if new entries appear at the beginning of the list (on the first page). In another case, in static lists (for example, in dictionaries or books), the classic pagination + bookmarks for sections or chapters will be convenient.

Answer 8

Please, I beg you, do not make page-by-page selection ... by all means save the user from page-by-page scanning ... this is difficult / slow for the server (recently I analyzed another vyser for cutting the state budget - selecting a record from a directory of 13 tons of records 1500 pages ... who needs such nonsense, by the way, slows down 3 seconds for any zilch)
Any choice of more than 10-20 records should be excluded (in fact, you can tolerate 100 ... but more means somewhere they forgot to make it possible to specify the selection criterion), where possible - by introducing categories, and in any case, make a full-text search filter for data with maximum information content about the results.
The choice of address is generally a classic, as soon as the developers do not go out of their way (I myself remember being perverted with a complex active form that changes the filter in the selection fields and their display). Let the full line from the KLADR database be displayed (country, region, district, city/village, street), and the search should be full-text in all fields at once.

Answer 9

The best search I've seen is implemented in the search everything program.