- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
![Переиграть и победить: как анализировать конкурентов для продвижения сайта](https://d.searchengines.guru/20/95/m6y6akr_hrag2glw__600x314__37965c50.jpg)
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Вдобавок к недавним около программистским архитектурным топикам хочу предложить обсудить (оплевать :)) одну простую модель данных.
Суть в том, что данные для роутинга хранятся вместе с прочими данными в БД (не считая общей адресной маски, описывающей все допустимые адреса). При роутинге после попадания адреса под общую маску (или еще до этой проверки) из него выделяются параметры, прежде всего компоненты пути: /cat[/obj] (obj – это все компоненты после первого вместе с разделяющими их слешами). Затем по выделенным компонентам пути происходит выборка из одной или двух таблиц БД. В таблице первого уровня (таблице категорий, корневой таблице) хранятся слаги первого уровня для cat, в таблицах второго уровня (таблицах объектов) – слаги или числовые идентификаторы второго уровня для obj.
Значение cat идентифицирует не только категорию (запись корневой таблицы), но и соответствующую ей таблицу объектов (для того чтобы несколько категорий «смотрели» на одну таблицу объектов, обычно используются представления). Значение obj не обязательно идентифицирует объект в таблице (каждая категория имеет один из четырех режимов доступа к объектам, включая режим запрета на указание объекта в адресе; см. первоисточник).
Описанного обычно хватает для работы админки (соглашения по формату хранения контента в расчет не беру). Для морды сайта данные для роутинга обычно дополняются, например полем module для хранения имени/номера модуля/контроллера (именованные экшены обычно не используются, т.к. архитектура ориентирована на REST, но в принципе ничего не мешает хранить имя экшена вместе с именем контроллера в одном поле или в отдельном поле) или флагами разрешения GET-параметра, допустим, ?p= отдельно для адресов форматов /cat и /cat/obj.
Обсудить в первую очередь хочется такие моменты:
А что тут обсуждать/оплевывать? Обычная, часто встречающаяся модель с вариациями. Есть маска урла, по ней идет обращение в БД, а уж как там искать - слаги, айди- без разницы
Sly32, маска одна общая, предназначенная скорее для того, чтобы просто сузить границы дозволенного (исключить кириллицу, верхний регистр, левые GET-параметры и т.п. при обработке запросов). Реальный роутинг происходит уже на основе данных из БД.
P.S. Конечно, можно использовать и др. роуты в обычном понимании, но смысл в том, чтобы этого не делать. Чтобы адреса определялись логической структурой БД, например адрес /articles/my-first-article означает, что должна быть категория (точнее коллекция, т.к. через нее должен быть разрешен доступ к объектам) articles в корневой таблице и статья my-first-article в таблице site_articles (вместо префикса site_ может быть и др., но articles в имени таблицы определяется слагом категории).
---------- Добавлено 21.03.2020 в 19:33 ----------
P.P.S. В принципе, как я писал в стартовом посте, модель позволяет, чтобы my-first-article было чем угодно, если установить для категории более мягкий в этом отношении режим.
miketomlin, какую задачу вы решаете? Для чего это все?
Встречал как-то я систему, в ней значит совсем все было в mysql. Шаблоны, какие-то непонятные вставки на PHP, ну и само собой роутинг и контент.
Вес этих самых баз измерялся 10-ками гагабайт для одного сайта. Как вам такое? и тратились на эти костыли 50 - рабочих джунерских рук, чтоб какую-то правку сделать, джун городил новый костыль в очередной 100-той таблице рабочего сайта. Все это коммитилось папашкой, который и городил и только ему было все это понятно.
А теперь к вопросу. В первую очередь нужно делать так и придерживаться того, чтобы большей доброй половине ваш код был понятен. Ваша логика понималась любым человеком со стороны. В противном случае это мёртвый код, который понесет огромные затраты на его поддержку.
CMS пихают роутинг в базу, так что в этом нет чего-то особенного. Но я так понял вы хотите плодить таблицы от глубины. С точки зрения скорости работы это отрицательная часть само собой. Да и при большом кол-ве этих самых модулей, как я понимаю, там будет такая запутанность, что придется городить некий справочник.
Осуждаю! "работа с БД во фронте" не догоняю что вы хотите делать, но еще раз, лучше придерживаться V - шаблоны и только отображение, M - основные функции, все что там у вас выполняется, зависимости и прочее, работа с базой данных, C - прослойка между MV где есть логическая часть Route, прием данных и передача результатов.
Не знаю, что вы хотели тут услышать. Рекомендую Laravel 7, я его обожаю, это просто. Если конечно PHP. Там же роутинг посмотрите, я так понимаю вашу логику можно с коробки сделать.
маска одна общая, предназначенная скорее для того, чтобы просто сузить границы дозволенного (исключить кириллицу, верхний регистр, левые GET-параметры и т.п. при обработке запросов). Реальный роутинг происходит уже на основе данных из БД.
Не претендую, но. У меня вообще никакой маски нет. Правила простые. Сначала предопределенные роуты.
Казалось бы, достаточно на все случаи, если есть программер под рукой. Но, гибкости хотелось, и меньше зависеть от админов сайтов. Поэтому:
. Ранее, часто название соответствующего класс похоже на Request - довольно жесткий контроль урла. Может быть излишне. Секция урла, не может быть отличной от иначе исключение.Примерно такие таблички (DВ данном случает Sqlite, но не важно)
В общем то, такой подход позволяет обработать любой динамический урл заданный админом сайта в админке. Таблица map это просто карта разделов сайта, каждый из которых может иметь набор статей и коллекций colls (категория каталога товаров или др. объект). Иными словами, по урлу /articles/my-first-article, в табличке мап будет только articles, а my-first-article попытаемся найти в другой, при условии, что articles в мап есть. Аналогично с коллекциями. Это накладывает некоторые лишние действия при изменении урла в мап, но все решаемо. Профит, главным образом в том, что админ сайта не парит мне мозг, когда ему надо какой то свой урл сделать вместо /catalog/samosvaly/kamaz-65115, а легко делает /avto/gruzovye/samosval/kamaz-65115. Ну или просто /kamaz-65115, если коллекция самосвалы приписана к морде.
производительность с учетом использования БД
Не поленюсь, несколько строк на коленке накидать:
И выложить результат.Таких разделов сайта не будет слишком много, в данном случае 363 и за 0.24(ms) легко получить 12 разделов 1 секцией имеющих
Т.е. имеем все доступные документы /company/about, /company/contacts, /company/.... Если среди них есть, с текущим урлом, то продолжаем дальше, если нет 404. Всякие бредкрумбы уже готовы.
А у меня так
url.py
вьюха-контроллер по вашему
модели
Задать любую вложенность, расширить модели- элеметнарно. В базе только айди конкретной записи( сам роутинг на основе маски, так как динамическая типизация, только нужно помнить о порядке урлов
А у меня так
Вы с точки зрения программера. Попробуйте, чтобы без обращения к вам, чтобы часть категорий была доступна вместо katalog-tovarov/tablet/... по адресу samsung/tablet/..., другая tablet/cases/..., при том, что в любой момент может появится еще-какой-нибудь/tablet после обновления каталога. Или будет заведена новая категория аксессуаров, где нет брендов. Потом, если получится, посчитайте +/-
Единственно, что напрашивается, если клиента побреете, что сначала бренд и ни как иначе.
Что само по себе, напрягает
А если, еще и статья нужна с урлом /samsung/почему-самсунг-лучше-айфона, а по урлу /samsung/полезное, листинг анонсов статей, которых 100500.
Поэтому, считаю, такого плана роутинг не лучшее решение, тут и программер скажет, ну его, анриал
----
Иными словами - изменения в базе, легко меняют любой урл, начиная с первой секции.
Все что вы описали делается в админке - любые варианты и без прогера. Я привел только часть кода и урлов. В результате так и работает - вложенность категроий до 3. Дальше не делал, нет смысла но там рекурсией можно сколько угодно.
danforth, тут по-моему все очевидно. См. метки темы ;)
SocFishing, немного не в тему. Речь не о том, чтобы все перетянуть в БД (это идиотизм, согласен), а только о том, чтобы перетянуть в БД данные для роутинга (причем не тупо в виде обычных роутов). Чтобы БД стала более самодостаточной, т.е. чтобы в ней хранился не только контент (не считая файлов, относящихся к контенту), но и полностью определялись адреса, по крайней мере простые, соответствующие этому контенту.
timo-71, маска не входит в модель. Но она предполагается. Так обычно работают приложения, чтобы не пытаться «лезть в БД» вообще без каких-либо ограничивающих условий, например я могу в конце маски прописать подмаску для строки параметров (\\?p=[1-9]\\d{0,9})?, чтобы не пытаться «лезть в БД» при наличии левых GET-параметров или левого значения допустимого параметра.
Смысл в том, чтобы не использовать «сначала предопределенные роуты», а перенести и их в БД, т.е. «префиксные» слаги, имена контроллеров (последние легко соотносятся с типами объектов в этих коллекциях, поэтому нет ощущения, что мы вносим в БД какие-то левые имена) и т.п. для коллекций разместить в корневой таблице вместе с собственными данными коллекций, например их названиями («Пользователи» и т.п.).
В общем то, такой подход позволяет обработать любой динамический урл заданный админом сайта в админке.
Да, верно. Только в наших админках обычно запрещен прямой доступ к корневой таблице, чтобы неквалифицированный «админ» не наворотил дел. А если нужно организовать доступ к категориям (записям корневой таблицы), не являющимся коллекциями, то просто создаются представление корневой таблицы, скрывающее служебные поля и записи, и соотв. коллекция для него (см. концовку статьи по ссылке в стартовом посте).
В любом случае это все хранится в БД/решается на уровне БД. Мы не лезем в код админки, а тем более морды сайта, про которую мы вообще можем ничего не знать. Админки или морды может вообще не быть в данный конкретный момент!!!
P.S. Но все же модель не включает описание построения произвольных таксономий (с любым уровнем вложенности и т.п.), она только описывает иерархию «коллекция-объект (элемент коллекции)» и возможность расширения.
---------- Добавлено 22.03.2020 в 17:07 ----------
Если среди них есть, с текущим урлом, то продолжаем дальше, если нет 404. Всякие бредкрумбы уже готовы.
P.S. Предвыборка данных обновляемого объекта полезна для того, чтобы обновлять в БД не все подряд поля, а только необходимые.