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

Le docteur · 28.10.2010

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

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

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

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

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

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

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

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

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

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

dr_mousefly · 28.10.2010

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

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

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

ESS · 28.10.2010

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

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

Le docteur · 28.10.2010

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

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

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

dr_mousefly · 28.10.2010

Le docteur сказав(ла):
Тут скорее не понимаю логику

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

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

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

ESS · 28.10.2010

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

dr_mousefly · 28.10.2010

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

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

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

ESS · 28.10.2010

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

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

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

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

dr_mousefly · 28.10.2010

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

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

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

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

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

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

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

ESS · 28.10.2010

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

Код:

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 · 29.10.2010

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

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

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

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

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

Therion · 29.10.2010

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

dr_mousefly · 29.10.2010

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

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

ESS · 29.10.2010

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

dr_mousefly · 29.10.2010

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

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

ESS · 29.10.2010

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

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

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

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

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

dr_mousefly · 29.10.2010

ESS сказав(ла):
У нас разве не то же самое?

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

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

не такое?

ESS · 29.10.2010

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

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

не такое?

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

dr_mousefly · 29.10.2010

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

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

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

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

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

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

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 · 30.10.2010

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

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

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

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

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

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

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

,

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

.

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

Вкладення