Помогите придумать, как хранить данные

[Вася Патриков]

Помогите придумать, как хранить данные

Задача в следующем. Есть таблица пользователей, где каждый пользователь определяется по идентификатору id. Пользователи могут периодически "драться" между собой и надо хранить результаты боёв в БД (2:0, 1:3 и т.д.). Так вот никак не могу придумать, как это хранить.
Представим себе таблицу battle_stat, которая хранит эти результаты (это то, как я её вижу, и заранее понимаю, что это как то не очень... кажется). В ней четыре колонки: user, opponent, rate_1, rate_2.

Получается, для пары пользователей (с идентификаторами 555 и 777), которые провели один бой, в таблице будет храниться две строки:

user | opponent | rate_1 | rate_2 |
555  | 777      |     1  |   0    |
777  | 555      |     0  |   1    |

И мне кажется, что это несколько избыточно. Может кто то знает "проверенный способ", как хранить такие данные в удобной форме, но меньшими жертвами ?

 

[vovanium]

а у тебя только эти данные будут храниться?
Ну можешь делать только одну запись, и делать выборку WHERE user = 555 OR opponent = 555 если так не нравится избыточность.
Если же инфы хранится больше то сделать таблицу с боями, плюс таблицу связку юзер_бой

 

[Mols]

Ну тут лучше UNION использовать при выборке.

 

[Alexandre]

Поддерживаю структуру:
Users + Combat

так как бои парные, то надо заносить в таблицу Combat данные для user_id с наименьшим идентификатором, чтиоб не было дублирования информации.

 

[vasa_c]

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

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

 

[Вася Патриков]

Согласен. Конечно, схема предложенная Alexandre мне очень пронравилась... А вот по поводу как выбирать их лучше и апдейтить я как то ещё не думал ))

По идее, если хранить дублированные записи, то выборка будет происходить быстрее т.е. сделать индекс по полю `user` (в вышеописанной мной схеме) и всё будет классно. Однако на ряду с операцией выборки, есть ещё и операция апдейта, которая должна будет затронуть две строки.
А если хранить данные только в одной строке, то апдейт соответственно будет затрагивать только одну строку, но вот при селекте надо будет делать OR (или UNION). А так как скорость для меня имеет большое значение, чем удобство и выборка будет происходить гораздо чаще апдейта, то походу всё таки придётся прибегнуть к избыточности... вообщем никуда я не ушёл )))

 

[Alexandre]

но вот при селекте надо будет делать OR (или UNION).

зачем???
иногда 2 селекта работают быстрее, чем один с OR
а обобщение делайц на клиенте.

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