Вопросы Теги

Это действительно стоит того для нормализации пути “Toxi”? (3 нФ)

Я нахожусь на ранних стадиях моего проектирования баз данных, таким образом, ничто еще не является окончательным, и я использую дизайн с 3 таблицами "TOXI" для своих потоков, которые имеют дополнительные теги, но я не могу не чувствовать, что присоединение не действительно необходимо, и возможно я должен просто полагаться на простой столбец тегов в моем posts таблица, где я могу просто сохранить varchar чего-то как <tag>, <secondTag>.

Таким образом резюмировать:

  • действительно ли это стоит проблемы дополнительных левых соединений на 2 таблицах тега вместо того, чтобы просто иметь столбец тега в моем posts таблица.
  • существует ли способ, которым я могу оптимизировать свой запрос?

Схема

CREATE TABLE `posts` (
    `post_id` INT UNSIGNED PRIMARY AUTO_INCREMENT,
    `post_name` VARCHAR(255)
) Engine=InnoDB;

CREATE TABLE `post_tags` (
    `tag_id` INT UNSIGNED PRIMARY AUTO_INCREMENT,
    `tag_name` VARCHAR(255)
) Engine=InnoDB;

CREATE TABLE `post_tags_map` (
    `map_id` INT PRIMARY AUTO_INCREMENT,
    `post_id` INT NOT NULL,
    `tags_id` INT NOT NULL,
    FOREIGN KEY `post_id` REFERENCES `posts` (`post_id`),
    FOREIGN KEY `post_id` REFERENCES `post_tags` (`tag_id`)
) Engine=InnoDB;

Демонстрационные данные

INSERT INTO `posts` (`post_id`, `post_name`)
  VALUES
(1, 'test');

INSERT INTO `post_tags` (`tag_id`, `tag_name`)
  VALUES
(1, 'mma'),
(2, 'ufc');

INSERT INTO `posts_tags_map` (`map_id`, `post_id`, `tags_id`)
  VALUES
(1, 1, 1),
(2, 1, 2);

Текущий запрос

SELECT 
    posts.*,
    GROUP_CONCAT( post_tags.tag_name order by post_tags.tag_name ) AS tags

  FROM posts
    LEFT JOIN posts_tags_map
      ON posts_tags_map.post_id = posts.post_id
    LEFT JOIN post_tags
      ON posts_tags_map.tags_id = posts_tags.tag_id

  WHERE posts.post_id = 1
  GROUP BY post_id

Результат

ЕСЛИ существуют теги:

post_id     post_name        tags
1             test           mma, ufc
5
задан outis 27 July 2012 в 01:57
поделиться

4 ответа

Наличие всех тэгов в различных записях (нормализовало) средства, что вы сможете переименовать тэги, более легко должен потребность возникать и отслеживать историю имени тега.

ТАК , например, переименованный SQL Server связал тэги по крайней мере трижды ( mssql-> sqlserver-> SQL-сервер ).

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

SELECT  *
FROM    posts
WHERE   MATCH(tags) AGAINST('+mma +ufc')

, который возможен также, но менее эффективен с нормализованным дизайном.

(Не забывают корректироваться @ft_min_word_len для индексации тэгов 3 символы или меньше чтобы это работало)

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

можно также сохранить нормализованный дизайн в базе данных и использовать запрос, который вы обеспечили для питания тэгов к Сфинкс или Lucene.

Таким образом, можно сделать историю, роющую с MySQL , fulltext поиски тэга с помощью Сфинкс , и никакое дополнительное обслуживание не будет требоваться.

6
ответ дан 18 December 2019 в 13:14
поделиться

Если вы используете The Varchar Hack, для вас будет почти невозможно запросить данные. Это будет ада, чтобы написать запрос, который точно и эффективно показывает все сообщения с данным тегом (и давайте посмотрим на него, это довольно большой аспект системы мечения): часть точности трудна, потому что вам нужно рассмотреть все возможности для запятая; Часть эффективности трудна, потому что поиск в строке много, намного медленнее, чем смотреть на полное значение поля (Moreso, если вы можете использовать целое число).

Так что да, это намного наверняка стоит.

Далеко за то, что касается вашего запроса быстрее - убедитесь, что у вас есть соответствующие индексы на ваших таблицах. Запустите объяснение на запросе, чтобы увидеть, где находится любое узкое место. Я не думаю, что было бы лучше получить теги для каждого поста, когда вы обрабатываете его, но это может быть - я не уверен, насколько эффективный MySQL на самом деле находится в манипуляциях строки, что это делает, когда вы делаете группу_Concat Отказ

3
ответ дан 18 December 2019 в 13:14
поделиться

Ваш запрос тега будет очень медленным, если у вас был Varchar со списком тегов. Вы бы делали что-то вдоль того, где Post.tag как «% MyTag%» , который не будет работать нигде, а также в поисках индексированного ключа.

[править] Это исследование показывает производительность различных способов выполнения систем мечения (включая FullText Indense) и предлагает где и когда вы хотите использовать каждый.

3
ответ дан 18 December 2019 в 13:14
поделиться

No. После завершения просить PHP все ресурсы будут освобождены, включая ресурсы подключения MySQL.

-121--3460700-

То же самое можно сказать, почему нет Visual Studio 2008 для OSX.

-121--1633301-

Соединение (при наличии правильных индексов) обычно происходит гораздо быстрее, чем при попытке извлечь данные из середины последовательности с разделителями-запятыми в поле даже с помощью полнотекстового поиска. Или вы можете пойти с кучей отдельных полей тэгов (Tag1, tag2, tag3), и запрос все равно будет сложнее (позвольте мне найти 5 полей, чтобы найти, если я использовал этот тэг), и вам нужно будет добавить новый столбец каждый раз, когда вам нужно добавить новый тэг и вы использовали существующие столбцы. Нормализованная структура базы данных - это наилучший и наиболее эффективный способ. Базы данных предназначены для использования соединений. Почему ты не хочешь их использовать, не за мной.

2
ответ дан 18 December 2019 в 13:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: