- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Раньше в своём самописном движке блога была табличка комментариев к постам. В этой табличке были ячейки id, text, posts_id, где ячейка "posts_id" означала id поста, к которому принадлежит данный коментарий. Выборка нужных комментариев происходила из всех таблицы, в конце sql-запроса я указывал WHERE posts_id='".$post[$i]['id']."'. Таким образом происходил поиск нужных комментариев среди ВСЕХ комментариев в блоге вообще. Это было не оптимально, т.к. комментериев может быть миллион и каждый раз скрипт будет искать из этого миллиона только те, комментарии, которые относятся к выбранному посту. Конечно, к каждой теме записывалось количество имеющихся комментариев. Например, если их было 3, то к sql-азпросу добавлялось LIMIT 3, но если в базе 10.000 постов и там нужно открыть например посто с id 5, то будет проверяться почти вся таблица с миллионом комментариев со всеми вытекающими для процессорного времени последствиями... Конечно, индексы я использую, но не думаю, что они ускоряют работу настолько, чтобы не париться по поводу скорости.
Сейчас я думаю, что лучше создавать для комментариев к каждому посту отдельную табличку. Например, если id поста 125, то для него будет автоматом создаваться табличка comments_for__125. Если id поста 48, то - comments_for__48 и в этих табличках будут комментарии только к постам, которые имеют id 125, 48 и т.д.
Но вот вопрос: MySQl ищет таблицы с такой же скорость как и данные в ячейках или медленнее?
К тому же возникает проблема хранения таких таблиц, т.к. если их будет тысячи, то зайдя в phpMyAdmin они все будут отображаться. Однако, есть решение:
Если в названии таблицы поставить два нижних подчёркивания, то они объединяться в группу таблиц. Например, если сделать так:
comments_for__123
comments_for__124
comments_for__125
Тогда в phpMyAdmin будет отображаться только ссылка comments_for и рядом будет плюсик. Если нужно раскрыть все таблицы, нажимаешь на плюсик и они открываются. Если они не нужны, то можно на плюсик не нажимать и все эти таблицы с комментариями будут свёрнуты.
Такой вариант оптимальный или я чего-то не догоняю?
Как вы организовали структуру комментариев в своём движке? (если не секрет)
Откройте для себя индексы.
Алексей Барыкин, я про индексы знаю давно и использую их. Но они не решают всех проблем.
Что за последствия-то?
По теме - все давно уже придумано до вас: http://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0
Алексей Барыкин, я про индексы знаю давно и использую их. Но они не решают всех проблем.
Проблему, заявленную в стартовом сообщении, они решают.
Абстрактные цифры:
Таблица из 600 записей, содержит дерево из 40 узлов.
Без индексов оно строилось у меня 10 секунд, с индексами 0.02 секунды.
Алексей Барыкин, спасибо, учту.
Но я всё же хотел бы услышать Ваше мнение насчёт предложенной мною выше структуре комментариев. MySQL будет искать таблицы так же быстро как и данные в них?
Конечно, индексы я использую, но не думаю, что они ускоряют работу настолько, чтобы не париться по поводу скорости.
вы жгун ещё тот...
интресно, как этот форум работает со своими 7 миллионами сообщений?
dkameleon, кэш.
кэш.
ппц....
а формируется этот "кэш" каким образом? для каждой страницы каждой темы.
и как часто он "перестраивается", если через минуту вы уже видите мое сообщение?
и откуда берутся данные для "кеша"?
dkameleon, ну вообще-то тут темы не так уж и быстро открываются, как хотелось бы. Неужели не замечали тормозов? Поэтому, логично предположить, что такая вот система, предложенная мною в 1-ом сообщении этой темы, имеет право на существование.
А насчёт кэша, я предпологая, что он используется только для главной страницы и для первых 5-10 страниц каждой категории форума, а для тем используются индексы, т.к. к каждой теме кэш не сделаешь иначе он будет не усокрять а наооборот тормозить скорость загрузки.
ну вообще-то тут темы не так уж и быстро открываются, как хотелось бы. неужели не замечали тормозов?
нет. для такой посещаемости как здесь, все просто летает.
Поэтому, логично предположить, что такая вот система, предложенная мною в 1-ом сообщении этой темы, имеет право на существование.
у вас явные проблемы с логикой :)
вы как шаман в древности - не понимаете явления и объясняете его как вам нравится.
расскажите мне, как вы новые сообщения и поиск организуете, если он будет затрагивать больше одной темы?
а для тем используются индексы
надо же! мы подходим к сути! :)