Спустя 3 минуты, 5 секунд (28.01.2009 - 00:46) twin написал(а):
Не стоит. Пишите прямо файлом - проще, быстрее и не накладно. Базы нужны для динамической информации, статику грешно туда пихать
Спустя 8 часов, 20 минут, 15 секунд (28.01.2009 - 09:07) sergeiss написал(а):
Я лично не вижу проблемы с использованием БД. Она же ведь и так используется!!! Так зачем еще искать гимор на свою голову, занимаясь с текстовыми файлами?
Это я к тому, что чем меньше разнообразие "технологий" в пределах одного проекта, тем лучше (я имею ввиду выполнение однотипных действий, таких как хранение данных в рассматриваемом случае).
Это я к тому, что чем меньше разнообразие "технологий" в пределах одного проекта, тем лучше (я имею ввиду выполнение однотипных действий, таких как хранение данных в рассматриваемом случае).
Спустя 8 минут, 9 секунд (28.01.2009 - 09:15) kirik написал(а):
beginer, если все равно будете использовать БД, то делайте с ней. И бэкапить проще, если что.
Спустя 22 минуты, 26 секунд (28.01.2009 - 09:37) twin написал(а):
Вы ребята или плохо читаете вопрос, или вам наплевать на ресурсы сервера. Зачем гонять мускул, если страница статична? Раз в полгода обновить файл - на несколько порядков экономичнее. А сбэкапить пару страниц - где же проще?
Спустя 3 минуты, 12 секунд (28.01.2009 - 09:40) sergeiss написал(а):
Цитата (twin @ 28.01.2009 - 09:37) |
Вы ребята или плохо читаете вопрос, или вам наплевать на ресурсы сервера. Зачем гонять мускул, если страница статична? Раз в полгода обновить файл - на несколько порядков экономичнее. А сбэкапить пару страниц - где же проще? |
Встречный вопрос :
а что, ресурсы сервера сильно напрягутся от того, если надо только "раз полгода обновить файл"?
Подчеркиваю: всего раз в полгода!!! Даже не раз в полчаса.
Спустя 7 минут, 13 секунд (28.01.2009 - 09:48) kirik написал(а):
Цитата (twin @ 28.01.2009 - 01:37) |
или вам наплевать на ресурсы сервера |
Главное чтобы он (сервер) не остыл
Кстати интересно, что будет быстрее include файла, или запрос в БД? /* пошел тестить */
Спустя 27 минут, 8 секунд (28.01.2009 - 10:15) kirik написал(а):
Из вредности провел тест
Размер текста - 65 214 байт.
Текст был занесен в файл text.php, где был заключен в тэги <? ?> и заккоментирован.
Также была создана запись в таблице структуры id | content.
Количество иттераций - 500.
Были использованы следующие скрипты:
Для проверки скорости инклюда файла
Размер текста - 65 214 байт.
Текст был занесен в файл text.php, где был заключен в тэги <? ?> и заккоментирован.
Также была создана запись в таблице структуры id | content.
Количество иттераций - 500.
Были использованы следующие скрипты:
Для проверки скорости инклюда файла
PHP |
$start = microtime(true); |
Для проверки скорости вытаскивания из БД
PHP |
$start = microtime(true); |
Результаты:
При работе с файлом - 3.3476 с.
При работе с базой - 0.3423 с.
Если я провел тест верно (если нет - поправьте меня), то
Спустя 12 минут, 48 секунд (28.01.2009 - 10:28) twin написал(а):
Упс, это что за замеры такие? Вы гоняете инклуд в цикле, а у запоса ставите LIVIT 1. Что за сравнение? Вызвать 500 раз функцию или осуществить один запрос.... Сделайте тогда правильный тест, с выводом в поток. Подключите статичный html в первом случае и достаньте его из базы. Тогда и сравнивайте. Да и суть не в этом.
Вопрос был -
Вопрос был -
Цитата |
стоит ли статические страницы хранить в БД? |
Не в
Цитата |
а что, ресурсы сервера сильно напрягутся от того, если надо только "раз полгода обновить файл"? |
а именно в выводе, в отдаче пользователю. Если на сайте 500 посетителей в день, это минимум 500 запросов к бд. А если будeт несколько страниц? Как можно это сравнить с одним в полгода изменением файла?
Спустя 17 минут, 50 секунд (28.01.2009 - 10:45) kirik написал(а):
Цитата (twin @ 28.01.2009 - 02:28) |
Вызвать 500 раз функцию или осуществить один запрос.... |
Если вы могли заметить в случае с БД все 500 раз открывается новое соединение с БД => выбирается таблица => осуществляется запрос => результат запроса записывается в переменную => чистим память от результата запроса => закрываем соедниение с БД.
В любом случае, вот поток-
Раз
PHP |
$start = microtime(true); |
Два
PHP |
$start = microtime(true); |
Первый (include файла) - 1.294 с
Второй (работа с БД) - 0.875 с
Разница сократилась, но все-же в пользу БД.
Ну а если юзать file_get_contents() вместо include() -
Третий (с file_get_contents) - 0.5319 с
Разница уже в пользу файлов, но стоит-ли она удобства в работе?
Цитата (twin @ 28.01.2009 - 02:28) |
Если на сайте 500 посетителей в день, это минимум 500 запросов к бд. |
И тогда как минимум 500 обращений к диску (что впринципе равнозначно)
Спустя 2 минуты, 2 секунды (28.01.2009 - 10:47) sergeiss написал(а):
Цитата (twin @ 28.01.2009 - 10:28) | ||||
Вопрос был -
Не в
а именно в выводе, в отдаче пользователю. Если на сайте 500 посетителей в день, это минимум 500 запросов к бд. А если будeт несколько страниц? Как можно это сравнить с одним в полгода изменением файла? |
Подожди секунду
Оставим в стороне вопрос о корректности методики проведенного kirik'ом теста, это лучше делать в отдельной теме.
Но вот смотри, что ты упустил в процитированном утверждении.
Ты сравниваешь 500 обращений к БД за день, и одно изменение файла за полгода. Даже если не говорить о том, что эти обращения к БД совершенно ненапряжные для нее, то ты все равно не о том говоришь!
Кирик правильно измеряет: сравнение 500 обращений к БД "супротив" 500 обращений к файлу в день. А вовсе не 1 раз в полгода.
А "одно изменение файла раз в полгода" надо сравнивать с "одним изменением записи в БД раз в полгода".
И при этом всём не надо забывать, что БД - это те же файлы, только с чуть более структурированной информацией.
Спустя 14 минут, 38 секунд (28.01.2009 - 11:02) twin написал(а):
К файлу обращение идет одним сервером, а к бд - двумя. Вот я про что. Или Вам может не знакома ситуация, когда хостеры банят сайты именно из за перенапряга мускула? Файлы то они файлы, но вы гоняете два сервера, таская и перелопачивая html разметку в php, хотя можно обойтись простым html, и кстати наверняка даже без подключения, напрямую.
Спустя 15 минут, 20 секунд (28.01.2009 - 11:17) kirik написал(а):
Цитата (twin @ 28.01.2009 - 03:02) |
К файлу обращение идет одним сервером, а к бд - двумя. |
Если правильно понимаю все хитрую систему, то к файлу обращение идет вообще не через сервер (на уровне скрипта), он берется напрямую из ФС, а в случае с БД, да, через сервер, но разве это как-то влияет на скорость? Кстати можно еще вспомнить, что у MySQL есть такая штука, как кэширование запросов. Тогда данные будут считываться не из файла на жестком диске, а прямо из оперативной памяти. О разности в скорости чтения думаю спорить не будем
Цитата (twin @ 28.01.2009 - 03:02) |
Или Вам может не знакома ситуация, когда хостеры банят сайты именно из за перенапряга мускула? |
Знакомая ситуация, вот только чаще всего она возникает из-за криворукости программера. Ну а если не по этой причине, то сайт настолько сложный и высоконагруженный, что файлами его реализовать _не возможно_.
Спустя 1 минута, 26 секунд (28.01.2009 - 11:19) sergeiss написал(а):
Сорри... Похоже, я попутал слова "статические" и "статиСтические"... Подразумевал последние.
В первом случае, конечно, лучше без БД.
twin - экскузи муа (это "типа по-хранцузски" )
PS. Даже не то, что "лучше", а только так и можно. Просто сама изначальная постановка вопроса "сбила с толку".
В первом случае, конечно, лучше без БД.
twin - экскузи муа (это "типа по-хранцузски" )
PS. Даже не то, что "лучше", а только так и можно. Просто сама изначальная постановка вопроса "сбила с толку".
Спустя 9 минут, 15 секунд (28.01.2009 - 11:28) kirik написал(а):
Цитата (sergeiss @ 28.01.2009 - 03:19) |
Даже не то, что "лучше", а только так и можно. |
Да чем же вам БД не нравится в подобной роли?
Спустя 3 минуты, 29 секунд (28.01.2009 - 11:32) sergeiss написал(а):
Цитата (kirik @ 28.01.2009 - 11:28) | ||
Да чем же вам БД не нравится в подобной роли? |
Тем, что речь идет про обычный сайт, в котором есть набор обычный файлов. И зачем их в БД засовывать?
Странно, что изначально у человека (топикстартета) вообще возник этот вопрос
Спустя 10 часов, 17 минут, 51 секунда (28.01.2009 - 21:49) kirik написал(а):
Цитата (sergeiss @ 28.01.2009 - 03:32) |
Тем, что речь идет про обычный сайт, в котором есть набор обычный файлов. И зачем их в БД засовывать? |
Все равно нужно в БД! =) А вдруг потом нужно будет поиск привязать? Или еще какую полезность?
Спустя 1 минута, 56 секунд (28.01.2009 - 21:51) twin написал(а):
Это потом. Потом и привязать, когда появится необходимость динамически использовать страницу. Поиск можно кстати и по статической легко сделать.
Спустя 16 минут, 23 секунды (28.01.2009 - 22:08) kirik написал(а):
Цитата (twin @ 28.01.2009 - 13:51) |
Потом и привязать, когда появится необходимость динамически использовать страницу. |
Можно.. Тогда еще придется тратить время на написание скрипта, который файлы скопирует в БД + перевод самого сайта на работу с БД.
А такого случая когда нужно переводить сайт с БД на файлы я себе даже не представляю.
Спустя 19 минут, 57 секунд (28.01.2009 - 22:28) twin написал(а):
Всё должно быть своевременно. Когда появляется потребность - её надо удовлетворять. Это прогресс и оптимизация. Вы же не станете покупать допустим хостинг с суперпрофессиональным тарифом и не будите платить за него по 1000$ в месяц только потому, что потом вдруг когда-нибудь Вам потребуется немного больше мощности... Можно конечно и так поступить, каждый сходит с ума по своему, но советовать этот беспредел всем подряд - моветон. Вы спорите уже по инерции, сами понимая, что не правы.
Спустя 19 часов, 1 минута, 46 секунд (29.01.2009 - 17:29) beginer написал(а):
Цитата |
Странно, что изначально у человека (топикстартета) вообще возник этот вопрос |
Потому и возник, что раздел в котором топикастер разместил свой вопрос называется "PHP для начинающих", а топикастер в веб-разработках как раз начинающий.
Кстати некоторые мысли участников дискуссии заставили меня задуматься над планируемой архитектурой. Например, мысль об организации поиска...
Да и в целом все получилось достаточно познавательно. Тем более, как мне кажется, я не единственный кто задавался вопросом о том, где лучше хранить контент.