Дизайн базы данных для hashtags в MySQL

Question

В настоящее время я работаю над системой, которая позволит использовать хэштеги на нашем сайте, и у меня возникли проблемы с тем, как наилучшим образом и наиболее эффективно хранить хэштеги в базе данных. Дизайн должен быть настроен таким образом, чтобы его относительно просто получить сообщения, соответствующие условиям поиска (например, в Twitter при нажатии ссылки на хэштег, и на нем показаны все твиты с этим хэштегом). Хэштеги будут храниться в db, извлекая термины из содержимого созданных сообщений (также сопоставимые с твиттером) и вставляя их. Как вставить их, конечно, это проблема под руку: На данный момент я разрываясь между 2 возможными конструкциями:

1) Моей первой идеей дизайна (и, возможно, более обычным) является конструкция 3-таблицы:

• В первой таблице просто хранится содержимое сообщения и другие связанные с ним данные самому сообщению (им уже используется таблица, подобная этому).
• Вторая таблица просто хранит новые используемые хэштеги, в основном функционирующие как поиск всех хэштегов, которые были использованы.
• Третья таблица представляет собой таблицу, которая определяет отношения между хэштегами и сообщениями. Таким образом, в основном это будет простая таблица, в которой будет иметь один столбец с идентификатором сообщения и другим столбцом для идентификатора одного хэштега, который мы сохранили в предыдущей таблице. Таким образом, сообщение, которое имеет, например, 3 хэштега, будет иметь 3 строки в этой таблице, 1 для каждого хэштега, с которым он связан.

2) Вторая конструкция 2 стола дизайн:

• та же таблица с почтовыми данными, хранящимися в нем, как выше.
• Вторая таблица представляет собой смесь 2-й и 3-й таблиц в первом дизайне: она хранит данные между отношениями хэштегов и сообщений, но вместо хранения нового хэштега в таблице присваивает ему идентификатор, он просто сохраняет фактический hashtag (например, «#test») сам вместе с идентификатором сообщения. Та же концепция здесь применима, что , если сообщение имеет 3 хэштега в нем, оно будет хранить 3 отдельных строки в таблице .

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

Также, когда я пытаюсь создать страницу поиска для hashtags, мне нужно использовать меньше JOIN, так как мне не нужно будет искать идентификатор искомых терминов, а затем перейти в другую таблицу и найти связанные записи с этим Я БЫ.

Кроме того, при попытке просто перечислить хэштеги сообщения, одна вещь, которая будет раздражать, заключается в том, что хэштеги могут распечатываться иначе, чем пользователь может стилизовать их в своем сообщении. Так, например, если пользователь добавляет #testing, но другой пользователь ранее ввел сообщение с #TeStIng, хэштег для сообщения затем распечатал #TeStIng, так как это было бы сохранено в таблице поиска базы данных. Конечно, вы можете сделать его чувствительным к регистру, но в поисках #testing и #TeStIng следует считать одним и тем же хэштегом, чтобы он мог запутаться. Или я ошибаюсь? Кто-нибудь имеет предложение о том, как избежать этого сценария?

С другой стороны, моя забота о втором дизайне таблицы заключается в том, что я боюсь, что она может стать неэффективной, если таблица станет огромной, поскольку поиск строк происходит медленнее, чем поиск целых чисел (что я бы делал с первым дизайн). Однако, поскольку мне пришлось бы использовать больше JOINs в 1-м дизайне, действительно ли была бы разница в производительности? Чтобы быть ясным, при поиске самих строк я бы использовал оператор =, а не LIKE.

Аналогично, я бы предположил, что первый дизайн более эффективен, если я хотел бы делать запросы о самих хэштегах, например, сколько сообщений использует определенный хэштэг и тому подобное, хотя это было бы не очень сложно с 2-й дизайн, я просто задумываюсь об эффективности снова.

Любые мысли о том, что может работать лучше? Самое главное, что эффективно искать по hashtag, поэтому, например, я пытаюсь найти сообщения с #test, связанные с ними. В идеале я также хотел бы получить хэштаг сообщения из базы данных, поскольку он был стилизован пользователем в сообщении. Все остальные вопросы и функции, связанные с анализом хэштегов, являются вторичными на данный момент.

Answer 1

Чисто с точки зрения нормализации базы данных ваш второй дизайн не был бы в 3NF. Есть причина, почему вы полагаетесь на весь основной и ничего, кроме ключа. Если что-либо в таблице хеш-таблицы изменяется, что оказывает непосредственное влияние на стол почты, вы получаете логическую несогласованность. Например, таблица хэштегов имеет два ряда: один с хэштегом #politics, а другой с hashtag #politic. Скажем, человек, создавший сообщение для второго хэштегажа, решает отредактировать свой пост и обновить хэштег до #politics (возможно потому, что они сделали опечатку). Какую строку вы обновляете?

Что касается производительности, я бы не стал беспокоиться об этом, по крайней мере, с первым дизайном. Ваша база данных (например, почти все основные реляционные dbms там сегодня) опирается на нечто, называемое двоичным деревом поиска (или, более конкретно, red-black tree), чтобы оптимизировать стоимость вставки/удаления/поиска в таблицах базы данных, когда вы правильно индексируете эти значения , Он может дополнительно оптимизировать это с помощью O (1) (хеш-таблиц поиска) в некоторых случаях использования текстового поиска, или вы даже можете сделать это в хранилище кеша ключа/значения, например Memcached/Redis, по дороге. По большей части индексирование хэштегов для более быстрого поиска сообщений, использующих эти хэштеги, - это, безусловно, дизайн, на который вы хотите пойти. Поскольку самый большой фактор затрат заключается не в поиске одного хэштега (большинство поисков будет иметь один хэштэг, который я предполагаю в этом случае), но получаю все сообщения, содержащие этот хэштег.

---

Что касается решения регистронезависимое поиска часть вашего запроса СУБД, скорее всего, имеет некоторые опции сортировки, которые вы можете указать в вашей схеме (например, utf8_general_ci), где ci представляет собой сравнение без учета регистра в схеме , Значение, данные будут храниться как есть, но при сравнении в запросе с другим значением MySQL будет выполнять сравнение символов без учета регистра.