Есть такая штуковина: PHP: <? $names = array ( '1' => 'Контент 1', '2' => 'Контент 2' ); $name = null; if (isSet($category) && isSet($names[$category])) { $name = $names[$category]; } else { exit("Несуществующая категория"); } ?> $category = "1"; , то $name = "Контент 1"; и т.д. Если перенести эту часть Код (Text): '1' => 'Контент 1', '2' => 'Контент 2' в текстовый файл, чтобы получилась такая статичная база, будет ли она создавать большую нагрузку на сервер, если её объём примерно 400 мегабайт? Быстро ли она будет работать?
400мегабайт текстового файла ? я не ослышался ? О_О_О если да , то (по моему мнению ) у клиента будет , мягко говоря - капец , хосту не будет , будет просто метры раздавать клиенту , которому кстати капец
Почему клиенту метры раздавать? При запросе $category = "1"; будет $name = "Контент 1"; , а всё остальное, что ниже (2 => Контент 2 и т.д.) никуда не пойдёт.
верно , я возможно ошибаюсь ) но при этих тестах при инклуде множества файлов общим весом в много-много метров этот файл грузился клиенту полностью для того чтобы извлечь из себя данные. не отрицаю вероятности существования других простых методов кроме тех что я использовал , но я их не знаю ) да , но вам ведь прийдётся делать простой инклуд этого файла ? попробуйте на локалхосте заинклудить этот файл под браузером который покажет сколько он скушает
причем здесь инклуд и клиент? скрипт на сервере обрабатывается. клиент может заметить только задержку пока сервер обработает такой файл, ничего ему закачиваться не будет. бред какойто.
ххмм верно йа перепутал вывод текста в браузер с инклуда (что равносильно загрузке файла) с какой-то херью которую хочет автор кароче раз ты прав подскажи тс"у ответики на вопросики йаху
-Vladimir- Да, будет создавать большую нагрузку. Если вам нужен простой способ хранения данных, то SQLite вам поможет. Но каждый раз инклудить 400-метровый PHP файл - смерть серверу.
я на локалхосте не могу заинклудить 2.5метровый файл с 66к строками какого-то текста про какую-то реку из индии а там символов на 400мб...*shocked*
Если на сервере нет акселератора, то серверу придется каждый раз снова и снова парсить этот 400 метровый PHP файл - представьте себе тормоза. А если акселератор есть, то закешированный файл будет весить уже где-то под гигабайт (файлы с готовым опкодом всегда почему-то занимают гораздо больше места, чем исходные скрипты). То есть в любом случае будет жуткая трата времени и оперативной памяти.
В том-то и дело, что мне нужен не mysql (хотя все возможности на сервере есть). Просто до этого пробовал через mysql, после чего последний стал тормозить (наверно, хостинг такой). Хотя, можно снова mysql попробовал. А с текстовыми базами - есть один обходной путь, чтобы 400 мб не делать, а разбить на меньшие файлы.
я кажется ссылочку дал не для того чтобы показать свою первую тему на этом форуме тебе нужно при разбиении подумать над сортировкой , алгоритмом поиска нужного файла и т.д да и блин , я параноик насчёт перегруза бд , но даже у меня никогда бд не тормозила предполагаю что у вас тормо-хостер и средненький проект иначе вы были бы уверены что у вас грузится бд из-за количества запросов и не предполагали что это хостер
а про разбиение по папочкам подумаем ? )) или будем "всё так просто" кидать 100500 файлов в одну дирректорию ? это всё блин обсуждали в том линке что я дал *обиделся*
Очевидно, с MySQL следует поступить тем же образом, то есть одна категория - одна запись, а не пихать всё в одну строку.
Не совсем понял, что ты имеешь ввиду. В таблицу mysql данные добавляются следующим образом: id | category | title | text | dates | views | vote Соответственно: id - номер записи, category - категория записи. Предлагаешь для каждой категории создавать свою таблицу в базе?
Отнюдь. И прекрасно. Осталось поставить индексы на столбцы в соответствии с нужными выборками и всё будет летать. Для mysql 400 Мб, это ничто.
Чем вам поможет скришнот майадмина? Я имею ввиду, что 400 Мб для MySQL ничто, используйте MySQL. Если говорите, что использовали, но не вышло - расскажите, как это делали.