- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Накидайте бесплатные актуальные CMS без БД, новостного типа. Чтоб можно было легко натянуть на CMS любой html шаблон.
Без БД и чтобы легко натянуть - это несвязанные проблемы.
Без БД лучший вариант - это static site generator. В частности, бонусом получаешь максимально возможную производительность. Никакие CMS и рядом не лежали.
Например, http://gohugo.io/ Готовишь шаблон, готовишь текстовые файлы с новостями, запускаешь hugo - он натягивает на новости шаблон и получается сайт.
---------- Добавлено 25.02.2018 в 14:10 ----------
Marat_Kh так о каком уважении вы говорите ?
Его нет на форумах уже давно. Лет 5 назад все было как-то по другому.
Врете вы все.
Лет 7 назад люди уже обижались когда к ним на ты обращались.
Хотя, например, в начале века - нормой было именно на ты.
---------- Добавлено 25.02.2018 в 14:21 ----------
Сразу видно что вы никогда не производили тесты производительности.
Я вот производил, и результатом был шокирован.
Сайты без БД при множестве потоков (клиентов в секунду) начинают жрать столько времени CPU, что сайт начинает жутко тормозить (вплоть до нескольких секунд на открытие страницы).
Проверял тот же сайт (скрипт) на с базой в SQLite и страницы молниеносно загружались.
Сайт без БД выдерживал 200 потоков, с SQLite выдерживал 1500 потоков без заметных лагов.
Ну и база SQLite размещается в едином файле, легко копируется, редактируется итп. Выводы делайте сами.
Е-р-у-н-д-а.
Зависит он конкретной кривизны конкретной тестируемой системы.
Вы раз уж тестировали - привели бы конкретные названия и описание железа.
И да - данные, коими тестировали - тоже имеют значение.
---------- Добавлено 25.02.2018 в 14:23 ----------
Какие и зачем данные вы собрались "хранить и легко выбирать" ?
Легче всего "энти данные" достать из файловой системы, в виде уже готовой страницы, и сразу отдать пользователю.
Даже скриптов никаких не надо ..
Только это не называется словом "CMS без БД"
Вы описали принципы работы static site generator.
---------- Добавлено 25.02.2018 в 14:28 ----------
Вы из какого года нам пишете ? Судя по продвигаемой философии где-то с времен популярности Web 1.0 🤣
Вы не понимаете умных слов, которые употребляете.
Дело в том, что Веб 2.0 - это дохрена JS на стороне браузера. Да, это динамика. В браузере. Никакого отношения к тому, что там на стороне сервера это не имеет отношения.
На сервере может быть при том полнейшая статика.
А управлять однозначно удобнее на уровне БД
Что такое управление?
Поиск?
Если у вас куча страниц, где нужно найти определенное слово в тексте - да, конечно БД лучше. Только не обычный MySQL, а специализированная БД полнотекстового поиска.
Если же у вас информация структуризирована и вы ищете по дате, по тегу - никакой разницы нет в удобстве и на голой файловой системе.
Добавление, редактирование - не является проблемой на файловой системе.
Блокировки во избежание множественного доступа на запись в файловой системе решаются элементарно.
Какие еще проблемы управления?
---------- Добавлено 07.03.2018 в 05:03 ----------
Сразу видно что вы никогда не производили тесты производительности.
Я вот производил, и результатом был шокирован.
Сайты без БД при множестве потоков (клиентов в секунду) начинают жрать столько времени CPU, что сайт начинает жутко тормозить (вплоть до нескольких секунд на открытие страницы).
Проверял тот же сайт (скрипт) на с базой в SQLite и страницы молниеносно загружались.
Сайт без БД выдерживал 200 потоков, с SQLite выдерживал 1500 потоков без заметных лагов.
Ну и база SQLite размещается в едином файле, легко копируется, редактируется итп. Выводы делайте сами.
Это говорит только то, что ваша конкретная система была заточена на работу с БД и криво от нее отвязана. Системы изначально заточенные на работу без БД, те же генераторы статических файлов - вообще максимально быстры, быстрее их и быть не может чисто конструктивно.
---------- Добавлено 07.03.2018 в 05:19 ----------
Всё чаще мне начинает казаться, что теория плоской земли добралась и до разработчиков.
В 21м веке не понимать зачем нужна БД (и вообще почему пришлось их изобретать) - это.. ппц просто.
Они просто очень хорошо понимают зачем именно нужна СУБД?
И хорошо понимают и различают ситуации когда СУБД не нужна?
😂
Товарищ, который пишет интернет-магазин на статических файлах - отлично прояснил все технические моменты.
И страницы с товаром можно отображать прямо из статических файлов - это будет очень быстро. Понравится и пользователям и Гуглю.
А в самом магазине есть какая нибудь системка с 1С, где учет остатков ведется.
Другое дело, что если товаров тысячи и больше - то, да, для поиска придется использовать полноценную СУБД. Правда для нормального быстрого полнотекстового поиска это должен быть не MySQL, а какая-нибудь специализированная вещь Сфинкс, Мантикора или ЭластикСерч.
И при хорошей посещаемости для отображения динамической части сайта, для корзины и оформления заказов, СУБД предпочтительнее файлов.
Но на небольших объемах - СУБД это оверлишняя вещь. Файловая система будет проще в обслуживании и быстрее отдавать страницы
Другое дело, что большинство программистов (как впрочем и в других профессиях) низкоквалифицированы и работают по шаблонам, которые где-то увидели один раз. А типовой шаблон сами знаете какой.
Поэтому им кажется СУБД верхом прогресса и они представить себе не могут ситуаций, когда СУБД не нужна.
Опытный профи может манипулировать своими инструментами свободно. И выбирать именно то, что лучше для данной конкретной ситуации.
---------- Добавлено 07.03.2018 в 05:24 ----------
У вас магазины без поиска, фильтров, регистрации пользователей?
Регистрация не нужна. И вообще дико раздражает в интернет-магазинах. У меня уже миллион паролей. А спамеры вынуждают не отдавать основной адрес электронной почты магазину.
Поиск прекрасно работает без СУБД.
Нужно только нагенерить заранее файлов для поиска: http://www.tipue.com/search/
В случае больших объемов данных разумеется не подойдет. Но в случае большого наплыва посетителей - хорошо работает, так как нагрузка на клиенте а не на сервере.
---------- Добавлено 07.03.2018 в 05:39 ----------
Вы из какого года нам пишете ? Судя по продвигаемой философии где-то с времен популярности Web 1.0 🤣
http://www.tipue.com/search/
Какой же это web 1.0
---------- Добавлено 07.03.2018 в 06:25 ----------
А если их, товаров, 100000. Или сегодня 100, завтра 1000000, а послезавтра 12
Откуда? Система всегда строится под конкретные задачи.
И на 100 000 и на 100 - это совсем разные архитектуры.
Не, если будет рост со 100 до 100 000 - значит бизнес идет отлично и владелец оплатит новую систему, делов-то.
Регистрация не нужна. И вообще дико раздражает в интернет-магазинах.
А меня раздражает вводить адрес доставки каждый раз, а менеджеры паролей в браузере спасают, что делать будем?
В целом я согласен, что БД может быть не нужна - но это какие-то пограничные случаи типа магазина на 10 товаров (где БД оверхед), либо на сотни тысяч (где БД уже не вывозит).
Адепты статики, вы серьезно думаете, что те, кто топит за БД не умеют странички в файлики нагенерить и поэтому за БД?
А меня раздражает вводить адрес доставки каждый раз, а менеджеры паролей в браузере спасают, что делать будем?
В целом я согласен, что БД может быть не нужна - но это какие-то пограничные случаи типа магазина на 10 товаров (где БД оверхед), либо на сотни тысяч (где БД уже не вывозит).
Адепты статики, вы серьезно думаете, что те, кто топит за БД не умеют странички в файлики нагенерить и поэтому за БД?
Это решается и без регистрации. Запоминаем в куках покупателя, его контакты с адресом в БД. При повторном обращении все поля будут заполнены.
По сути пассивная регистрация получается. Вместо пароля - id в куках
А меня раздражает вводить адрес доставки каждый раз, а менеджеры паролей в браузере спасают, что делать будем?
Так после первого он из local storage берется... вводить ничего не надо.
При этом ваш адрес хранится у вас, а не на каком-то сервере...
Меня прям даже пугает, что такие простые вещи кажутся неочевидными.
Даже моей "наколенной поделке" второй раз оформляя корзину только подтверждаешь все свои данные,
они уже готовые введены. Без всякого использования БД и паролей.
Единственное неудобство тут - если разными устройствами пользуешься.
Это тоже решаемо, но чуть сложнее.
Адепты статики, вы серьезно думаете, что те, кто топит за БД не умеют странички в файлики нагенерить и поэтому за БД?
Да нет, конечно. Просто они привыкли зарабатывать бабки определенным образом.
И не заинтересованы в том, чтобы сделать оптимально.
Клиенту трудно объяснить "чё тут хорошего", зато очень просто распаковать готовый говномагазин
по его выбору, и потом отвечать "ты сам выбрал - вот и результат".
Ответственности меньше, бабок больше. Вполне прагматичный подход.
Модное всё. Современное. Требует хостинга пожирнее, а это постоянные платежи.
Итд итп.
ЗЫ. поиск говорите... есть идея написать аддон к нгиксу для поиска.
Чтобы держал статически в памяти всю инфу и делал нужные выборки.
Это, конечно, тоже очень несовременно :).
Современные "перцы" каждый раз mysql дрючат :)
CMSimple_XH
В целом я согласен, что БД может быть не нужна - но это какие-то пограничные случаи типа магазина на 10 товаров (где БД оверхед), либо на сотни тысяч (где БД уже не вывозит).
На сотни тысяч - как раз нужна.
На такой объеме будет сложный поиск.
Насчет 10 - заблуждаетесь.
Реализовывал на 5 000 товаров на статике.
Прекрасно работало.
---------- Добавлено 07.03.2018 в 13:35 ----------
Просто они привыкли зарабатывать бабки определенным образом.
...
Требует хостинга пожирнее, а это постоянные платежи.
Плюсую.
Сделал сайт еще и хостинг реселлишь. И на любой вопрос про тормоза - предлагаешь тариф подороже.
---------- Добавлено 07.03.2018 в 13:38 ----------
Адепты статики, вы серьезно думаете, что те, кто топит за БД не умеют странички в файлики нагенерить и поэтому за БД?
Думаю, что 95% оппонетов умеют только с СУБД, более того - только с MySQL.
Профессионализм - это умение выбирать лучшее решение индивидуально под задачу.
Так после первого он из local storage берется... вводить ничего не надо.
При этом ваш адрес хранится у вас, а не на каком-то сервере...
Насчёт куков не уверен, а вот localStorage между компами не переносится, даже если логинитсья под той же учеткой в хроме. Куки слететь могут на раз тоже и привет - вводи адрес заново.
Ну. те.е да, хранить-то можно, но какие-то костыли.
Да нет, конечно. Просто они привыкли зарабатывать бабки определенным образом.
И не заинтересованы в том, чтобы сделать оптимально.
Оптимально - это не только разработка, но еще и поддержка. Где все эти популярные интернет-магазины на файлах, если это дофига оптимальное решение, где специалисты, шарящие в них?Это мировой заговор производителей СУБД? Или вы предлагаете самопис, которые в случае bus factor никто поддерживать не возьмётся?
Модное всё. Современное. Требует хостинга пожирнее, а это постоянные платежи.
Итд итп.
О да, в этоху ВДС по 10 баксов mysql на хостинге - это что-то безумно дорогое.
ЗЫ. поиск говорите... есть идея написать аддон к нгиксу для поиска.
Чтобы держал статически в памяти всю инфу и делал нужные выборки.
Это, конечно, тоже очень несовременно :).
Современные "перцы" каждый раз mysql дрючат :)
Ага, хостинг в мускулом - это дорого, а вот хостинг, где можно будет воткнуть свой модуль для nginx'а - он копейки наверняка стоит и администрировать его клиент сам сможет.
Чтобы держал статически в памяти всю инфу и делал нужные выборки.
С языка сняли.
Тот же сайт интернет-магазина, что был мною сделана на статике когда-то при очередной капитальной модернизации стал хранить товары в оперативной памяти. К тому времени там стало уже чуть более 15 000 товаров, но никаких проблем все запихать в оперативку не было, все влазит прекрасно и на недорогом хостинге.
---------- Добавлено 07.03.2018 в 13:44 ----------
Ага, хостинг в мускулом - это дорого, а вот хостинг, где можно будет воткнуть свой модуль для nginx'а - он копейки наверняка стоит и администрировать его клиент сам сможет.
Ну дык VDS/VPS, где можно поставить свое что хочешь, стоит вообще то дешевле, чем shared, где только стандартный PHP+MySQL при тех же доступных аппаратных ресурсах.
---------- Добавлено 07.03.2018 в 13:45 ----------
Насчёт куков не уверен, а вот localStorage между компами не переносится, даже если логинитсья под той же учеткой в хроме. Куки слететь могут на раз тоже и привет - вводи адрес заново.
Ну. те.е да, хранить-то можно, но какие-то костыли.
Они могут храниться очень долго.
Средний покупатель - не чистит свой браузер, скорее напротив, засирает.
---------- Добавлено 07.03.2018 в 13:51 ----------
О да, в этоху ВДС по 10 баксов mysql на хостинге - это что-то безумно дорогое.
Классический интернет магазин, где БД хранения товаров организована примерно как тут /ru/forum/986313 не держит никакую нормальную посещаемость.
Пример с меню еще так себе, на меню нагрузка не велика (правда все равно не понятно зачем на каждый чих базу дергать), а с товарами все еще хуже. Для полноценного фильтра товары хранят по схеме EAV. Хранить так можно и это удобно. Но вот дергать оттуда - совершенно не нужная нагрузка.
Единственное, что может оправдать говноструктуру БД - то что магазин на хостинге за 10 баксов не посещается, значит, нет проблем с тем чтобы держать нагрузку. Правда он и ничего не приносит владельцу.
Серьезные и успешные магазины, которые завязались на жуткую БД того же Битрикса или Маженты - вынуждены оплачивать очень жирные сервера, если им повезло раскрутиться.
С языка сняли.
Тот же сайт интернет-магазина, что был мною сделана на статике когда-то при очередной капитальной модернизации стал хранить товары в оперативной памяти. К тому времени там стало уже чуть более 15 000 товаров, но никаких проблем все запихать в оперативку не было, все влазит прекрасно и на недорогом хостинге.
И во сколько такой сайт обошелся клиенту (ну или сколько в часах ушло)? А во сколько бы обошелся на каком-нибудь woocommerce, magento или на чем там сейчас магазины делают?
---------- Добавлено 07.03.2018 в 13:56 ----------
Я тогда не понимаю, для кого создаются все эти системы на мускуле? Это заговор какой-то чтоли, раз в файлах всё хранить удобнее и "дешевле"?