Хранения текста в базе
 

Сразу извиняюсь, если вопрос уже обсуждался.
Я столкнулся с необходимостью реализации хранения больших объемов в базе.
Грубо говоря html + текст.
Вопрос.. из вашего опыта, как лучше это все хранить...
Просто загнать все в text ячейку?
Видимые для меня проблемы:
1. Скорость загрузки далека от идеала(сравнительно со статическим html)
2. Правильность форматирования текста
3. Разбитие на страницы

Заранее благодарен!

Воевать за каждую миллисекунду нужно только когда у тебя проект с посещаемостью не менее 10К. В остальных случаях это изобретение велосипеда.
А каким образом хранение в БД может этому помешать?
Проще всего хранить уже в разбитом виде. А разбивать лучше всего руками.

Просто я замечаю, что на диалапе тяжеловато текст большой из базы берется!
И без 10к посетителей!

Так скорее виноват диалап

я имел ввиду по отношению к загрузке той же страницы локально!

локально, - это с того же сервера но в html?

тьфу. этож надо было такое сморознуть.
Я имел ввиду:
Берется страница статическая с этим же текстом
и берется динамическая , которая берет этот текст из базы!

И сравнивается.
так вот статическая быстрее грузится!

Возможно. Причины тому разные. Если условиться что динамику и статику отдаёт один и тот же сервер без каких-либо лишних наворотов, то самое вероятное: тормозит сервер БД. Нет, я не отрицаю - passthru() быстрее mysql_query(), но не настолько, чтобы это ощущалось визуально.

RaZEr
Я не имел ввиду под статической страницей использование passthru.
Имел ввиду просто *.html страницу
А это не зависит от размера текста в базе?

Конечно зависит. В твоём случае когда сервер отдаёт тебе простой html файл, ему ненадо запускать жирный php со всеми модулями.

По сути ненадо хранить тексты в базе, если нет ответа на вопрос - "зачем это надо?"

Во-первых, диалап тут совершенно не при чём. Диалап тормозит, когда страница уже готова для получения, а её никак не могут получить. А разница html или сгенерированная страница - это ощущается ещё до того, как она начинает получаться.
Вообще, конечно, апач отдаёт тексты быстрее, чем мускул. Но это зависит от:
1. Загруженности мускула
2. Оптимизации БД.
У меня вот тексты хранятся в базе. И текстов уже почти 1500. Всего база около 5М. Есть там и таблицы, в которых до 100000 строк...
Дело в том, что большие тексты надо выделять в отдельные таблицы с двумя полями: id и text. Причём id сделать первичным индексом и выбирать из этой таблицы только одну запись по этому индексу. А все остальные параметры, которые не занимают много места, отложить в другую таблицу и уже по ней делать различные выборки и т.п.

Какие по вашему тексты называются большими?

RaZEr
Зачем надо.. вот тут подходим к ключевому вопросу....
чтобы потом можно было поиск осуществлять

да и просто, чтобы интерактивность обеспечить...

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

а не проще ли тогда воспользоваться каким-нибудь индексером (поисковиком)? Ну не верю я что для ПХП не бывает поисковиков, которые могут строить индексы для поиска по текстовым файлам и по данным в БД. Все равно с большим текстом like будет медленно работать, а нормальный поисковик ощутимо быстрее... Вот, к примеру, поисковик для С, авось для ПХП похожее что-нить есть... http://incubator.apache.org/lucene4c/

Которые больше 256 символов. То есть именно тексты а не надписи. У меня сделано примерно также, как у Self Author. Есть куча таблиц со всякими полями типа CHAR(80) и есть одна таблица в которой тексты типа MEDIUMTEXT. Один текст используется для заполнения одной страницы. Соответственно я каждый раз выбираю по порядковому номеру только один текст. И всё летает.

Посыпаю голову пеплом...
Это я только решил так сделать. :) А всё никак не сделаю. Вот и ворочается еле-еле. Аж посетителей жалко...

если я не ошибаюсь, это обычная теория нормализации

Ж?пой чую что многие её незнают :cool:

Скажу как делаю я - составляю таблицу из двух полей id | text , возможно бывает и больше, например третье поле, где хранится стиль для этого текста, кстати, можно сделать еще четвертое поле с ключевыми словами (надо только чтб их было немного). Потом просто выбираю по id, иногда на id ставлю индекс - это увеличивает соответственно скорость select'a но сильно уменьшает скорость insert'а здесь нужно выбирать (причем это достаточно хорошо видно). поиск выбираю регулярным выражением (в мускуле это видимо LIKE, в посгресе я делаю просто ~), оно делается для конечного пользователя практически моментально, ибо оно на то и регулярное выражение. Безусловно нужно для каждой отдельной страницы делать свою запись в таблице, а еще лучше разбивать вообще весь контент просто логически, т.к. в данном случае чем больше разобьешь, тем быстрее будет работать (но это только в данном случае, т.к. даже логических блоков, скорее всего не много - <1000). Что касается скорости, то статика будет быстрее это точно, но скорость торможения на динамике зависит (и это 99% от всего торможения) от коннекта к самой базе (а базы, особенно у хостингов, а не у выделенных серваков слегка тормозят - отсюда и визуальное торможение), т.к. сам запрос на хорошем серваке - просто не заметно. А вообще для этого
и не только могу предложить следующий способ (так делал один из сайтов): весь текст страниц хранится в базе, через админ панель ты его изменяешь, а сами страницы - статика, просто в админке делаешь кнопку - "Обновить на сайте" и при этом все данные из базы перегоняются в статику - в итоге админ панель удобная и конечному пользователю вываливается быстрая статика;)

У меня на сайте 3000 страниц (по мнению Яндекса). И мне нужно добавить какой-нибудь пункт меню или ещё что-нибудь, что должно лежать на каждой из этих страниц. Сколько же времени скрипт будет переписывать эти 3000 файлов?

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

Ой... Сложно всё... Куча плюсов и куча минусов.
Среди минусов, например, интерактив. Такие вещи, как форум, думаю, запаришься переписывать страницы.
А ещё минус - например, то же меню, в котором графикой или чем ещё выделяется текущий пункт, сложно сделать с помощью SSI.

такую вещь как форум вообще врядли можно на html переписать;)
делается элементарно - это реализуется в админ панели, а страницы у тебя html просто....т.е. в ней в самой и прописывается что и каким цветом выделять..
Вообще здесь просто нужно определится сколько будет пользователей и стоит ли тратить кучу времени на переделывание php->html для увеличения скорости, или это будет даже незаметно....:)

Хорошо, а никто не смотрел, как происходит хранение страниц в движках типа LDU или там phpnuke?

Хорошая идея!... посмотреть как сделано в phpnuke, и сделать наоборот :)

RaZEr
((:
Я конечно понимаю, что все так плохо... Но меня интересует сама идея... а не реализация (:

Я не разбирал никаких известных движков, но вообще сейчас всё серьёзные работы делаются через шаблоны и модули. Когда я писАл что храню текст в отдельной таблице, я имел в виду именно текстовую инфу с минимальным форматированием типа <BR> <B> <IMG> <A>. Этот текст просто передаётся шаблону также, как пункты меню и может быть ещё какие-то мелочи.
В зависимости от структуры системы её стараются делить на модули чтобы потом можно было решать подгружать модуль какой-нибудь "шапки" или нет. Соответственно каждому модулю можно делать свой шаблон.
В такой системе грузится всегда один скрипт и по каким-нибудь нескольким(или одной) переменным решает какую инфу показать.

Вот собственно сама идея. Реализуется практически везде через ООП.

А если оперировать целыми хтмл страницами - там никакой гибкости или структуры не получается.

Если я тебя правильно понял, то ты говоришь про то, что не правильно хранить в базе полноценную html страницу..

В общем-то про страницу никто не говорил.. говорилось про текст c html форматированием!

Ну, про полноценную страницу - это было сказано для количества. А общая идея такая как я написал. Более конкретно можно говорить только относительно конкретной системы. Нет смысла изучать какой-нибудь phpnuke если нужно построить сайт с другой структурой. Оптимальную програмную логику нужно придумывать под конкретные требования. :)

EvroStandart
Я так понимаю, что лучше всего хранить с текстом параметр типа style, а потом в зависимости от этого style уже подключать шаблон

Это зависит от структуры и конкретных требований.
Я, на пример, делал сайт с четырьмя шаблонами (главная страница + три раздела). В каждом разделе меню с тремя уровнями вложенности, на каждом уровне сколько-то текстов. Тогда я сделал объект "раздел" и туда прописал шаблон. А всем текстам прописал ид "верхнего текста", который в меню на ступеньку выше. Получилось древовидная структура с текстами. У самого верхнего текста прописан ид раздела. Тогда от любого текста можно пойти по дереву наверх и получить настройки раздела.
При этом я получил ещё одну выгоду: всегда в запросе передаётся только ид текста, а скрипт уже сам вычисляет какие ступеньки в меню нужно развернуть.
При изменении одной насройки меняется дизайн сразу всего раздела. Но это естественно оптимальное решение для той конкретной задачи...

Я тоже так делаю: http://www.kordon-rnd.ru/equipment/?id=140
Только вот никак не решу, что делать с описанием в листьях дерева: оно такое разношёрстное. Пока храню в БД весь кусок html...

Если для каждого пункта описания делать отдельную запись, тогда сразу напрашиваются два варианта:

1) отдельная таблица каждому типу товаров

2) сделать для описаний отдельную таблицу и выбирать поля где товар_ид соответствует выбранному товару. Можно пойти дальше и добавить имя_параметра_ид, который показывает на таблицу с именами параметров ("Процессор"; "Набор микросхем"; ... )

Вставлю свои пять копеек:
1. При нормальной форме хранения (нормализацию тут уже затронули, и примеры таблиц даже приводили) чтение текста из БД, с выборкой по первичному уникальному индексу, не должно быть медленнее чтения статического файла тем же ПХП в общем случае. При условии конечно не чрезмерной перегруженности СУБД.

Как правильно сказал RaZEr, отдача той же страницы на ПХП вообще медленнее чем просто статический файл html, поскольку сам ПХП тоже занимает какие-то ресурсы и требует время процессора и памяти, даже без использования БД.


Вот это не понял, мы говорим о каком-то форматировании или обработки текста, или о его хранении в той или иной форме?

2. Если скорость так уж важна и критична, то есть вариант просто кешировать контент, особенно если он малодинамичен. Об этом уже говорил Naked.


А зачем собственно переписывать все файлы? Достаточно переписать только один файл, текст которого только что изменили в админке.

Подобным образом, в смысле кеширования, работают и многие шаблонизаторы, например Smarty тотже.

Отсюда вывод я бы сделал такой (как в самом начале писал еще RaZEr) что когда не слишком интенсивно используется, можно не слишком и задумываться об оптимизации.

Однако, кеширование, самое простое, без изощрений, можно сделать для основного контента весьма просто и быстро, а то что просто не поддается кешированию, то что более динамично, можно уже задумываться позже.
Таким образом, если СуБД не является крайне перегруженной, то хранение в ней кусков текста в поле text я считаю весьма нормальным решением, естественно соблюдая здравый смысл в этом и в использовании.

Ну и еще один, возможно главный вопрос: А если работало все на статических файлах, может и не надо вовсе использовать БД? Тоесть для чего запизивать все в БД нужно решить сначала. Если поиск (как уже писалось в пример), то может и стоит в общем случае, если планируется создавать полнотекстовый индекс по этим полям и осуществлять поиск средствами СУБД. А если будет использоваться какой-то собственный алгоритм индексации, то как правильно было замечено, результаты индексации можно хранить в БД и независимо от самих текстов.

Вы ж посмотрите, что выше написано: "И мне нужно добавить какой-нибудь пункт меню или ещё что-нибудь, что должно лежать на каждой из этих страниц".

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