Не про CMS. Но, как могут, защищаются. Например YII так.
/** * Normalizes the request data. * This method strips off slashes in request data if get_magic_quotes_gpc() returns true. * It also performs CSRF validation if {@link enableCsrfValidation} is true. */ protected function normalizeRequest() { // normalize request if(function_exists('get_magic_quotes_gpc') && get_magic_quotes_gpc()) { if(isset($_GET)) $_GET=$this->stripSlashes($_GET); if(isset($_POST)) $_POST=$this->stripSlashes($_POST); if(isset($_REQUEST)) $_REQUEST=$this->stripSlashes($_REQUEST); if(isset($_COOKIE)) $_COOKIE=$this->stripSlashes($_COOKIE); } if($this->enableCsrfValidation) Yii::app()->attachEventHandler('onBeginRequest',array($this,'validateCsrfToken')); }
имеет смысл юзать у себя
Про real_escape_string (если это не про get_magic_quotes_gpc) , это скорее всего где то выше mysqli объявили и сконнектились и заодно входящие данные зачистили. Так что не к хостингу вопрос.
Я отреагировал лишь на
но учитывая
предмета разногласий вроде как нет.
Спс кэп. Те, кто не имеют "свойства" использовать файлы в качестве хранилища, не используют их. И я кэп 😂
Не настолько категоричен. Для задачи быстро сделать сайт визитку в пределах 5-10 страниц файлы бы не исключал. Быстро, это 2-3 часа времени, 70-100 строк кода + работа над шаблонами. Управление в 2-3 простых текстовых файлах. TTFB - десятки мс.
Зы: 2-3 простых имеется ввиду для конкретного раздела (меню, м/б суб-меню или парент-меню и собственно файл контента + файл шаблона), понятно что 50 страничника файлов будет минимум 52
Неверно, мне кажется, суть уловили.
Началось с того, что попросили накидать актуальные CMS без БД. Потом пришел товарищ, который заявил, что брать из файла весом 2 МБ и базы аналогичного размера не конструктивно. Файл проигрывает.
И понеслась. По кочкам 😂
Товарищу указали, так никто на делает, а делают вменяемое кол-во require небольших файлов и в этом случае никакого выигрыша базы данных нет.
Также, на мой взгляд, все говорят примерно об одном и том же - выбор хранилища зависит сугубо от задачи. Просто разными словами ☝
Error:
читать: что брать из файла весом 2 МБ в сравнении с базой аналогичного размера не конструктивно
Не не не 🙄 Не 20 тысяч, а пользователь ввел, например "тойота"
Ответ
{ search_result:{...}, variants : { 1 : {key : "тойота к", search_result:{тойота королла,тойота камри , ...}}, 2 : {key : "тойота р", search_result:{тойота раф , ...}}, ... } }
3 символа ввел, получил ответ, а дальнейшие варианты по факту ввода след. символов берем из variants. Вернулся назад, изменил запрос - локалстораж почистили и следующий ответ записали.
Да вот недавно. Продавали тут одни "шурики" запчасти, отдельную позицию - карданы. Примерно 100 наименований и есть. Потом решили всю номенклатуру на одну марку, где то между 10-15 тыс. позиций. Залили - работает. Теперь хотят еще пару популярных марок. + от 20000. А 1000000, это условно конечно.
Вот такая конструкция на ~140000 записей при 20 одновременных запросов ни одного не 200 и не более 96мс чтобы собрать ответ. А в среднем время выполнения запроса ~ [transaction_time] => 0.0625 , Memory current/peak, MB => 0.95 / 1.00
CREATE VIRTUAL TABLE USING [FTS4] ( url, snpt, tokenize=porter); SELECT `url`, snippet(s, '[', ']', '... ') as r_snpt FROM `s` WHERE `snpt` MATCH :ttl limit 10; [:ttl] => snpt:садов* snpt:альпийс* [transaction_time] => 0.0625 //ответ примерно такой [0] => Array ( [r_snpt] => как построить [альпийскую] горку на [садовом] участке ) " title=" => /kak_postroit_alpijskuyu_gorku_na_sadovom_uchastke-new_new950 [r_snpt] => как построить [альпийскую] горку на [садовом] участке ) " target="_blank"> => /kak_postroit_alpijskuyu_gorku_na_sadovom_uchastke-new_new950 [r_snpt] => как построить [альпийскую] горку на [садовом] участке ) " title=" => /sadovye_cvety_dlya_alpijskih_gorok_nazvaniya_i_foto-new_new20 [r_snpt] => [садовые] цветы для [альпийских] горок названия и фото ) ...... [9] => Array ( => /kak_postroit_alpijskuyu_gorku_na_sadovom_uchastke-new_new950 [r_snpt] => как построить [альпийскую] горку на [садовом] участке ) " target="_blank"> => /sadovye_cvety_dlya_alpijskih_gorok_nazvaniya_i_foto-new_new20 [r_snpt] => [садовые] цветы для [альпийских] горок названия и фото ) ...... [9] => Array ( => /kak_postroit_alpijskuyu_gorku_na_sadovom_uchastke-new_new950 [r_snpt] => как построить [альпийскую] горку на [садовом] участке )
Дальше экспериментирую. Удаляю
1) DELETE FROM s WHERE rowid>60000;
т.е. оставил всего 60000 записей. Результат: [transaction_time] => 0.0312
2)DELETE FROM s WHERE rowid>10000;
т.е. оставил всего 10000 записей. Результат: [transaction_time] => 0.0156
Вывод: на коленке, можно собрать вменяемую поисковую систему для небольшого сайта (10-60 тыс документов) без применения ухищрений типа кеширования. А если в кеш класть или локалстораж пользовать то☝
Кстати, идея отдавать результат для подсказки + варианты с различными следующими символами и localStorage.setItem( 'find_result', jsn_response ); И брать подходящий результат при следующем нажатии, прям сейчас в работе.
Разговор свернул в сторону БД vs файлы. По мне так, ничего плохого ни в файлах, ни в БД нет. Сам юзаю и тот, и другой вариант сугубо в зависимости от задачи. Полет нормальный;)
Конечно.
SELECT `adomain`, offsets(ads), snippet(ads, '[', ']', '... ') as result_snippet FROM `ads` WHERE `atitle` MATCH :ttl limit 20; .... [:ttl] => atitle:камаз* atitle:новы* atitle:зерновоз*
Такие запросы к базе с почти 44 млн. записей никто в здравом уме "на продакшене" задавать ни будет.
А если их, товаров, 100000. Или сегодня 100, завтра 1000000, а послезавтра 12🍿
Архитектура скажут почти все, и я повторю - архитектура. А зачем сразу 2МБ, которые могут перерасти в 100500МБ, может проще 3+ файла грузануть.
Реквайр файл вменяемого размера 10-100-ни мс. Памяти юзается мизер. Как показывает практика, число разделов на сайте исчисляемых 1000 редко встречается. Разделы дальше 3-4-5 уровня вложенности тоже не популярны (с) Кэп очевидность
как вариант, коих может быть немало. Зависит☝
Из файла можно по разному данные брать require, file_get_contents + (json_decode, SimpleXML иже с ним про xml, csv, parse_ini_file).
Но, да SQLite тоже уважаю :) И вот почему. К вопросу о скорости SQLite:
[sql] => SELECT `adomain`, offsets(ads), snippet(ads, '[', ']', '... ') as result_snippet FROM `ads` WHERE `atitle` MATCH :ttl limit 20; .... [:ttl] => atitle:камаз* atitle:новы* atitle:зерновоз* .... [transaction_time] => 0.9531 ....
Запрос к базе букварикс имеющей 43984091 записей - менее 1 секунды
Заказчик жеж как - на внешнюю сторону смотрит. Разработчик тему (плагин) накатил, заказчику показал - смотри как круто и прошу отметить, дешево! ☝
А потом, когда сайт сдан пингдом и облом 😕
На мой взгляд заказчик, заказчик выбирая вордпрес в качестве КМС, должен или остановиться на сайте-блоге или осознавать - сэкономленные на сайте деньги придется компенсировать затратами на железо - хостинг. Это справедливо и для многих других платформ.
Если на сайте нет поиска и фильтра, и все сводится к тому, чтобы по определенному урлу показать документ имеющий несколько признаков [title, description, content, ...] на самом деле БД "не нужен, он только лишний лунц жрет" (с) Уэф
