Как оптимальней будет хранить такие данные в таблице?

Question

[Urukhayy]

Пример:

В ходе использования приложения пользователь собирает фрукты. Всего 18 видов фруктов. За всю историю использования приложения он может и не собрать какие-то виды фруктов, а может и вообще не собрать ни одного фрукта.
Когда пользователь захочет продать какой-либо вид фруктов, фруктов данного вида должно быть не менее определённого числа, скажем - 100.

Как лучше хранить к такой задаче данные в таблице?
1) В виде 19 столбцов (1 для ID пользователя и 18 для видов фруктов), причем если пользователь соберёт лишь один фрукт одного вида, остальные столбцы будут нулями, и попусту существовать (а может он передумает собирать фрукты вообще?).
2) В виде 2 столбцов (1 для ID пользователя и 1 для ID вида фрукта), и множества строк. Каждая строка будет означать наличие фрукта определённого вида.

Answer 1

[Котик Антон]

Таблица с тремя столбцами: ID пользователя, ID вида фрукта, количество.

Comments

[Urukhayy]

В данном способе не будет работать REPLACE. Тогда придётся создавать строку с каждым видом фрукта при регистрации пользователя. А если он не будет собирать фрукты вообще?

[Котик Антон]

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

[Антон Щербаков]

Urukhayy: А в чем суть проблемы?
Не проще ли создать:
- таблица пользователя, с ID и данными авторизации;
- таблица фруктов, с названием и ID;
- таблица пользователь-фрукт, где идет сопоставление ID пользователя, ID фрукта и количество. Зная ID пользователя - мы найдем всего его фрукты, зная ID фрукта - найдем всех пользователей с таким фруктом и т.д.

[Urukhayy]

27cm Алексей Уколов Проблема в том, что не факт, что пользователь обязательно будет когда-либо вообще брать фрукты, и чтобы создать строчку под только что первый раз взятый фрукт, нужно проверить отдельным запросом, не создана ли эта строчка уже.

[Котик Антон]

Urukhayy: Это не проблема. Есть INSERT… ON DUPLICATE KEY UPDATE ...

[Urukhayy]

27cm: В том то и дело, что там не получится UNIQUE значение на ID профиля.

[Котик Антон]

Urukhayy: Там должен быть составной ключ из двух полей (ID пользователя, ID вида фрукта).

Answer 2

[Алексей Уколов]

2) В виде 2 столбцов (1 для ID пользователя и 1 для ID вида фрукта), и множества строк. Каждая строка будет означать наличие фрукта определённого вида.

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

P.S. Оказывается, я невнимательно прочитал второй вариант. Конечно, его нужно заменить на то, что предлагает 27cm.

Answer 3

[Александр Таратин]

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

остальные столбцы будут нулями, и попусту существовать (а может он передумает собирать фрукты вообще?).

И пусть. 18 интов много места не займут.
Добавить новый столбец в будущем не такая уж и проблема, если новые фрукты лепить, зато сама логика работы с базой сильно упроститься.