Дайте совет по организации сайта, использовать MySQL для статей?

WebPHPDev

Новичок
Дайте совет по организации сайта, использовать MySQL для статей?

Планируется сайт с огромным количеством статей (счёт идёт на сотни тысяч).
Вопрос в том где эффективнее и продуктивнее хранить тексты статей.
"По старинке" я делал это в отдельной папке (там структура по директориям), как надо отобразить статью делаю что-то типа:
Код:
$body = file_get_contents ( 'folder/.../nuzhaya-statiya.html' );
echo HTMLDesign ( $body );
и вывожу статью. Вот и думаю, а насколько "гиблая" такая архитектура сайта?

Может быть имеет смысл полное содержание статей хранить в MySQL? Но не будет ли тормозить база данных из-за таких объемов данных?
Если одна статья занимает под 30-60 кб умножив на 100 тысяч статей это уже весомо получится для БД.
Либо в БД хранить только ссылку на ту же "folder/.../nuzhaya-statiya.html" и не хранить сам контент..

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

Спасибо большое за внимание.
 

WebPHPDev

Новичок
Спасибо за ответы!

Alexandre
Всмысле виртуальные пути? Т.е. хранить поле с путем типа: "folder/.../nuzhaya-statiya.html", а физически файл держать на файловой системе в виде отдельного файла?
Или ты просто о ModRewrite?

Фанат
Почему всё равно? А время затрачиваемое на постоянное обращение к файловой системе? В БД это всё же оптимизировано..
 

Фанат

oncle terrible
Команда форума
А файловую систему, по-твоему, криворукие дауны писали?
 

WebPHPDev

Новичок
Фанат
Получается, если содержание статей будет находиться целиком в БД то преимуществ никаких не будет?
 

Фанат

oncle terrible
Команда форума
Ты такого вопроса НЕ ЗАДАВАЛ.
Ты спрашивал - "где эффективнее и продуктивнее".
С точки зрения эффективности и продуктивности там настолько нет никакой разницы, что заметить её невозможно.

База данных не для того придумана, чтобы обогнать файловую систему в 10 раз. А для удобства.

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

А в том вопросе, который ты задал - откуда дергать удобнее - смысла ноль. Особенно - в плане "оптимизации". Самый дурацкий вопрос
 

WebPHPDev

Новичок
Фанат
Спасибо большое за развёрнутый ответ!
Решено делать это всё в БД. Вопрос снят.

-~{}~ 05.04.07 21:52:

Ещё вопрос параллельный появился.. А вот скажите пожалуйста, а по нагрузке на сервер какой вариант будет менее грузным?
Мне почему-то кажется, что вариант с БД будет грузить сервер сильнее. Поскольку размер статей большой, БД следит за всякими ключами, структурами, да и так как размер статей велик, то делать мускулу это будет сложнее и сложнее по мере нарастания статей.. А вариант с хранением файлов на файловой системе в открытом виде (понимаю, что и БД хранит на ФС инфу), да ещё если категоризировать по папкам вида: "data/год/месяц/article.html" будет гораздо меньше давать нагрузки при работе..(отображении)

Что думаете по этому поводу?
Хостер ругается за чрезмерную нагрузку на сервер, хочется оптимизировать всё же как-то свои скрипты. Вот и начинаешь перебирать варианты, в том числе и такие..
 

wi

Новичок
Я больше склоняюсь к полному контенту в БД. MySQL тоже жалко, но, думаю, если через пару дней к двум строкам кода появится еще что-то вроде поиска, сортировки или т.п., с файлами хостер точно злиться будет. Так что мой +1 к БД.
Так, например, Найти максимальное число намного быстрее, сделав конкретный запрос к mysql, нежели сортировать все подряд средствами php.
 

WebPHPDev

Новичок
Хм, поиск по контенту статей не учёл, действительно здесь выигрыш несомненно будет. Переоткрывать все файлы поочерёдке на ФС это неблагодарное дело, согласен.

А ещё какие мнения у кого-нибудь будут?

-~{}~ 06.04.07 20:47:

кстати, уточню, что я имею ввиду вариант полностью в MySQL или НЕ_ПОЛНОСТЬЮ. То бишь второй вариант тоже с использованием MySQL, но там будут только заголовки и поле типа:
"data/год/месяц/article.html"
что указывает на место хранения статьи.

Т.е. если находить какое-то максимальное число ( правда не понял какое именно :) ) то возможно и средствами MySQL получится это сделать..

Здесь даже упор делается именно на более низку нагрузку на сервер, нежели на удобство хранение статей админом/модером..
 

Фанат

oncle terrible
Команда форума
Делай уже в базе, и не парь себе мозги.
Два месяца прошло, а ты все никак не определишься?
 

WebPHPDev

Новичок
:)
Я сделал в базе, но если снизит нагрузку содержание контента не в базе - то я в миг всё перелопачу :)
Поэтому и спрашиваю в каком варианте она будет ниже..
Тем более скрипт экспортирующий статьи из базы на ФС уже написан.. в качестве развлечения от нечего делать :)
 

Фанат

oncle terrible
Команда форума
А что - проблемы с нагрузкой?

-~{}~ 06.04.07 21:41:

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

dark-demon

d(^-^)b
WebPHPDev, всякие учёты просмотра и тп вовсе не требуют присутствия текста статьи в самой бд. а для полнотекстового поиска лучше организовать специальный индекс. так что опать - где хранить саму статью - без разницы :) впрочем, в данном случае я сторонних файлов, ибо нефиг захламлять БД.
 

WebPHPDev

Новичок
всякие учёты просмотра и тп вовсе не требуют присутствия текста статьи в самой бд.
да, я как раз о том же.

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

Видимо, чтобы хранить текст статей в БД то они явно должны быть в отдельной таблице? т.е. не вместе с полями заголовков, просмотров и т.д.
 
Сверху