Хранение массива в строке (вопрос экспертов по базам данных) - PullRequest
2 голосов
/ 18 июля 2009

У меня есть таблица продуктов с 100000 продуктов, а также таблица пользователей с 5000 записями. и предположим, что пользователь может дать нам отзыв о любой комбинации этих продуктов. Итак, предположим, что он выбирает для сравнения продукты 1,3100,200,400,500 и так далее. (он может отправить нам еще один отзыв о некоторых других продуктах)

Итак, вот мой вопрос, я просто хочу знать, что бы эксперт по разработке баз данных подумал об этой ситуации, когда число продуктов и пользователей велико. Один из способов сохранить эти оценки в одной строке, например: 1 # 5 3 # 4 100 # 5 .... x # y означает, что он дал y звездочек продукту с идентификатором x. Я могу, например, загрузить эту строку голосования в свой php-скрипт и извлечь ее детали.

Таким образом, таблица рейтинга, вероятно, будет иметь такую ​​структуру: id, идентификатор_пользователя, строка_оценки

Другой способ - сохранить эту обратную связь в этой структуре:

голосование Таблица: идентификатор, идентификатор пользователя, дата

poll_details Таблица: голосовать_ид, product_id, голосовать ==> (voice_id, products_id) в качестве первичного ключа, а voice_id - внешний ключ.

(или эти две таблицы могут быть сжаты в одну таблицу, такую ​​как id, user_id, product_id, голосование [id, user_id, product_id] в качестве первичного ключа)

Так что я думаю, что во втором дизайне сделать запрос намного проще, но он потребляет больше места и времени для каждого запроса, также в случае удаления продукта лучше использовать второй дизайн. Что бы вы сделали?

Любая идея ценится.

Ответы [ 3 ]

6 голосов
/ 18 июля 2009

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

думаю, что вы хотите ваш второй подход. Вам нужно подумать о первичных ключах и тому подобном {то есть один и тот же человек может проголосовать за продукт дважды?}

2 голосов
/ 18 июля 2009

Ehsan

Конкатенируя, вы только что убили любую способность, которой обладает БД, навязывать целостность или использовать индекс для эффективного поиска, если пользователь проголосовал за определенный продукт.

2 голосов
/ 18 июля 2009

Сохраняя его в виде строки, например 1 # 5 3 # 4 100 # 5, вы позже усложняете создание отчетов. Вы также должны выполнять некоторые манипуляции со строками каждый раз, когда вам нужно использовать данные. Для такой простой структуры я не вижу выгоды.

Я бы выбрал одну таблицу (id, userid, productid, голосования), но я уверен, что две тоже подойдут.

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