Облако тегов PHP

Question

Я ищу помощь со схемой базы данных, а не с самим «облаком».

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

Я думал

ID - int(11), unique, auto_incremenet
tag - varchar(20)
imageID - int(11)

предположим, я загрузил изображение и пометил его "Торонто, суши, лето".

запрос будет:

INSERT INTO tags (tag, imageID) VALUES ('$tag[0]', $imageID);
INSERT INTO tags (tag, imageID) VALUES ('$tag[1]', $imageID);
INSERT INTO tags (tag, imageID) VALUES ('$tag[2]', $imageID);

Затем для извлечения я бы выбрал * из тегов, где imageID = $ imagID.

Есть ли в этом недостаток?

Answer 1

Я не вижу никаких реальных проблем с этим подходом, кроме изображений, которые имеют один и тот же тег, имеют повторяющиеся записи в базе данных. Если вы попытаетесь нормализовать, вы получите таблицу, содержащую дубликаты ссылок на другую таблицу, в которой хранятся сами теги, что в данном случае кажется пустой тратой времени (кодирование, объединение и обход таблиц для MySQL).

Одна крошечная оптимизация, которую я рассмотрю, - это порядок ваших столбцов. Сгруппируйте значения int вместе, так как они имеют фиксированную ширину для MySQL, что означает, что их можно искать незначительно быстрее в этом порядке, чем int varchar int.

Answer 2

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

Answer 3

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

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

Сказав это, поскольку сам факт - крошечная таблица, я думаю, вам понадобится МНОГО строк данных, прежде чем вы увидите разницу между varchar (20) и char (20).

Просто мысль. :)

Answer 4

Убедитесь, что в поле imageID есть индекс.

Answer 5

Я бы использовал отдельную таблицу тегов: ТАБЛИЦА Тэгов: tag_id- int (11), уникальный, auto_incremenet tag - varchar (20)

TABLE image tags:
ID - int(11), unique, auto_incremenet
tag - varchar(20)
imageID - int(11)

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

INSERT INTO теги (tag, imageID) VALUES ('$ tag_id [0]', $ imageID); INSERT INTO теги (tag, imageID) VALUES ('$ tag_id [1]', $ imageID); INSERT INTO теги (tag, imageID) ЗНАЧЕНИЯ ('$ tag_id [2]', $ imageID);

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