- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Пишется небольшой движок для сайтов. Никаких особых примочек нет. Только постраничный вывод статей из базы. Соответственно вопрос: целесообразно ли использовать MySQL для моих целей?
Ведь, того же самого функционала можно добиться с помощью обычных файлов. Еще очень важно, что из этого будет быстрее (время выполнения скрипта, при больших нагрузках) и надежнее (не падать от количества обращений) – файлы или мускул?
На каждом сайте будет порядка 10к-30к страниц.
в вашем случае мускул - явно лишнее.
вопрос только в том как вы будете готовить эти 10к-30к страниц (мускул тут ни при чём.)
З.Ы. Поясню: мускул - это среднее звено между файловым хранилищем вебсервера и отдаваемым клиенту html'ем.
мускул нужен тогда, когда необходимо вести базу данных (тут можно много говорить зачем это нужно...).
Спасибо, тоесть для меня получается хранить данные в файлах идеальный вариант? Какие-нибудь еще варианты имеются?
Это все продумано. Как раз вот встал вопрос в хранении таких количеств страниц.
del.......
Как раз вот встал вопрос в хранении таких количеств страниц.
в чем вопрос-то? раскидать по каталогам... и делов-то... по 100-200 страниц на каталог...
/topic1/glava1/
/topic1/glava1/page1.htm
/topic1/glava1/page2.htm
...
/topic1/glava1/pageN.htm
/topic1/glava2/
...
/topic1/glavaN/
...
/topic2/glava1/
/topic2/glava2/
...
/topic2/glavaN/
идеальный вариант? Какие-нибудь еще варианты имеются?
Вас не устраивает идеальный вариант? ;)
Ну, если хотите, то можно все 10К-30К страниц хранить в файле ворда на хостинге и оттуда изымать в html при каждом обращении пользователя... :)
или Вам нужен WP, Joomla или другая нынче модная у школьников хрень?
даже динамический сайт с кучей журналюг, постящих каждую минуту свои статейки на сайт можно реализовать без мускула, а, например, с помощью php, cgi, Perl и т.д. ... но это тема отдельного разговора...
Нет-нет, я не это имел в виду. Можно же все хранить в базе мускула. Ну и скриптом оттуда вытаскивать в зависимости от параметров.
А можно хранить в файлах и также скриптом оттуда вытаскивать. Вот и выбирал между ними. Ладно, спасибо за помощь.
хранить в файлах и также скриптом оттуда вытаскивать
а зачем тут скрипт? скрипт может быть нужен только чтобы положить в файл, а сам файл-то - page.html при наличии ссылки на него уже будет сам работать...
небольшой тест:
публикация страниц будет каждую минуту?
нет? - вам не нужна база данных
публикуемая страница будет проходить на проверку валидности, орфографии, наличие/отсутствия чего-то в ней?
нет? - вам не нужен серверный скрипт (php, perl и т.д.).
Итог: если сайт типа - залил и забыл (иногда поправил) - не нужно ни MySQL, ни php (и аналоги). Этим достигается надежность и быстродействие.
При этом используется http: ftp: html SSI. Всё.
10-30k страниц сейчас
потом захочется добавить метки (tags) или еще какую плюшку
перелопачивать 10-30k файлов, мягко говоря, не удобно (ИМХО)
бэкапить mysql базу, опять таки ИМХО, значительно удобнее и проще (нет гемора с правами на запись и листинг директории с большим кол-вом файлом иногда :) штука неприятная, да и целостность бэкапа большого кол-ва файлов не всегда гарантируется)
решение: пользовать mysql для удобства и надежности
пользовать файловое кеширование для увеличения производительности (если будет не хватать - копать в сторону memcached)
перелопачивать 10-30k файлов, мягко говоря, не удобно
конечно! но для этого не нужен MySQL или php, и они не помогут.
достаточно предусмотреть в шаблонах html и в содержании страниц такую возможность. А реализуется она с помощью SSI (.shtml). Правда именно тут можно использовать php.
целостность бэкапа большого кол-ва файлов не всегда гарантируется
она гарантируется автором - на своём HDD и т.д.
пользовать файловое кеширование для увеличения производительности
кешировать страницу page.html ? 😮 (вообще-то зачем? и броузер это делает и хостинг...)
хороший хостер это гарантирует, а если это не работает у других - надо менять хостинг, но я таких сегодня не представляю... ну если только домашний хостинг...
Кстати, напоминаю, ТС спрашивал, что надежнее и быстрее.
Что может быть надежнее и быстрее голого html от вебсервера хостинга к броузеру пользователя?
Только мысль... :) или почта России? :) DHL? Western Union? :D
достаточно предусмотреть в шаблонах html и в содержании страниц такую возможность. А реализуется она с помощью SSI (.shtml). Правда именно тут можно использовать php.
как Вы с помощью ssi найдете ключевые слова в статьях и присвоите статье, на основе этих ключевых слов, определенный тег?
моя практика показывает, что качание большого кол-ва файлов по ftp на винт может сопровождаться сбоем процесса и в следствии этого какой-то файл (если сбоев несколько, то следовательно несколько файлов) будет битым (докачка не всегда срабатывает как ожидается)
+ если на файле стоит право на запись, то скачав по ftp этот файл себе на win машину, вы это право потрете (в винде автоматом будет право на запись, а вот если закачивать этот файл на новый хостинг, то прийдется заново ставить право на запись ибо по дефолту будет "только чтение")
хороший хостер это гарантирует, а если это не работает у других - надо менять хостинг, но я таких сегодня не представляю... ну если только домашний хостинг...
кешировать результаты выполнения скрипта (php, perl), запросов к БД (запросили у mysql текст статьи, автора и прочие данные - сформировали блок "статья" - сохранили в файл, при повторном запросе страницы с этой статьей - берете данные из сформированного (кешируемого в файл) блока, а не заново мучаете mysql)
как Вы с помощью ssi найдете ключевые слова в статьях и присвоите статье, на основе этих ключевых слов, определенный тег?
я поэтому и сказал: php (но в случае ТС этого, похоже, не надо)
скачав по ftp этот файл себе на win машину, вы это право потрете (в винде автоматом будет право на запись, а вот если закачивать этот файл на новый хостинг, то прийдется заново ставить право на запись ибо по дефолту будет "только чтение")
я с таким не встречался, и не думаю, что это частая ситуация
и зачем page.html какие-то недефолтные права?
кешировать результаты выполнения скрипта (php, perl), запросов к БД (запросили у mysql текст статьи, автора и прочие данные - сформировали блок "статья" - сохранили в файл, при повторном запросе страницы с этой статьей - берете данные из сформированного (кешируемого в файл) блока, а не заново мучаете mysql)
к чему это всё? (всё это обеспечивается хостингом, цепочкой прокси-серверов от хостинга к клиенту, броузером)
если у ТСа просто голые html страницы?
какое кеширование запросов? у него же не форекс!
а не заново мучаете mysql
я и говорю - mysql нам не нужен... как и скрипач в Кин-Дза-дза...:)
mysql автоматом тэги тоже не сформирует - для этого нужны некие действия..., которые при начальном планировании можно предусмотреть и на уровне html и php.
Mitos, я рассуждаю в пределах поставленной ТС задачи... вообще - может быть куча вариантов...