Таблица поиска: лучше? - PullRequest
Новая
       21

Таблица поиска: лучше?

0 голосов
/ 19 марта 2011

Интересно, есть ли лучшая практика или какой-либо принцип при разработке таблицы поиска.

Я намереваюсь разработать абстрактную таблицу поиска, которая может обслуживать множество различных ситуаций.

Например, я называю свою справочную таблицу как masters and slaves таблицу, 

CREATE TABLE IF NOT EXISTS `masters_slaves` (
  `mns_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `master_id` varchar(255) DEFAULT NULL COMMENT 'user id or page id',
  `slave_id` varchar(255) DEFAULT NULL COMMENT 'member id or user id or page id',
  `cat_id` varchar(255) DEFAULT NULL COMMENT 'category id',
  `mns_created` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `mns_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`mns_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;

, поэтому эта справочная таблица может обслуживать отношения этих типов, например, 

Admins and Members
Admins and Pages
Admins and Posts
Post Categories and Posts
Page Parents and Pages
etc

cat_id в masters and slaves таблица опишет и дифференцирует эти категории.например, cat_id 1 - это Администраторы и члены и т. д.

И я вставлю:

  1. идентификатор администратора в столбец master_id и идентификатор участника в slave_id столбце
  2. идентификатор родительской страницы в столбце master_id и идентификатор дочерней страницы в slave_id столбце
  3. идентификатор категории публикации в столбце master_id и идентификатор страницы в slave_id столбце
  4. и т. д.

Но я уверен в этом, должен ли я пойти на это или нет:

  1. ЕстьЭто хорошая практика для таблиц поиска, или многие должны создавать более одной таблицы поиска для разных отношений?
  2. Если я могу сделать таблицу поиска подобной этой, которая является всего лишь одной таблицей поиска для всех, какие последствия у меня будутв будущем?Будет ли эта единственная таблица поиска переполнена, когда содержание моего сайта будет увеличиваться?
  3. Еще одна вещь, которая приходит на ум, - не является ли система тегов решением для таблицы поиска?

Благодаря.

Ответы [ 2 ]

4 голосов
/ 19 марта 2011

Звучит ужасно, как анти-паттерн One True Lookup Table . Google это!

Вот список плохих вещей, с которыми я столкнулся менее чем за 1 минуту:

  • Вы не сможете навязать ссылочную целостность
  • Все отношения должны быть либо многие-ко-многим или один-ко-многим
  • Вы не сможете обрабатывать атрибуты (100 шт. Article_id = 1 продано в store_id = 7)
  • Вы сможете работать только с ключами из одного столбца
  • Стол будет больше (а значит, в среднем медленнее)
  • Индексы также будут больше (следовательно, в среднем медленнее)
  • Это может вызвать ненужные разногласия
  • Статистика оптимизатора станет искаженной
  • Обслуживание базы данных усложняется

Я мог бы легко придумать больше, но я не думаю, что это действительно необходимо;)

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

Используйте отдельные таблицы для ваших отношений. В конце концов, вы все равно это сделаете.

1 голос
/ 19 марта 2011

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

  1. Одна таблица поиска может стать очень большой, в то время как несколько небольших таблиц поиска могут быть загружены механизмом кэширования mysql в память и обрабатываться только оттуда.если вы обращаетесь к специальной категории.
  2. Проще загрузить / перезагрузить / создать резервную копию и т. д. несколько небольших таблиц.
  3. Позже вы можете изменить схему таблицы, скажем, вы хотитедобавить другое поле только для одного типа категории.Вам не нужно добавлять его ко всем строкам в этой глобальной таблице.

Я думаю, что есть несколько плюсов для того, чтобы иметь несколько небольших таблиц, чем одну большую.

...