- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
А зачем там кмс вообще ? Сверстал хтмл да закинул на сайт.
Новости постить. Цены менять на услуги. Страницы редактировать. Это, как правило нужно раз в месяц, но для этого непременно впендярят битрикс
Новости постить. Цены менять на услуги. Страницы редактировать. Это, как правило нужно раз в месяц, но для этого непременно впендярят битрикс
Просто все почему-то кидаются в крайности. От голого html до bitrix. Если ничего особенного не нужно, проще взять любой микрофреймворк (lumen, slim, pixie?) и запилить нужный функционал достаточно быстро.
Инструмент нужно подбирать под потребности и бюджет, а не с горящими глазами и вилами кидаться и кричать "ТОЛЬКО HTML!!!1", "CMS c БД наше все!!!!11один"
Просто все почему-то кидаются в крайности. От голого html до bitrix.
Я не кидаюсь. Я работаю, пардон, с этим говном. Как SEO-шнек. И кое что мне проще править самому, чем искать горе вебмастера, что неизвестно когда и как слепил. Их может быть и несколько, как вот клиент с визиткой зашел на джомле. Там такой цирк с конями...
Хотя его случай должен быть - как раз простая ЦМС с бд на файлах, с простой админкой.
Но наворотили и содрали многоденех - чтоб было дорогобохато.
Не бывает так. Не бывает.
В реальности никогда не бывает так, чтобы сегодня 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 ); И брать подходящий результат при следующем нажатии, прям сейчас в работе.
Да вот недавно. Продавали тут одни "шурики" запчасти, отдельную позицию - карданы. Примерно 100 наименований и есть. Потом решили всю номенклатуру на одну марку, где то между 10-15 тыс. позиций. Залили - работает. Теперь хотят еще пару популярных марок. + от 20000. А 1000000, это условно конечно.
Автозапчасти да - их тыщи. Радиодетали там итп.
И тут надо сразу думать как это все переваривать, то, что первоначально у людей было 100 позиций кажется мне крайне удивительным.
Но всё, что ближе к "куртка женская" "слон синий" редко имеет столько разновидностей.
Вывод: на коленке, можно собрать вменяемую поисковую систему для небольшого сайта (10-60 тыс документов) без применения ухищрений типа кеширования. А если в кеш класть или локалстораж пользовать то☝
Да и миллион можно. При наличии индекса из базы все забирается почти мгновенно.
Дольше весь этот php стартует.
Кстати, идея отдавать результат для подсказки + варианты с различными следующими символами и localStorage.setItem( 'find_result', jsn_response ); И брать подходящий результат при следующем нажатии, прям сейчас в работе.
Ну давайте посчитаем. 20.000 товаров. По 50 байт. 1.000.000 байт.
Насколько сожмет его зип ? Надо конечно попробовать, но если в 5-10 раз, то 200кб один раз юзеру можно и "залить".
Особенно если асинхронно.
Больше - хуже. Действительно придется заливать то, что остается после ввода скажем 3х символов.
Но это всё уже "несколько на грани фола".
Для сотен и тысяч товаров можно многое выгрузить на клиентскую сторону, для десятков тысяч уже не выйдет.
Интересно составлят ли ИМ и CMS с >10.000 документов хотя-бы 0.1% от общего числа...
А в БД фигачат 99%...
Ну давайте посчитаем. 20.000 товаров. По 50 байт. 1.000.000 байт.
Не не не 🙄 Не 20 тысяч, а пользователь ввел, например "тойота"
Ответ
3 символа ввел, получил ответ, а дальнейшие варианты по факту ввода след. символов берем из variants. Вернулся назад, изменил запрос - локалстораж почистили и следующий ответ записали.
Всё чаще мне начинает казаться, что теория плоской земли добралась и до разработчиков.
В 21м веке не понимать зачем нужна БД (и вообще почему пришлось их изобретать) - это.. ппц просто.
ЗЫ. Я не против файловых двигов. Для нек. задач/условий они могут быть вполне целесообразнее. (для доров напр:) ). Но "современный сайт" и "статика"* - понятия несовместимые.
* АПД: имею ввиду вывод статики из файлов.
Аргументация шикарная, просто слов нет :).
Академическая яб сказал :).
Тоже, подозреваю, пункты меню из ПХП зажигает... а чё... php егож не просто так изобрели :))
Истинно говорю вам, налетит на ось, недолго осталось...
незапрошенные. Десятки тысяч сгорели в пламени пожара. Иногда ущерб бывал
относительно невелик - добрые намерения, не вполне подходящие для среды
назначения. Иногда информация была злонамеренной - вирусы, затыкавшие
локальную сеть так тщательно, что целая цивилизация должна была начинать с
нуля. В группах "Где они теперь" и "Угрозы" ходили рассказы и о худших
трагедиях: планеты, увязшие в дублировании информации; расы, ставшие
безмозглыми из-за плохо запрограммированных иммунных систем.
итд итп... недолго, недолго нам всем осталось :)
Всё чаще мне начинает казаться, что теория плоской земли добралась и до разработчиков.
В 21м веке не понимать зачем нужна БД (и вообще почему пришлось их изобретать) - это.. ппц просто.
ЗЫ. Я не против файловых двигов. Для нек. задач/условий они могут быть вполне целесообразнее. (для доров напр:) ). Но "современный сайт" и "статика"* - понятия несовместимые.
* АПД: имею ввиду вывод статики из файлов.
Неверно, мне кажется, суть уловили.
Началось с того, что попросили накидать актуальные CMS без БД. Потом пришел товарищ, который заявил, что брать из файла весом 2 МБ и базы аналогичного размера не конструктивно. Файл проигрывает.
И понеслась. По кочкам 😂
Товарищу указали, так никто на делает, а делают вменяемое кол-во require небольших файлов и в этом случае никакого выигрыша базы данных нет.
Также, на мой взгляд, все говорят примерно об одном и том же - выбор хранилища зависит сугубо от задачи. Просто разными словами ☝
Error:
что брать из файла весом 2 МБ и базы аналогичного размера не конструктивно
читать: что брать из файла весом 2 МБ в сравнении с базой аналогичного размера не конструктивно
Также, на мой взгляд, все говорят примерно об одном и том же - выбор хранилища зависит сугубо от задачи. Просто разными словами ☝
Я б ещё добавил. ...и вебмастера.