Время доброго. Вопрос: как лучше хранить текст книг (пьесы драматурга, по 50-200 А4 листов 12 шрифтом)? Задача: вывод текста пьесы для чтения, с разбивкой на страницы (1-2 А4 на страницу). Что продуктивней: хранить текст в базе или в файлах? При этом: 1) Хранить каждую страницу текста в отдельной(ом) ячейке(файле). 2) Хранить весь текст в одной(ом) ячейке(файле). Т.е. для каждой страницы будет происходить чтение всего текста, разбивка на страницы, и только потом вывод необходимой страницы.
Два файла для каждой книги: в одном - текст, в другом - сигнатура, с какого по какой байт идут главы.
Мы храним книги в одном файле. Разбивка на страницы - дополнительная разметка типа <span class="page">3</span>. Большие книги грузятся долго, но вполне терпимо.
Ну если не критично каждый раз грузить весь текст страницы...Хотя в этом случае переход по страницам можно сделать через js. А как вариант от [vs], во второй файл: имхо, наиболее подходящий. А если данные о файле считываются из базы, то данные второго файла можно так же в базе хранить.
igordata Для меня оба не составляют большой разности в сложности реализации. Вопрос в том, как из вариантов будет наиболее лучшем для производительности работы сайта и меньше нагружать сервер?
zvenophp Не знаю как там PDF, но мне HTML'ем проще текст разметить, и всякие JavaScript красивости прикрутить. igordata А то что тексты от БД в PHP будут бегать это ничего?
igordata В смысле? Вот я и интересуюсь разве хранение текстов в БД на производительность и нагрузку не скажется резко отрицательно?
по сравнению с ковырянием в файлах? =) нед. я вобще не понимаю о чем вы говорите. или самописный скриптовый движек "БД на файлах" даст прикурить специализированному компилированному движку, писаному весьма таланливыми ребятами? или я просто не понимаю о чем вы.
Тексты в файлах. Мета информация в БД. Итог: не гоняем мегабайты(а при хорошей посещаемости гигабайты) от СУБД к PHP.
zvenophp Не-не, PDF идеален для варианта "скачать документ". Т.к. универсален в отображение контента, бесплатен, да и с минимальной защитой документа от вороства. С нормальной инструкцией как скачать и поставить A-Reader, имхо, это лучший вариант для размещения текстовых документов для скачивания: книг, статей, пьес, сцинариев и т.д. публицистики. (если же конечно txt не подходит). Я же разбираюсь как лучше хранить контент документа, что бы выводить на страницу для чтения. Вижу мнения разделились....
Volt(220) igordata Значит надо тестить.... Вычислить время выполнения - легко. А как вычислить нагрузку на сервер? На localhost (денвер) или же на вирт-хост?
Кеглем. Шрифты разные бывают, а их размер - кегль, то есть размер высоты буквы. По поводу самого вопроса. Надо лишь "примерить" кол-во символов на страницу. Затем: 1. получить текущие кол-во байт (символов, что на страницу); 2. получить размер файла; 3. поделить п.1 на п.2 и так получить общее кол-во страниц книги; 4. переключая страницы умножать текущую страницу на п.1, тем самым срезая лишние куски файла. Просто. Быстро. Пенисы.
lexa "Кегель", да верно. Дело в том, что такой метод разделения страницы может сделать "разрез" как раз на какой-нить хитроумной разметке страницы, например таблицы с картинками и т.д. мелочью. В этом случае есть много шансоф, что "разрезаный" кусок " поплывет". Поэтому, хранение конкретных значений батов начала и конца каждой страницы, имхо, лучше.
Не. Представь - чтобы выбрать часть текста (одну главу) из поля БД, надо будет прогонять его функцией substring, которая к тому же считает не байты, а символы. Потом эти данные должны быть переданы с сокета на сокет, распарсены, и выделены из реузльтата запроса. Прямое чтение с файла должно быть быстрее.
Что касается построчного чтения файла, то работал я с этим, работал. Правда у меня не было два разных файла, а лишь один, размером в 1.37Гб Два байта в начале файла указывали на размер мета-информации, сама мета-информация содержала данные о размерах блоков. К сожалению они были абсолютно нелинейными и непоследовательными, поэтому задача усложнялась. Но, не смотря на это, работа с файлами была очень-очень быстрой. Про чтении без смещения, т.е построчном выплевывании в поток (без fseek) было очень быстро, если мы не использовали никаких промежуточных этапов. Блоки, кстати, представляли собой чистое изображение (т.е только значащие байты) формата JPEG без меток. Поэтому при получении нужно было ещё и делать из него нормальное изображение, дописывая байты и нормализуя формат. В некоторых случаях мы встречали такие блоки, в которых были только измененные байты изображения, а верхние брались из другого блока. Так что работа с файлами - очень быстрое решение, хотя бы из-за возможности низкоуровневой работы с ними. Можно написать экстернальное приложение на С++, которое выполнять через exec
Самописный движок "БД на файлах", думаный и точенный под конкретную задачу вполне возможно даст прикурить компилированному движку "общего назначения" писанному весьма талантливыми ребятами.
Благодарю Всех. Как доберусь до релизации этой задачи - протестю оба варианта и напишу о результатах. 1. Хранение текста в БД. 2. Хранение текста в файле. Инфо о страницах будет хранится в БД.