Как спроектировать таблицу под задачу?

Лексеич

Московский калмык
Как спроектировать таблицу под задачу?

Задача: грубо говоря лотерея "5 из 36".
Пользователи вводят по пять чисел.
Когда розыгрыш, идет генерация 5 чисел. Дальше необходимо выбрать тех, кто угадал 5, 4 и 3 номера.

Имеется таблица такого вида:
[sql]
CREATE TABLE lottery_next (
user_id bigint(15) DEFAULT '0' NOT NULL,
n1 tinyint(2) DEFAULT '0' NOT NULL,
n2 tinyint(2) DEFAULT '0' NOT NULL,
n3 tinyint(2) DEFAULT '0' NOT NULL,
n4 tinyint(2) DEFAULT '0' NOT NULL,
n5 tinyint(2) DEFAULT '0' NOT NULL
);
[/sql]

Выборка совпадений по 5-ти номерам проблем не представляет:
[sql]
(select * from lottery_next where
n1 in ($result[0],$result[1],$result[2],$result[3],$result[4]) and
n2 in ($result[0],$result[1],$result[2],$result[3],$result[4]) and
n3 in ($result[0],$result[1],$result[2],$result[3],$result[4]) and
n4 in ($result[0],$result[1],$result[2],$result[3],$result[4]) and
n5 in ($result[0],$result[1],$result[2],$result[3],$result[4]));
[/sql]

а вот как быть с 4 и 3 совпадениями. Ведь порядок введенных пользователем номеров может не совпадать со сгенерированными. Есть мысль тупо выбрать все данные из базы, отфетчить и пройтись сравнением массивов, но хотелось бы сделать выборку не всех, а нужных. Имхо так быстрее будет да и рациональнее. А вот как это реализовать пока не могу понять. Помогите, люди добрые.. :) Поделитесь мыслями.
 

bgm

 
Э... На мой взгляд, мягко говоря, - неправильная модель базы.
Я бы делал такую таблицу:
user_id - пользователь
joke_id - идентификатор розыгрыша
range - порядковый номер числа (если порядок важен)
number = собственно одно из введённых чисел.
 

Лексеич

Московский калмык
bgm
joke_id не нужен, ибо розыгрыш один и хистори не ведется.
range тоже не важен, ибо порядок ввода может быть произвольным. хех... всё гениальное просто... выбираем данные по пяти номерам, а потом сортируем полученных юзеров по количеству номеров для них. :) Спасибо. Вариант действительно хорош. Даже если и попадется "мусор" в виде одного или двух угаданных, все-равно существенно лучше такой вариант, чем мой..
Единственное, пришлось добавить ticket_id, на случай нескольких билетов.
 
Сверху