Как создать облако тегов для своего сайта на PHP

7 мая, 2008

Создание облака тегов
В этой статье я расскажу и, естественно, покажу пример создания облака тегов для сайта (блога). Основные инструменты – PHP и фреймворк CodeIgniter (подойдет любой другой).

Но, прежде всего, хочу поблагодарить Delchyve за идею.

Итак, переходим к делу.

Вы, конечно, знаете, что облако тегов используется на многих сайтах (в основном это блоги) как элемент навигации. По-сути, облако тегов – это набор ссылок с ключевыми словами, рядом с которыми обычно пишут количество постов, которые относятся к данному тегу.

Чтобы сфокусировать внимание посетителя на наиболее актуальных темах, размер шрифта тегов в облаке меняют в зависимости от количества постов, которые к нему относятся.

Если ваш сайт (блог) использует какую-нибудь CMS, например, WordPress, Joomla и т.п., то вы без труда найдете плагины, которые сами создадут облако тегов на основе ваших данных, а вам останется только разместить его в шаблоне сайта.

Но мы рассмотрим ситуацию, когда сайт пишется «с нуля» и вам нужно сформировать облако ручками :-) .

Прежде всего, вы должны четко понимать, что данные для создания облака мы получаем из базы данных, а способ их получения зависит от ее структуры (взаимосвязей между таблицами).

В качестве примера попробуем сформировать фрагмент такой базы данных для блога.

Мы хотим, чтобы пользователь мог присваивать любое количество тегов любому из постов. При этом один и тот же тег может быть присвоен нескольким постам. В принципе, можно разместить все эти данные внутри одной таблицы, т.е. сделать поле, в котором будут перечислены все теги через запятую. Но такой подход имеет несколько очень существенных недостатков.

Во-первых, информация в таблице будет дублироваться (если один и тот же тег присвоен нескольким постам).
Во-вторых, для поиска придется использовать предложение LIKE, а это очень неэффективно с точки зрения производительности.
В-третьих, простая операция вывода списка тегов потребует ряд дополнительных операций (разбивку строк на лексемы, формирования массива с тегами и т.д.).

Поэтому гораздо удобнее хранить посты и теги в разных таблицах.

Допустим, наша таблица с постами (назовем ее posts) содержит такие поля:

1) id – первичный ключ;
2) title – заголовок;
3) text – текст поста;
4) date – дата;
и др.

А таблица с тегами (tags):

1) id – первичный ключ;
2) tag – имя тега.

Теперь нужно связать таблицы между собой. Т.к. в данном случае мы имеем отношение «многие-ко-многим» (один пост и тот же пост может иметь несколько тегов, а один и тот же тег можно присвоить нескольким постам), то для его реализации нам потребуется еще одна таблица. Она будет называться posts_tags и иметь следующие поля:

1) id – первичный ключ;
2) postid – внешний ключ (связывает запись с таблицей posts);
3) tagid – внешний ключ (связывает запись с таблицей tags).

Каждая запись в таблице posts_tags определяет одну взаимосвязь между таблицами posts и tags.

На рисунке изображены связи между таблицами

Структура базы данных

Рассмотрим, как она заполняется.

Допустим в таблицах posts и tags уже есть какие-то данные.

posts

id text title date
1 post 1 title 1 2008-05-01 19:40:08
2 post 2 title 2 2008-05-01 19:40:39
3 post 3 title 3 2008-05-01 19:41:08

tags

id tag
1 php
2 html
3 java
4 ajax
5 JavaScript

Чтобы присвоить тег html второму посту (post 2), то в таблице posts_tags нужно создать запись:

postid = 2
tagid = 2

Хотим к этому же посту добавить еще тег JavaScript? Не проблема. Добавляем в posts_tags еще одну запись:

postid = 2
tagid = 5

Таким образом, используя эту таблицу, мы может создать любое количество взаимосвязей между постами и тегами.

Теперь переходим к реализации.

Как я и обещал, в качестве фреймворка мы будем использовать CodeIgniter. Но это совершенно не обязательно. Вы сможете легко переписать пример, используя только стандартные функции PHP.

Начнем с контроллера (main.php).

  1. class Main extends Controller {
  2.     function Main() {
  3.         parent::Controller();
  4.         $this->load->database();
  5.     }
  6.     function index() {
  7.         $this->load->model('tagcloudmodel');
  8.         $pageData['tagcloud'] = $this->tagcloudmodel->getTagCloudData();
  9.  
  10.         $this->load->view('header');
  11.         $this->load->view('tagcloud', $pageData);
  12.         $this->load->view('footer');
  13.     }
  14. }

Как видите, он имеет всего один метод – index(), который будет создавать страницу с облаком.

В конструкторе мы загрузили библиотеку для работы с базой данных (строка 4), а в начале метода index() – модель tagcloudmodel (о ней чуть позже).

После этого мы вызываем метод getTagCloudData() модели, который возвращает нам массив со всей информацией, необходимой для построения облака. И затем показываем страницу (строки 10-13).

Отдельно хочу отметить, что для отображения облака нам нужны.

1) Перечень всех тегов. Не проблема, просто читаем содержимое таблицы tags.

2) Количество постов, которым присвоен каждый тег. Тут чуть сложнее. Нужно посчитать сколько раз встречаются одинаковые цифры в поле tagsid (таблица posts_tags).

Теперь рассмотрим модель (tagcloudmodel.php)

  1. class TagCloudModel extends Model {
  2.     function TagCloudModel() {
  3.         parent::Model();
  4.     }
  5.  
  6.     function getTagCloudData() {
  7.         $qGetCloud = "SELECT tags.tag, COUNT(posts_tags.tagid) AS posts_count".
  8.                     " FROM posts_tags LEFT JOIN tags ON posts_tags.tagid=tags.id".
  9.                     " GROUP BY tags.id";
  10.         $res = $this->db->query($qGetCloud);
  11.         if ($res->num_rows() == 0) {
  12.             return false;
  13.         }
  14.         else {
  15.             return $res->result_array();
  16.         }
  17.     }
  18. }

Здесь тоже только один метод (не считая конструктора). В нем мы выполняем один запрос к базе данных и, если данные найдены, возвращаем массив с результатами.

Т.к. запрос выполняет основную часть работы, рассмотрим его подробнее. Условно запрос можно разбить на три части.

1) После предложения SELECT мы указываем, какие данные хотим получить (строка 7). Это имя тега и количество постов, которым он присвоен. (Для подсчета постов используем агрегатную функцию COUNT).

2) Указываем, из каких таблиц брать данные. Здесь мы используем «левое объединение» таблицы posts_tags с таблицей tags, а в условии объединения указываем, что posts_tags.tagid должен быть равен tags.id. Таким образом, MySQL для каждой записи в таблице posts_tags найдет соответствующую запись в таблице tags и подставит соответствующее имя тега.

3) Группируем поля по первичному ключу тега (строка 9). После этой операции в результирующем массиве теги повторяться не будут, а функция COUNT подсчитает, сколько раз встретился каждый тег.

Примечание. Этот запрос вернет только те теги, которые присвоены хотя бы одному посту (т.е. существует запись в таблице posts_tags). Если по каким-то причинам вам нужно вывести все теги (включая те, для которых нет постов), измените порядок объединения таблиц в запросе: .....FROM tags LEFT JOIN posts_tags ON........

Данные мы получили, переходим к созданию представлений.

Для этого примера я сделал 3 представления (заголовок, хвостовик и основная часть). Наверное, это перебор :-) , но для реальных сайтов заголовок и хвостовик обычно повторяются для нескольких страниц, поэтому лучше их сразу отделить.

В заголовке и хвостовике ничего особенного нет, поэтому я только приведу их код.

header.php

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  2. <html xmlns="http://www.w3.org/1999/xhtml">
  3. <head>
  4. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  5. <title>Облако тегов</title>
  6. </head>
  7. <body>

footer.php

  1. </body>
  2. </html>

А вот на основной части (tagcloud.php) остановимся подробнее.

  1. if ($tagcloud === FALSE) {
  2.     echo "Данные не найдены";
  3. }
  4. else {
  5.     $min = $tagcloud[0]['posts_count'];
  6.     $max = $tagcloud[0]['posts_count'];
  7.     for ($i = 1; $i < count($tagcloud); $i++) {
  8.         if ($tagcloud[$i]['posts_count'] > $max) {
  9.             $max = $tagcloud[$i]['posts_count'];
  10.         }
  11.         if ($tagcloud[$i]['posts_count'] < $min) {
  12.             $min = $tagcloud[$i]['posts_count'];
  13.         }
  14.     }
  15.     $minSize = 70;
  16.     $maxSize = 150;
  17.     foreach ($tagcloud as $item) {
  18.         if ($min == $max) {
  19.             $fontSize = round(($maxSize$minSize) / 2 + $minSize);
  20.         }
  21.         else {
  22.             $fontSize = round((($item['posts_count']$min)/($max$min)) * ($maxSize$minSize) + $minSize);
  23.         }
  24.         echo "<span style=\"font-size:".$fontSize."%\">".$item['tag']." (".$item['posts_count'].") </span>";
  25.     }
  26. }

Здесь мы проверяем, найдены ли данные (строки 1-3) и если найдены, начинаем формировать облако.

Прежде всего, находим теги, которые присвоены минимальному и максимальному количеству постов (строки 5-14).

После этого задаем минимальный и максимальный размер шрифта (в данном случае я задал 70% и 150%).

Теперь формируем цикл, который будет выводить теги (строки 17-26). Внутри цикла мы рассчитываем размер шрифта текущего тега (строки 18-23). Тег, для которого найдено минимальное число постов, будет иметь размер 70%, а тег с максимальным числом постов – 150%. Для остальных тегов будут рассчитаны промежуточные значения в зависимости от количества постов.

Результат показан на скриншоте.

Облако тегов

Естественно, для реального блога, каждый тег будет представлять собой ссылку, которая ведет на соответствующую страницу. Но это отдельная тема.

Как видите создать облако тегов совсем не сложно, задача, в общем-то, сводится к одному запросу.

Кстати, ради интереса посмотрите структуру базы данных WordPress. Думаю, вы легко найдете нужные таблицы.

Удачи!

Понравилась статья? Подписывайтесь на продолжение rss link !

Или на мой твиттер twitter link

]]>

Добавьте эту страницу в google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru

]]>

Опубликовано в CodeIgniter, HTML, PHP, Web разработка View Comments

]]>
  • Adds
    Как все это дело реализовать, на самописанном сайте?
  • Создание облака - точно также. Т.е. метод getTagCloudData и структура базы отличаться не будут (если, конечно, вы не захотите их изменить).

    Разница будет в выводе облака на страницы сайта. getTagCloudData возвращает массив с данными, а вам нужно будет сформировать html разметку.
  • Adds
    база у меня как показано на примере в начале. дело в том что у меня естественно нету файла (database), на сколько я понимаю, если будет этот файл отсутствовать, то многие запросы не пройдут, правильно я понял?
  • О каком файле database речь? database.php? В нем находятся только параметры подключения к БД. У вас должен быть свой файл с этими настройками (либо вы указали их прямо в основном скрипте).

    В любом случае, если вы можете подключиться к своей базе, то у вас есть все, что нужно ;)
  • Adds
    ну файл есть подключ. к базе bd.php. а на самописанном файле будет работать классы?
  • Adds
    т.е. на самописанном сайте, извиняюсь за свою невнимательность.
  • caferman
    Спасибо за неплохое решение)
  • Brdm
    А почему бы не сделать облако тегов на файловой базе?Все очень просто. В каждой строке пишется тег, а через разделитель перечень ссылок на страницы сайта или блога.
    Задача скрипта сформировать только анонсы страниц принадлежащих данному кронкретному тегу в строке базы. Это можно встретить в CMS_ках без баз типа http://acvarif.net.ru/ и ей подобных. Если пишется свой собственный скрипт, думаю такой вариант вполне может подойти.
  • По-большому счету, облако в любом случае хранится в файлах, т.к. все данные БД хранятся именно в них ;)
    Использовать файлы напрямую имеет смысл если вы не используете БД вообще. А комбинирование файлов и БД в данном случае приведет к дублированию данных.
  • nomos
    Для ДЛЕ я пользовался хаком, но в целом принцип тот же, в скрипте держим все теги для автозавершения, а в базе ведём уникальные теги и количество совпадений, и в зависимости от количества уже размер шрифта например...)
  • Roman
    шутки по поводу "трудно придумать 10 запросов" не понял
    вот обычный минус тегов через сводную таблицу
    - вывод названий списком с указанием тегов в подписи
    если у вас 10 названий на страницу еще норм
    а 50? а 100? вот вам и 100 запросов
  • В принципе, в отдельных случаях, никто не запрещает применять денормализацию БД. Т.е. в таблицу с названиями добавить поле теги и перечислить их через запятую. Я понимаю, что это дублирование данных и возможны очень неприятные последствия ;) , но это реальная возможность убрать ваши 100 запросов.
    Или использовать, если возможно, кеширование.
  • Очень познавательная статья. Хоть у меня стоит плагин, однако прочитал с интересом, хочу сделать сайт и надеюсь пригодиться.
  • Юрий
    ну добавлять метки в таблицу TAG например можно, а как реализовать таблицу posts_tags, чтобы добавить значения.
    И последний главный вопрос...
    Как вывести эти метки в посте.
  • Давайте уточним, какие метки имеются ввиду? Мета данные о которых говорил MAX? Если да, то использовать таблицу posts_tags в этом случае не нужно. У вас будет 2 таблицы: posts и meta, а отношение между ними - один-к-многим.
    Т.е. в таблице meta нужно создать поле post_id, которое будет использоваться в качестве внешнего ключа (в это поле записывается id поста к которому относится запись в таблице meta).
    Чтобы найти все мета данные, которые относятся к заданному посту, нужно выполнить запрос вроде
    SELECT * FROM meta WHERE post_id=123
  • nomos
    Это всё конечно хорошо, но меня интересует вопрос "автозавершения" тега, если он есть в базе, то есть поле ввода тегов должно выводить варианты дописания слова при вводе первых букв. Я так понимаю, что это должен быть скрипт поиска вводимого значения среди всех тегов базы, так?
  • Правильно. В статье этого нет, но готовых примеров довольно много, например, этот.
  • Petrik
    Я как сделать, если при добавлении поста, новости и т.д., в строку через запятую вводить тэги, добавлять в БД, но если совпадения, не предпринимать действий.
  • Убрать одинаковые теги из строки не сложно.
    1) Разбиваете строку на слова. Результат будет в виде массива.
    2) С помощью array_unique убираете дубли из массива.
    3) Сохраняете данные в базу.
  • Владимир, а где продолжение статьи?
    Чтобы реализовать ссылки и связь ил с полями в таблице с постами.
  • Хорошая статья, НО:
    Для тех, кто все же желает обойтись без использования дополнительной таблицы в БД и соответственно ключей, а тупо писать теги через запятую для каждой записи могу посоветовать мою идею : http://ezhik-v-dele.ru/blog/note/27-Oblako-Tegov
    Используется на нашем сайте (кстате тоже на CodeIgniter), среднее время, затраченное на исполнение алгоритма : 0.0014 с (это при порядка 400 тегах на 100 записей блога.)
  • Не спорю, так сделать можно, но тогда нужно идти дальше :)
    А зачем вообще БД? Если мы её возможностями не пользуемся. Хранить записи и теги можно в обычных файлах (или файле). Ведь при использовании вашего алгоритма вы все-равно должны получить все записи из базы, а потом разбирать теги с помощью PHP.

    Не подумайте, я вас не критикую. Вам нужно было облако тегов, вы его сделали и результат вас устраивает - это главное.
    Но поиск - одна из самых сильных сторон реляционных БД и есть смысл им пользоваться.
  • Роман
    извините за нубский вопрос, но я не понял в чем выигрыш?
    1000 постов например просмотреть добавленную ячейку с перечислением тегов через разделитель(пусть их 30) это 1000 операций
    а просмотреть вашу связующую таблицу 1000 постов * 30 тегов *3 (пусть в среднем используется 3 тега) это почти 100 000 запросов
    разница кратна 100!!!
    или я что то не так понял?
  • Дело в том, что операции выполняются разное время.
    Если теги будут записаны в одной строке через разделитель, то в запросе придется использовать условие Like. Если теги сохранены каждый отдельно, то они просто сравниваются (равны/не равны).
    Для того, чтобы лучше понять проблему попробуйте написать две функции (только без использования встроенных функций для работы со строками):
    1) сравнивает две строки и возвращает true если строки равны, false - если не равны;
    2) ищет указанный тег в строке с несколькими тегами, разделенными запятыми, возвращает true - если тег найден. (напоминаю, функции вроде explode не используете).

    Кроме того, 1000 постов * 30 тегов *3 - это не количество запросов, это количество записей в таблице POSTS_TAGS. Запрос только один. Данные в этой таблице MySQL имеют тип INT, т.е. поиск по ним будет выполняться значительно быстрее, чем по строкам.

    Если будут ещё вопросы, или получатся непонятные результаты, пишите, попробую помочь ;)
  • Вы ошибаетесь насчет тегов, записанных через разделитель. Не нужно никаких LIKE, это все можно легко сделать на пхп, разделив теги explode() и занести их в массив =)
    Вот моя статья про облако тегов на php (codeigniter) http://ezhik-v-dele.ru/blog/note/27-Oblako-Tegov
  • А существуют ли какие-нибудь автоматические русские облака???
  • А что значит русские? С поддержкой кириллицы?
    Это не проблема на сегодняшний день. Если движок сайта (например, тот же WordPress) нормально работает с кириллицей, то и проблем с облаком не будет.
  • Все что вы тут писали для меня полный бред, так как я не програламер :) но хочу иметь на своей доски объявлений облако тегов. В моем понимании это должно выглядеть так:

    Устанавливается php скрипт который собирает статистику потом ее обрабатывает и при помощи инклуда выводит в нужное мне место. Просто и со вкусом, без всяких бла бла бла.

    Желательно, чтоб такой скрипт развивали, были обновления и всякие завороты. Думаю, идея проста.
  • Какой смысл статистику собирать? Вся нужная информация для создания облака есть в базе сразу же после публикации поста.
    А если нужно просто облако, то во многих движках есть встроенные функции, которые его создают (или есть соответствующие плагины).
  • Big_Shark
    По мне так вариант Макса по лучше и по удобнее будет)
    Чего ты так на оптимизацию базы накинулись? Юзайте кэш и будет вам счастья)



    Значит если статья уже имеет 5 тегов и я хочу добавить еще 1, то сначала будут удалены 5 записей из БД, а затем вставлены новые 6? Выглядит немного неэкономно, но с другой стороны всего 2 запроса…

    Эта веть в админки и делаеть пару раз в день а не каждые 5 минут ) так что ничего страшного!
  • Я согласен, вариант Максима, наверное, более универсальный.

    Кэш это отдельная тема. Если он используется, то сравнивать количество запросов нет смысла, т.к. и в том и в другом случае их будет 0.

    Эта веть в админки и делаеть пару раз в день а не каждые 5 минут


    А если речь идет не о блоге, а о сервисе социальных закладок?

    P.S. Я ни на кого не накидывался, просто обсуждали :-)
  • Big_Shark
    Ну в сервисе соц закладок я думаю серваки могут позволить себе по 2 запроса на добовления ) ктомуже это серогно делаеться в любом случае реже чем пользователь ходит по сайту обновляя страницы

    Кэш сейчас должен быть на любом сайте без него не куда.
    Я уже даже если привожу примеры каких то скриптов своих то там всегда включен мой клас кеша по умолчанию и пописано кеширования для всего что работает с БД

    P.S. Я не только про тебя я про всех) все так решили сыкономить 0.005 секунд на запроси что проста жуть)
  • Кэш сейчас должен быть на любом сайте


    Не согласен, это зависит от нагрузки на сайт. При 10 юниках в сутки кэш однозначно не даст никакого эффекта ;) .

    0.005 сек это, конечно, не много. Но запрос тут, запрос там, а в результате дополнительные 20, 30, ... % нагрузки на сервер.

    Но вообще нужно считать, что дешевле: арендовать более мощный сервер или заниматься оптимизацией приложения.
  • Big_Shark
    при 10 юниках в сутки и об оптимизации сайта слишком задумываться не стоит)
    20 запросов эта не реально многа если больше 10 на страницу нужно задуматься о кеши и оптимизации даже не то что задуматься а все срочно перевести на кэш)
  • я имел ввиду, что нагрузка может увеличится на 20% из-за нескольких дополнительных запросов.

    Честно говоря, сложно даже придумать как использовать 20 запросов для одной страницы. Разве что если в сайдбаре куча виджетов.
  • Big_Shark
    Как практика показывает обычна 1 запрос отнимает время а все остальное выполняет очень быстро.
    Сложна придумать даже 10 запросов!
    Хотя я видел скрипт где было 1630 запросов)
    Запросы шли в циклах) После полу часа работы все свялось к 3 запросам в кеш)
  • 1630 запросов


    no comments :-)

    хотя, один раз я написал что-то похожее :-) , было тысяч 10000 запросов в цикле, причем выполнялась вставка данных, но кеш не использовал, т.к. скрипт нужно было запустить только один раз

    1 запрос отнимает время а все остальное выполняет очень быстро


    создание соединения с БД в первом запросе перед выборкой данных
  • Big_Shark
    Хорошо что сервак не упал при 10000 запросов!)
  • Какой сервак? :-)
    Все на локалхосте работало :-) . Это меня попросили игрушку помочь перевести. Все тексты были в базе (SQLight), их нужно было перегнать в текстовый файл, который пропускался через переводчик, а затем результат нужно было загнать обратно в базу.
    В общем, скрипт отрабатывал дольше чем я его писал :) .
  • Хороший пример! Если еще так же подробно распишете как создать для САЙТА двужущееся облако тегов - цены вам не будет!
  • Для движущегося облака тегов видел готовую реализацию на флеше, есть даже плагин для WordPress.
    Только вот на мой взляд пользоваться им не очень удобно, теги которые оказываются на заднем плане получаются очень мелкими. Кроме того, если тегов много удобнее искать когда они упорядочены (по алфавиту). И опять же, непонятно как такое облако будет проиндексировано поисковиками. Скорее всего, никак.
    Но выглядит безусловно очень красиво ;)
  • Критерии "удобства" и "полезности" слишком не однозначны в определении, что очень хорошо продемонстрировано в мультике про "дядю Федора": "... а какая польза от этой картины, например? Очень даже большая! Она дырку на обоях закрывает!..." :)
    Так вращающийся клубок тегов во Флэше для CI можно сделать?
  • Согласен.
  • Ну, вот, сделал человек "3D Culumus" облако тегов Прекрасно работает и очень эффектно выглядит http://6log.ru/page/sm_cumulus Скажем человеку большое спасибо
  • Можно, конечно. Облако будет тем же самым (т.е. флешка та же самая), нужно его только подключить к CI.

    Я как-то писал пост о подключении графиков, сделанных на флеше. Тут принцип будет тот же: подключить готовый флеш ролик, передать ему параметры.
    Но, т.к. я сам с флешем не работал, то без инструкции от разработчика флешки не сделаю.

    А вообще идея хорошая, спасибо :)
  • Давно хотел спросить: Вы не пробовали реализовать такую штуку для CI ?

    Вы не совсем правы, относительно удобства-неудобства. Это ведь, по сути, очень зрелищная "игрушка". Задний план "читать" вовсе даже не требуется, подведи указатель и ссылка сама к тебе "приедет" :) У меня такой стоял на WP-блоге, так я сам минут по десять, при каждом посещении, его с удовольствием "вертел" :). Фон для страницы и флэшки брал одного цвета, а теги контрастного из цветовой палитры темы. Красиво и полезно...

    Нам ведь нужно задержать посетителя? Вот и пусть "поиграется" Все равно кончится "кликом"... Вот бы кто-нить такую забаву к Google adSense прикрутил :)...???
  • Вывод тегов не универсально организован. Если будет присутствовать один тег, количество вхождений которого будет значительно превышать остальные, то оформление станет кривым: один тег будет большим, а все остальные примерно одинакового размера. Сам статью писал недавно по этому вопросу здесь : http://i-novice.net/oblako-tegov/
    Проблема решается простеньким алгоритмом кластеризации. Ссылки на его реализацию можно там в комментариях к статье посмотреть.
  • Огромное спасибо за ссылку!
    Как-то раньше я не задумывался об этой проблеме. Точнее с проблемой я сталкивался (в основном на сервисах закладок), но о том как ее решить почему-то не думал. Наверное работал стереотип: если минимальный размер шрифта будет нормально читаться, а максимальный - не будет очень большим, то все отлично.
    Нужно будет попробовать реализовать что-то подобное, идея в общем-то не простая.
  • Олег
    спасибо за помощь!
  • Олег
    Возникла сложность с внесением тегов в табличку.
    Поле tag в таблице tags у нас UNIQUE.

    Поля postID и TagID у нас UNIQUE в таблице post_tags.
    Вносим массив тэгов, которые пользователь внес:
    INSERT INTO tags (tag) VALUES ('$tags[$i]')
    $tags_id = mysql_insert_id();


    но при внесении в post_tags возникают сложности:
    INSERT INTO post_tags (postID, TagID) VALUES ('$post_ID', '$tags_id')
    в таблице имеем:
    9 1
    10 2
    10 10
    11 0
    11 11

    как мне узнать id тега, который уже есть в таблице tags, чтобы его внести в таблицу post_tags?
blog comments powered by Disqus ]]>