схема для большой базы данных - PullRequest
0 голосов
/ 02 декабря 2010

Я пытался решить эту проблему недавно, но я не знаю как.У меня есть приложение, которое позволяет пользователям регистрироваться и создавать профили (сколько угодно).Для каждого профиля они могут создавать кампании (сколько угодно для каждого профиля) и для каждой кампании они могут добавлять ссылки (количество ссылок ограничено, но оно в любом случае велико).Каждая ссылка может иметь свои собственные ключевые слова (более 1 ключевого слова).

Очевидная вещь, которая пришла мне в голову, это иметь таблицу для пользователей, одну для профилей, одну для кампаний, одну для ссылок и одну для ключевых слов.Но подумайте об этом, некоторые пользователи могут использовать одни и те же ключевые слова, и я не хочу повторять эту информацию в базе данных n раз.Я не знаю, возможно ли это в MySQL, но я хотел бы иметь поле в таблице ссылок, которая будет ссылаться на идентификаторы ключевых слов в таблице ключевых слов.что-то вроде массива идентификаторов.Мне бы хотелось, чтобы эта реализация была гибкой, позволяя мне легко находить ключевые слова, обновлять «массив ключевых слов» и выполнять определенные вычисления (например, подсчитать количество ключевых слов).Можете ли вы порекомендовать возможное решение о том, как это реализовать?

Просто чтобы еще раз заявить: я использую mySQL и php.Спасибо.

Ответы [ 6 ]

2 голосов
/ 02 декабря 2010

из этого описания я подумал об этих таблицах:

user (id, ...)
campaigns (id, user_id, ...)
links (id, campaign_id, link)
keywords (link_id, keyword)
1 голос
/ 02 декабря 2010

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

Если у вас есть кампания для коряги и флота, и в качестве ключевого слова в ссылке используется «оболочка», это не те «оболочки», которые я использовал бы в качестве ключевого слова в кампании утилит unix.

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

1 голос
/ 02 декабря 2010

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

1 голос
/ 02 декабря 2010

Вы должны создать таблицу для хранения ключевых слов, т. Е.

id (int) keyword (varchar)

и сохранить таблицу связей для ссылок -> ключевые слова, т. Е.

link_id (int) keyword_id (int)

Надеюсь, это поможет!

  • Christian
0 голосов
/ 02 декабря 2010

Есть 2 идеи 1) у каждого пользователя есть свой набор ключевых слов иметь пользовательскую таблицу и ключевые слова в другой таблице с идентификатором пользователя в виде FK.

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

Ссылка по-прежнему будет ссылаться на ключевое слово ID через таблицу соединения, которая будет содержать ключевые слова ID и LinkID

2) глобальные ключевые слова есть ключевые слова, просто есть ключевое слово ID и ключевое слово будет объединяющая таблица для хранения ключевых слов и идентификаторов ссылок, что позволит ссылкам иметь несколько ключевых слов.

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

0 голосов
/ 02 декабря 2010

Вам необходимо иметь таблицу «многие ко многим», в которой хранится идентификатор ссылки, идентификатор пользователя и идентификатор ключевого слова (я предполагаю, что все ссылки имеют ключевые слова)

Тогда вы сможете выполнить то, о чем говорите, просто с помощью обычных операций с базой данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...