Есть денные (текст) большого объёма (например книга). Вывести разом все данные на страницу было бы не красиво. Напротив, замечательно было бы вывести это именно "постранично" как в реальной книге. Рыл статьи на эту тему, но во всех метериалах предполагается вывод записей из БД с указанием LIMIT, ждесь же в безе кранятся не страницы, а книги целиком. Ни о каком лимите записей разумеется речи не идёт. Собственно попрос: как организовать базу и взаимодействие с ней, чтобы можно было осуществить указанный постраничный вывод и разделение на главы и страницы?
Может это укажет путь? Код (Text): $num = 10; // Число записей всего. $perpage = 7; // Кол-во, показываемых записей на странице. $pages_count = @ceil($num/$perpage); $pages .= 'Страницы:'; for($j=1;$j<=$pages_count;$j++) { if ($_GET['page'] != $j) { $pages .= ' <a href="?page='.$j.'"><b>'.$j.'</b></a> '; } else { $pages .= ' <b>'.$j.'</b> '; } }
Это не очень хорошо, потому что при выборке каждой страницы вы будете получать всю книгу заново из базы - ее надо либо хранить в файле по которому перемещатся через fseek(), либо в базе хранить главы, страницы.
Хм... Да проблема не в том, чтобы вырвать какой-то кусок из базы и его показать - нужно веть выдрать правильно, без разрыва слов, а ещё лучше - не разрывая предложение или абзац. Вот именно решения этой задачи я примеров не встретил. Хм.... Ну а предположим, что книга хранится в базе таким образом, что главы и страницы - это отдельные записи, как тогда эффективнее организовать структуру такой базы? Я это что-то не представлю. Создать таблицу книг, таблицу глав и таблицу страниц.... Не бред ли получится? Как лучше это сделать? Какие-то идеи есть?
Но тогда если на книжку в среднем будет около 800 записей в таблице страниц... Разумно ли это вообще? Да и заполнение... как его тогда организовать?
моя принципиальная позиция заключается в том, что вся "красота" разбивки на сервере заключается в возможности показать побольше баннеров. А пользователю, как раз, удобно и красиво скачать всё одним файлом и читать так, как ему удобнее.
Хм... Ну это уже Off Так всё-же, эффективно это или нет? Насколько ресурсоёмка для сервера база с такой структурой? Речь ведь идёт о сотнях тысяч страниц...
Хм... Что ж, если так... Так и поступлю. Буду кромсать на страницы и забивать в базу. В таком случае какая логическая схема эффективна? Три таблицы: КНИГИ, ГЛАВЫ, СТРАНИЦЫ. Таблица КНИГИ хранит описания книг и список всех страниц и всех глав (их id) Таблица ГЛАВЫ хранит описания глав, со списками входящих страниц и принадлежность книге. Таблица СТРАНИЦЫ хранит сами страницы в указанием id книги и главы. Так, или есть какой-то лучший вариант?
Книги хранят данные о книге + ID книги Главы хранят данные о главах + ID книги, к которой принадлежат Страницы хранят текст с указанием ID главы. + возможно, книги, но необязательно.
Хм... А в случае, если нужно вывести содержание например? Эффективнее в таком случае делать выборку из таблицы страниц тех страниц, которые ссылаются на главу или книгу? То есть, если я правильно понимаю, суть идеи в том, что записи дочерней таблицы ссылаются на запись в родительской, а в родительской эта информация не дублируется, верно понимаю? И запись страницы содержит поле со ссылкой и на id главы, и на id книги?
а почему все не хранить в одной таблице? напрм, такой: ID - primary_key book_ID - ID книги tom_ID - ID тома glava_ID - ID главы text - текст. напрм, SELECT text FROM db - вся книга SELECT text FROM db WHERE glava_ID LIKE '$glava' SELECT glava_ID FROM db (для оглавления по главам) и т.п.?
DarkElf, зато я не понял. А зачем нам трактор? Можно и на танке поля пахать! Если интересно - почему - читай теорию РСУБД.
=))) Реляционная система управления базами данных у меня две книги-кирпичи лежат ,,, одна из них - это введение,,,, почитать чтоли )))
Горбунов Олег У меня книги по всем СУБД ... кстати правильно говорить не РСУБД , а СУРБД Система управления реляционными базами данных =) реляционные базы данных - это одна из разновидностей бд... самая распространённая... есть ещё иерархические , объектно-ориентированные , ещё какие-то )