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

[Naked]

Self Author:
что должно лежать на каждой из этих страниц.

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

[Self Author]

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

[Naked]

Self Author:
Такие вещи, как форум, думаю, запаришься переписывать страницы.

такую вещь как форум вообще врядли можно на html переписать

Self Author:
А ещё минус - например, то же меню, в котором графикой или чем ещё выделяется текущий пункт, сложно сделать с помощью SSI.

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

[Псих]

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

[RaZEr]

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

[Псих]

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

[EvroStandart]

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

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

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

[Псих]

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

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

[EvroStandart]

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

[Псих]

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

[EvroStandart]

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

[Self Author]

EvroStandart:
всегда в запросе передаётся только ид текста

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

[EvroStandart]

Self Author:
Только вот никак не решу, что делать с описанием

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

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

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

[Hubbitus]

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

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

Псих:
2. Правильность форматирования текста

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

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

Self Author:

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

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

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

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

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

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

[Self Author]

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

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

[Naked]

Self Author:
Вы ж посмотрите, что выше написано

Naked:
если что-то должно лежать на каждой из этих страниц, то разумно использовать SSI,

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