LEOnidUKG: Серьёзно такое есть на хостингах? Это же по сути может ломает CMS.
Не про 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 объявили и сконнектились и заодно входящие данные зачистили. Так что не к хостингу вопрос.
SeVlad: Всё несколько глобальнее.
... а про тёрки "БД vs файлы" .... Эдак скоро докатимся "счёты vs ПК"
Не настолько категоричен. Для задачи быстро сделать сайт визитку в пределах 5-10 страниц файлы бы не исключал. Быстро, это 2-3 часа времени, 70-100 строк кода + работа над шаблонами. Управление в 2-3 простых текстовых файлах. TTFB - десятки мс.
Зы: 2-3 простых имеется ввиду для конкретного раздела (меню, м/б суб-меню или парент-меню и собственно файл контента + файл шаблона), понятно что 50 страничника файлов будет минимум 52
SeVlad: Всё чаще мне начинает казаться, что теория плоской земли добралась и до разработчиков.
В 21м веке не понимать зачем нужна БД (и вообще почему пришлось их изобретать) - это.. ппц просто.
ЗЫ. Я не против файловых двигов. Для нек. задач/условий они могут быть вполне целесообразнее. (для доров напр:) ). Но "современный сайт" и "статика"* - понятия несовместимые.
* АПД: имею ввиду вывод статики из файлов.
Неверно, мне кажется, суть уловили.
Началось с того, что попросили накидать актуальные CMS без БД. Потом пришел товарищ, который заявил, что брать из файла весом 2 МБ и базы аналогичного размера не конструктивно. Файл проигрывает.
И понеслась. По кочкам 😂
Товарищу указали, так никто на делает, а делают вменяемое кол-во require небольших файлов и в этом случае никакого выигрыша базы данных нет.
Также, на мой взгляд, все говорят примерно об одном и том же - выбор хранилища зависит сугубо от задачи. Просто разными словами ☝
Error:
Marat_Kh:
что брать из файла весом 2 МБ и базы аналогичного размера не конструктивно
читать: что брать из файла весом 2 МБ в сравнении с базой аналогичного размера не конструктивно
3 символа ввел, получил ответ, а дальнейшие варианты по факту ввода след. символов берем из variants. Вернулся назад, изменил запрос - локалстораж почистили и следующий ответ записали.
_SP_: Не бывает так. Не бывает.
В реальности никогда не бывает так, чтобы сегодня 100, а завтра 1000000.
И не будет работать НИХРЕНА если аяксом выгребать из базы на 1000000 при каждом нажатии клавиши. Ляжет всё. Задолго до того.
Да вот недавно. Продавали тут одни "шурики" запчасти, отдельную позицию - карданы. Примерно 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] => как построить [альпийскую] горку на [садовом] участке
)
т.е. оставил всего 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 файлы. По мне так, ничего плохого ни в файлах, ни в БД нет. Сам юзаю и тот, и другой вариант сугубо в зависимости от задачи. Полет нормальный;)
_SP_:
Ну и... 1 секунда выж понимаете, что "на продакшене" это "приговор" ?
Конечно.
SELECT `adomain`, offsets(ads), snippet(ads, '[', ']', '... ') as result_snippet
FROM `ads` WHERE `atitle` MATCH :ttl limit 20;
....
[:ttl] => atitle:камаз* atitle:новы* atitle:зерновоз*
Такие запросы к базе с почти 44 млн. записей никто в здравом уме "на продакшене" задавать ни будет.
_SP_:
Классический пример: подсказки в поиск для магазина с 100 товаров.
В 99% случаев народ будет при нажатии кнопок аяксом их с сервера вынимать.
Представляете :) ? Вместо того, чтобы получить все названия всех товаров один раз асинхронно
и сохранить их в локалсторейдж и мгновенно реагировать на ввод со стороны клиента
будут туда-сюда аяксить до позеленения, со стороны сервера запускать скрипты, искать в базе :))) и возвращать ответы.
"Мама роди меня обратно".
"Тормозит WordPress. 900+ запросов на странице!"
:)
А если их, товаров, 100000. Или сегодня 100, завтра 1000000, а послезавтра 12🍿
Первый вариант подключал файл (include), в котором хранились данные страниц в виде массива (вес файла ~ 2 Мб) из которого брался нужный контент.
Второй вариант получал нужный контент через запрос к SQLite (вес базы ~ 2 Мб).
Архитектура скажут почти все, и я повторю - архитектура. А зачем сразу 2МБ, которые могут перерасти в 100500МБ, может проще 3+ файла грузануть.
Реквайр файл вменяемого размера 10-100-ни мс. Памяти юзается мизер. Как показывает практика, число разделов на сайте исчисляемых 1000 редко встречается. Разделы дальше 3-4-5 уровня вложенности тоже не популярны (с) Кэп очевидность
массив c уралми разделов содержащий данные про суб_раздел и ссылку на path к файлу с контентом.
массив c уралми суб_разделов содержащий данные про cуб_суб_раздел и со ссылкой на path к файлу с контентом.
.....массив c уралми суб_суб_разделов
файл контента полученный из п.1 или 2.
как вариант, коих может быть немало. Зависит☝
Из файла можно по разному данные брать 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, ...] на самом деле БД "не нужен, он только лишний лунц жрет" (с) Уэф
Серьёзно такое есть на хостингах? Это же по сути может ломает CMS.
Не про CMS. Но, как могут, защищаются. Например YII так.
имеет смысл юзать у себя
Про real_escape_string (если это не про get_magic_quotes_gpc) , это скорее всего где то выше mysqli объявили и сконнектились и заодно входящие данные зачистили. Так что не к хостингу вопрос.
Я отреагировал лишь на
Всё чаще мне начинает казаться, что теория плоской земли добралась и до разработчиков.
но учитывая
что для некоторых сайтов и я вполне допускаю использование файлов
предмета разногласий вроде как нет.
Это полностью зависит от того, кто чем может делать. Те "свойство" (если так можно сказать) разработчика. Субъективная хар-ка.
Спс кэп. Те, кто не имеют "свойства" использовать файлы в качестве хранилища, не используют их. И я кэп 😂
Всё несколько глобальнее.
... а про тёрки "БД vs файлы" .... Эдак скоро докатимся "счёты vs ПК"
Не настолько категоричен. Для задачи быстро сделать сайт визитку в пределах 5-10 страниц файлы бы не исключал. Быстро, это 2-3 часа времени, 70-100 строк кода + работа над шаблонами. Управление в 2-3 простых текстовых файлах. TTFB - десятки мс.
Зы: 2-3 простых имеется ввиду для конкретного раздела (меню, м/б суб-меню или парент-меню и собственно файл контента + файл шаблона), понятно что 50 страничника файлов будет минимум 52
Всё чаще мне начинает казаться, что теория плоской земли добралась и до разработчиков.
В 21м веке не понимать зачем нужна БД (и вообще почему пришлось их изобретать) - это.. ппц просто.
ЗЫ. Я не против файловых двигов. Для нек. задач/условий они могут быть вполне целесообразнее. (для доров напр:) ). Но "современный сайт" и "статика"* - понятия несовместимые.
* АПД: имею ввиду вывод статики из файлов.
Неверно, мне кажется, суть уловили.
Началось с того, что попросили накидать актуальные CMS без БД. Потом пришел товарищ, который заявил, что брать из файла весом 2 МБ и базы аналогичного размера не конструктивно. Файл проигрывает.
И понеслась. По кочкам 😂
Товарищу указали, так никто на делает, а делают вменяемое кол-во require небольших файлов и в этом случае никакого выигрыша базы данных нет.
Также, на мой взгляд, все говорят примерно об одном и том же - выбор хранилища зависит сугубо от задачи. Просто разными словами ☝
Error:
что брать из файла весом 2 МБ и базы аналогичного размера не конструктивно
читать: что брать из файла весом 2 МБ в сравнении с базой аналогичного размера не конструктивно
Ну давайте посчитаем. 20.000 товаров. По 50 байт. 1.000.000 байт.
Не не не 🙄 Не 20 тысяч, а пользователь ввел, например "тойота"
Ответ
{search_result:{...},
variants : {
1 : {key : "тойота к", search_result:{тойота королла,тойота камри , ...}},
2 : {key : "тойота р", search_result:{тойота раф , ...}},
...
}
}
3 символа ввел, получил ответ, а дальнейшие варианты по факту ввода след. символов берем из variants. Вернулся назад, изменил запрос - локалстораж почистили и следующий ответ записали.
Не бывает так. Не бывает.
В реальности никогда не бывает так, чтобы сегодня 100, а завтра 1000000.
И не будет работать НИХРЕНА если аяксом выгребать из базы на 1000000 при каждом нажатии клавиши. Ляжет всё. Задолго до того.
Да вот недавно. Продавали тут одни "шурики" запчасти, отдельную позицию - карданы. Примерно 100 наименований и есть. Потом решили всю номенклатуру на одну марку, где то между 10-15 тыс. позиций. Залили - работает. Теперь хотят еще пару популярных марок. + от 20000. А 1000000, это условно конечно.
Вот такая конструкция на ~140000 записей при 20 одновременных запросов ни одного не 200 и не более 96мс чтобы собрать ответ. А в среднем время выполнения запроса ~ [transaction_time] => 0.0625 , Memory current/peak, MB => 0.95 / 1.00
Дальше экспериментирую. Удаляю
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 файлы. По мне так, ничего плохого ни в файлах, ни в БД нет. Сам юзаю и тот, и другой вариант сугубо в зависимости от задачи. Полет нормальный;)
Ну и... 1 секунда выж понимаете, что "на продакшене" это "приговор" ?
Конечно.
Такие запросы к базе с почти 44 млн. записей никто в здравом уме "на продакшене" задавать ни будет.
Классический пример: подсказки в поиск для магазина с 100 товаров.
В 99% случаев народ будет при нажатии кнопок аяксом их с сервера вынимать.
Представляете :) ? Вместо того, чтобы получить все названия всех товаров один раз асинхронно
и сохранить их в локалсторейдж и мгновенно реагировать на ввод со стороны клиента
будут туда-сюда аяксить до позеленения, со стороны сервера запускать скрипты, искать в базе :))) и возвращать ответы.
"Мама роди меня обратно".
"Тормозит WordPress. 900+ запросов на странице!"
:)
А если их, товаров, 100000. Или сегодня 100, завтра 1000000, а послезавтра 12🍿
Второй вариант получал нужный контент через запрос к SQLite (вес базы ~ 2 Мб).
Архитектура скажут почти все, и я повторю - архитектура. А зачем сразу 2МБ, которые могут перерасти в 100500МБ, может проще 3+ файла грузануть.
Реквайр файл вменяемого размера 10-100-ни мс. Памяти юзается мизер. Как показывает практика, число разделов на сайте исчисляемых 1000 редко встречается. Разделы дальше 3-4-5 уровня вложенности тоже не популярны (с) Кэп очевидность
как вариант, коих может быть немало. Зависит☝
Из файла можно по разному данные брать require, file_get_contents + (json_decode, SimpleXML иже с ним про xml, csv, parse_ini_file).
Но, да SQLite тоже уважаю :) И вот почему. К вопросу о скорости SQLite:
Запрос к базе букварикс имеющей 43984091 записей - менее 1 секунды
Заказчик жеж как - на внешнюю сторону смотрит. Разработчик тему (плагин) накатил, заказчику показал - смотри как круто и прошу отметить, дешево! ☝
А потом, когда сайт сдан пингдом и облом 😕
На мой взгляд заказчик, заказчик выбирая вордпрес в качестве КМС, должен или остановиться на сайте-блоге или осознавать - сэкономленные на сайте деньги придется компенсировать затратами на железо - хостинг. Это справедливо и для многих других платформ.
Если на сайте нет поиска и фильтра, и все сводится к тому, чтобы по определенному урлу показать документ имеющий несколько признаков [title, description, content, ...] на самом деле БД "не нужен, он только лишний лунц жрет" (с) Уэф