Проектирование базы данных для отношений пользователь-элемент - PullRequest
0 голосов
/ 25 февраля 2011

Я делаю сайт по продаже виджетов. У меня есть таблица для виджетов, каждый из которых имеет несколько атрибутов (имя виджета, стиль и т. Д.). У меня также есть таблица для пользователей. Виджеты имеют уникальные идентификаторы, а пользователи также имеют уникальные идентификаторы, связанные с ними.

Мои пользователи хотят начать «добавлять» виджеты в свою учетную запись. Каждый виджет может быть добавлен к бесконечному количеству пользователей. Поэтому мой вопрос заключается в том, должен ли я создать таблицу, назовем ее User_Widget, которая связывает идентификаторы UserID с WidgetID?

Другой метод, о котором я думал, - это иметь столбец в таблице User со значениями, разделенными запятыми (WidgetID1xQuantity, WidgetID2xQuantity и т. Д.). Если я стандартизирую этот формат, я смогу использовать php для его анализа и внедрения их в массив, который затем может иметь перекрестные ссылки для извлечения информации из таблицы виджетов.

Какой из них быстрее / лучше практиковать? Если я использую метод User_Widget, что произойдет, если несколько пользователей добавят один и тот же виджет? Буду ли я иметь две записи? Разве это не добавляет дополнительных затрат?

Виджет | пользователь wid1 | user1 wid1 | user2

Будет ли поиск по ним (с использованием JOIN и т. Д.) Медленнее, чем по другому методу?

Заранее спасибо за помощь.

Daniel.

Ответы [ 2 ]

5 голосов
/ 25 февраля 2011

Рекомендую новую таблицу с отношениямиБудет работать быстрее

0 голосов
/ 25 февраля 2011

Определенно новое отношение в конкретной таблице.

Помимо других недостатков в предыдущих комментариях, помните, что:

1) Предполагая, что с виджетом связана некоторая информация, вам все равно нужно получить доступ к БД, чтобы получить данные виджета, так что вы на самом деле не много экономите (и, как отмечали другие, анализ CSV является громоздким) 2) Забудьте делать что-то вроде «пожалуйста, перечислите всех пользователей, имеющих X, но не Y и Z в своей коллекции виджетов» - или, по крайней мере, забудьте сделать это эффективно. 3) То же самое для «Выберите всех пользователей, которые имеют одинаковые виджеты, принадлежащие пользователю Z» 4) Что если вам нужно массово заменить виджет X на виджет Y? Или дать всем, у кого есть W, бесплатный Z?

Существует множество сценариев, в которых выделенная таблица дает вам легко описанные SQL-запросы, эффективность, компактность. И мало (или нет) случаев, когда поле CSV «выигрывает».

...