PHPMySQL: сложный постраничный вывод. Нужен help

[Le docteur]

PHP\MySQL: сложный постраничный вывод. Нужен help

Привет! Скажу сразу - я не программист, в жизни занимаюсь другими вещами. Но для "качания" мозга, изучаю РНР.

Сделать простой постраничный вывод я могу из базы данных простым LIMIT X, 10 к примеру.

А вот как сделать такой сложный вывод? На приложеном файле сгенерированные 2 страница. Вернее как должны генерироваться.

Разные цвета - это разные категории. Номер категории на шарике. Шарик это разные элементы из категории. Количество категорий, элементов в категории - динамическое, т.е. можно менять.

Вопрос вот в чем. Как сделать так, чтоб информация сортировалась на листе с учетом того, что максимальное количество ячеек на 1 страницу - 12 штук.

Если категория занимает все 12 ячеек - оно идет сплошняком. Если категории занимают до 3х (включительно) клеточек, то следующая категория начинается со следующей строки.

Иными словами - каждая новая категория должна начинатся со следующего поля. Все последующие результаты должны смещаться вниз (вправо, как удобнее). На странице 2 видно продолжение.

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


Не сильно запутанно? Мне нужна помощь - как бы это реализовать.
Исходные данные - база данных или один сплошной массив.

 

[dr_mousefly]

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

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

но вообще, это мозгое*ство. переделайте так, чтобы разбивка на страницы не зависела от особенностей отображения.

 

[ESS]

Количество категорий, элементов в категории - динамическое, т.е. можно менять.

"Динамическое" - это сколько?

 

[Le docteur]

от 1 до 30 элементов в каждой категории.

Чтоб не грузить проц я могу все же использовать LIMIT x, 12 для выборки из базы данных. А потом с этим уже работать.

Тут скорее не понимаю логику, чем прошу сделать

 

[dr_mousefly]

Тут скорее не понимаю логику

ну не мы же ее придумали.
Вам разъяснить Вашу же задачу?

Чтоб не грузить проц я могу все же использовать LIMIT x, 12 для выборки из базы данных.

да хрена лысого.
а если из этих 12, скаежем, все в разных категориях, отобразятся только первые 4,
а остальные уедут в сиреневую даль.

 

[ESS]

Я не вижу смысла хранить в отдельной таблице информацию о том, на какой строке должен быть расположен каждый элемент.
Проще и быстрее рассчитать это в рантайме.

 

[dr_mousefly]

Я не вижу смысла хранить в отдельной таблице информацию о том, на какой строке должен быть расположен каждый элемент.
Проще и быстрее рассчитать это в рантайме.

ануко распихать по строчкам три миллиона шариков ради того, чтобы отобразить одну страничку.. ну-ну, веселых гигогерцев)))

тут уже один персонаж вынимает левой рукой 10 миллионов записей за 50 микросекунд, хотя ему нужна всего одна.

 

[ESS]

ануко распихать по строчкам три миллиона шариков ради того, чтобы отобразить одну страничку.. ну-ну, веселых гигогерцев)))

1. Откуда там 3 000 000 шариков? Логика подсказывает, что их может быть от 1 до 900.
2. Даже если их 3 миллиона, самое сложное - достать их из базы данных. Распределение по страницам не займет много времени.
3. Пересчет кэша при добавлении одного шарика и запись всего этого в базу займет гораздо больше времени.

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

Но еще раз повторю. Кэш нужен только тогда, когда он дает заметное повышение производительности. В данном он даст только геморрой.

 

[dr_mousefly]

та ради бога, все равно задачка учебная.
я прост не понимаю, чо ТС от нас хочет.

2. Даже если их 3 миллиона, самое сложное - достать их из базы данных. Распределение по страницам не займет много времени.
3. Пересчет кэша при добавлении одного шарика и запись всего этого в базу займет гораздо больше времени.

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

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

а потом захоца 10 строчек на странице вместо 4, а жопа.

Но еще раз повторю. Кэш нужен только тогда, когда он дает заметное повышение производительности. В данном он даст только геморрой.

причем тут кэш???

 

[ESS]

Вариант разбиения на страницы в псевдокоде:

categories = "SELECT Category, COUNT(*) AS "ElementCount" FROM Elements GROUP BY Category ORDER BY Category;"

freeLinesOnCurrentPage = 0;
currentElementIndex = 0;

foreach (category in categories)
{
    int elementsLeft = category.ElementCount;

    while (elementsLeft > 0)
    {
        if (freeLinesOnCurrentPage < 1)
        {
            Pages.AddNew();
            Pages.Last.FirstElementIndex = currentElementIndex;
            freeLinesOnCurrentPage = linesPerPage;
        }

        {
            int elementsPerCurrentLine = min(elementsPerLine, elementsLeft);
            --freeLinesOnCurrentPage;
            elementsLeft -= elementsPerCurrentLine 
            currentElementIndex += elementsPerCurrentLine 
        }
    }
}

Сразу оговорюсь, что написан он за несколько минут и ни о какой оптимальности и т.п. не может быть и речи.
Просто примитивный вариант реализации.

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

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

а потом захоца 10 строчек на странице вместо 4, а жопа.

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

причем тут кэш???

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

 

[dr_mousefly]

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

ну и? один запрос.

А потом нам захочется 10 строчек и 8 столбцов, и в результате выйдет все та же жопа.

не жопа. взяли пересчитали ОДИН РАЗ и пользуемся дальше.
а не каждый раз когда страничку показать надо.

но ТС оно пофиг, ему хоть как-то.

 

[Therion]

Курсорами можно... вроде бы.

 

[dr_mousefly]

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

собственное уникальное определение.
Селко перевернется в гробу, узнав что его деревья стали "кэшем".

 

[ESS]

dr_mousefly, ссылки на педивикию хватит, или другую найти?

 

[dr_mousefly]

dr_mousefly, ссылки на педивикию хватит, или другую найти?

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

 

[ESS]

та да, прочтите то что по ссылке хотя бы.

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

У нас разве не то же самое?

идите и больше не путайте кэш с избыточными данными.

Обычно "избыточными данными" называют несколько иное...

 

[dr_mousefly]

У нас разве не то же самое?

неа. и индексирование БД там совсем не в тему.

Обычно "избыточными данными" называют несколько иное...

не такое?

 

[ESS]

неа. и индексирование БД там совсем не в тему.

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

не такое?

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

 

[dr_mousefly]

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

так она еще и модифицируется при изменении основной информации. а кэш не модифицируется, он тока сбрасывается и обновляется. в этом и разница.

Когда клиент кэша (ЦПУ, веб-браузер, операционная система) обращается к данным, прежде всего исследуется кэш. Если в кэше найдена запись с идентификатором, совпадающим с идентификатором затребованного элемента данных, то используются элементы данных в кэше. Такой случай называется попаданием кэша. Если в кэше не найдена запись, содержащая затребованный элемент данных, то он читается из основной памяти в кэш, и становится доступным для последующих обращений. Такой случай называется промахом кэша. Процент обращений к кэшу, когда в нём найден результат, называется уровнем попаданий или коэффициентом попаданий в кэш.

чукча не читатель?

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

та здрасьте. это данные восстановления. вот тебе и "обычно":

The denormalized or redundant data must be carefully controlled during extract, transform, load (ETL) processing, and users should not be permitted to see the data until it is in a consistent state.

https://en.wikipedia.org/wiki/Database_normalization

 

[ESS]

так она еще и модифицируется при изменении основной информации. а кэш не модифицируется, он тока сбрасывается и обновляется. в этом и разница.

Стирается и пересчитывается с нуля или просто обновляется - это не принципиально.

чукча не читатель?

Ну и к чему это?

та здрасьте. это данные восстановления. вот тебе и "обычно":

Так они названы только в

Тільки зареєстровані користувачі бачать весь контент у цьому розділі

,

Тільки зареєстровані користувачі бачать весь контент у цьому розділі

.