SQL: идеальный тип механизма (MyISAM против InnoDB) и тип данных для уникального текстового столбца.

Привет, у меня есть веб-сайт php, использующий mysql, и у меня есть таблица со столбцом под названием «Имя». Я намерен, чтобы он имел следующие функции:

  • Это должен быть тип varchar(N), как и обычные имена.
  • Он может быть длинным, но никогда не должен содержать так называемых «описаний», поскольку они находятся в другом поле, поиск которого меня не интересует. (возможно, в будущем, что я мог бы даже просто поместить в другую таблицу)
  • Он ДОЛЖЕН быть уникальным и доступным для поиска, что делает его подходящим кандидатом в качестве первичного ключа.
  • Поиски являются простыми типами, подойдет только такое поведение, как mysql LIKE %keyword%.
  • Эта таблица (очень) часто читается, новые строки вставляются время от времени, строки удаляются/обновляются очень редко.
  • Многие другие таблицы ссылаются на значения в этой таблице, и в идеале я хочу иметь ограничения внешнего ключа для других таблиц, что заставляет меня хотеть использовать InnoDB.

Мой вопрос в том, должен ли я использовать MyISAM или InnoDB для этой таблицы? Также нормально ли использовать мой не очень длинный varchar в качестве первичного ключа, учитывая частоту чтения/объем используемой памяти/количество предупреждений в Интернете о первичных ключах varchar?

Но я действительно хотел бы извлечь выгоду из ограничений внешнего ключа, которые предлагает InnoDB, или я должен просто беспокоиться об этом на уровне php?

В частности, меня беспокоят возможности полнотекстового поиска MyISAM. Я попытался прочитать официальные веб-страницы mysql, чтобы понять, для чего это нужно, но не смог понять достаточно, чтобы судить, выиграет ли от этого моя ситуация.


person Lim    schedule 13.05.2011    source источник


Ответы (1)


Короткий ответ: InnoDB с суррогатным первичным ключом.

Длинный ответ

Поскольку вы предполагаете, что таблица со столбцом Name будет иметь много дочерних таблиц, я бы рекомендовал суррогатный ключ с использованием INT UNSIGNED (или даже BIGINT UNSIGNED, если ваши данные это подтверждают). Таким образом, во всех ваших дочерних таблицах не требуется иметь столбец Name, что экономит место.

В InnoDB короткие первичные ключи — лучший вариант, поскольку первичный ключ включен во все вторичные индексы: http://dev.mysql.com/doc/refman/5.1/en/innodb-index-types.html

FULLTEXT индексы не требуются для простого LIKE('%keyword%') сопоставления. Они помогают, если вы заинтересованы в сопоставлении естественного языка, которое вы не указали в качестве требования.

person Chris Morgan    schedule 13.05.2011