Как представить отношения между двумя элементами в БД?

Question

я и мои коллеги разрабатываем веб-сайт с идеей, аналогичной Stackoverflow, но для отправки заданий (и для внутреннего использования). Сегодня утром мы поговорили о задачах с тегами и не могли понять, какой вариант будет самым быстрым, или если мы что-то не упустили.

Давайте представим таблицу с тегами, которая будет динамически обновляться в зависимости от пользователей. Пользователи могут создавать любые теги, и они будут добавлены в эту таблицу. Структура следующая:

• ID
• имя
• Количество * * 1 010

Я сейчас вернусь к фактической точке. Если вы нажмете, например, тег «PHP», он покажет вам другую страницу со всеми задачами, помеченными как «PHP». Нечто подобное этой странице . Важным является список связанных тегов . Как представить это в базе данных?

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

1. Выберите все задачи с тегом "PHP" и проверьте, какие другие теги они содержат. Через несколько лет мы можем получить ответ от сервера.

2. Создайте таблицу с cols tag , related tag , count , где будут все возможные отношения тега. Единственная проблема, которую мы видим - это двуличие. Мы могли бы иметь тег PHP и связанный тег DB2, но мы могли бы также иметь тег DB2 со связанным тегом PHP, который, конечно, является тем же самым отношением, с тем же количеством.

Мне действительно нравится вариант № 2, но без двуличия. Возможно, вариант, при котором не было бы такой тесной связи между тегами (как если бы не было никаких «первичных» и «вторичных» тегов), мог бы работать лучше всего. Я не совсем уверен в этом и не хотел бы моделировать то, что не сработало бы в будущем или было бы слишком медленным, если бы было, например, один миллион тегов.

Мы будем использовать PHP и mySQL или DB2, но, думаю, это не имеет значения.

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

Заранее спасибо.

Answer 1

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

Если вы делаете это в БД, тогда ваш второй подход - лучший. Вы можете даже подумать о создании индекса, который поднимается в поле тега и спускается в поле счетчика связанных тегов.

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

Answer 2

Я предполагаю, что вы представляете отношение тега задачи, используя отдельную таблицу (просто идентификатор задачи, идентификатор тега), поэтому первый вариант, который вы опишите, будет «простым» соединением таблицы задач с таблицей тегов. используя таблицу отношений тега задачи. Я боюсь, что мои знания SQL немного иссякли, поэтому я бы не стал доверять себе, чтобы дать вам совет о том, к какому типу соединения INNER / OUTER / LEFT / RIGHT это потребуется, и о том, какой тип производительности вы можно ожидать от этого при правильном построении индексов и так далее. Попробуйте, это, вероятно, лучшее, что можно сделать ... Оператор sql может быть построен с использованием Visual Studio / Access /, возможно, что-то еще.

Я бы предположил, что ваш второй подход быстрее, если вы ожидаете, что в вашей БД будет много предметов. Тем не менее, я бы определенно рекомендовал вам сделать правильное тестирование производительности, чтобы определить это, а не угадывать. В любом случае, вы можете избавиться от двойственности, сохранив только одну из пар тег-тег (например, db2-php, а не php-db2). Какой из них сохранить, можно определить, упорядочив их, например, по идентификатору, чтобы всегда хранить их с тегом с наименьшим идентификатором.

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

Answer 3

Я полагаю, что если у вас есть таблица «Теги, назначенные для Задачи X» с правильными / умными индексами, поиск тегов, как описано в варианте 1), не займет так много времени с использованием объединения. Это был бы самый динамичный подход.

Второй вариант предоставит вам средства для выполнения запроса «Тег X часто используется вместе с тегами Y и Z» и может быть статически заполнен при создании новой задачи, однако для этого потребуется больше времени, например, когда тег добавлен или удален из задачи. Это было бы автоматически для подхода 1).

Подход 2) (как вы это описали) не позволил бы вам точно связать теги для текущей задачи, поскольку вы не сохраняете идентификатор задачи. Однако, если вы сделали это, вы находитесь в той же точке, что и подход 1).