Вот возникла проблема, есть база MySQL есть несколько таблиц, к примеру одна таблица это все туры какого-нибудь чемпионата, есть пользователи которые хотят делать прогнозы на предстоящие туры, соответственно надо как-то эти прогнозы хранить, и очевидно что для каждого пользователя создавать таблицу это нереально и имхо не правильно, как можно организовать такую таблицу что-бы результаты пользователей хранить в одной таблице?

 таблица на основе которой будет сделан прогноз:

 `foot` (
  `id` int(11) NOT NULL auto_increment,                                                                                             идентификатор строки, он-же номер строки тура 
  `boss` varchar(60) character set latin1 default NULL,                                                                     хозяева
  `count_1` int(11) default NULL,                                                                                                            счет
  `count_2` int(11) default NULL,                                                                                                            счет
  `guest` varchar(60) character set latin1 default NULL,                                                                    гости
  `data` varchar(10) character set latin1 default NULL,                                                                      дата
  `siti` varchar(60) character set latin1 default NULL,                                                                         город
  `stadium` varchar(60) character set latin1 default NULL,                                                                стадион
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=721 DEFAULT CHARSET=utf8 

вот приблизительный вариант таблицы куда хранить прогнозы:

 `user_prognoz` (
  `id` int(11) NOT NULL auto_increment,                                                                                              идентификатор пользователя
  `id_mt` int(11) default NULL,                                                                                                                 идентификатор пользователя в системе
  `count_1` int(11) default NULL,                                                                                                            счет
  `count_2` int(11) default NULL,                                                                                                            счет
  `data` varchar(10) default NULL,                                                                                                          дата игры
  `mail` varchar(60) default NULL,                                                                                                          е-майл пользователя
  `number_str` int(11) default NULL,                                                                                                       номер строки тура какого-нибудь чемпионата
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

Именно так, как вы это сделали.

Вы связали таблицу user_prognoz с таблицей foot с помощью поля user_prognoz.number_str, которое должно ссылаться на foot.id, как я понимаю.
А с пользователями вы связали прогнозы посредством поля id_mt.
Классическая связь многие ко многим.

Зачем Вам разные таблицы для разных пользователей?

Я вот чего боюсь, допустим такой вариант прогноза одного пользователя:

Дата                  Хозяева          Счет     Гости
02.05.2009     Амкар                 0:1     Москва
02.05.2009     Сатурн                0:5    Рубин
02.05.2009     Томь                   2:1      Терек
02.05.2009     Спартак М       0:2         Динамо
03.05.2009     Кр/ Советов     1:3         ЦСКА
03.05.2009     Ростов                 2:1     Зенит
03.05.2009     Химки                  2:2      Кубань
03.05.2009     Локомотив       1:0         Спартак Нч

Я принял данные из формы, начинаю делать insert в таблицу, и мне кажется что сохранится только одна запись(или я не прав), так как каждая последующая строка затрет предыдущую, или в противном случае таблица будет выглядеть так:

 id       id_mt    count_1    count_2   data   mail       number_str  
 1        2            0                1               02.05.2009     49
 2        2            0                5               02.05.2009     50
 3        2            2                1               02.05.2009     51
 4        2            0                2               02.05.2009     52
 5        2            1                3               03.05.2009     53
 6        2            2                1               03.05.2009     54
 7        2            2                2               03.05.2009     55
 8        2            1                0               03.05.2009     56


и вот если добавится еще один юзер, то непонятно как дальше будет выглядеть таблица... То есть если каждый юзер будет иметь возможность записать по 8 записей в БД, четыре раза в месяц, и это только по одному чемпионату, а вот как это будет выглядеть когда юзеров 100 а чемпионатов около 10, 100x32x8x10 = ???   Спасибо.

Это сообщение отредактировал(а) Marlik - 4.5.2009, 21:56

Я вот, хоть убейте не могу понять, что значит мне кажется. Вы проектируете ту логику, какая Вам нужна? Или готовитесь приспособиться к той, какая получится? 

Прирост 256 тыс в год.. А каковы требования к актуальности информации?
Нужно ли хранить прошлогодние прогнозы? Сколь частым может быть к ним(прошлогодним) доступ? Может имеет смысл раз в квартал проводить операцию архивации данных, переносить устаревшие данные из боевой таблицы в архивную или вообще удалять нафиг ввиду ненадобности? 

256 тыс записей вполне потянет даже акцесс на среднего уровня персоналке. даже 2007й эксель(вроде) уже не боится оперировать такими объемами.


Очень хорошо что вы считаете проектируемые объемы. Имея представление о них вы можете выдвинуть аппаратные требования к системе.
Однако стоящих перед Вами проблем я не вижу, ну или не понимаю.

Спасибо, я кажись когда постил, понял немного, мне важно было иметь представление как все будет происходить, и хранится. Ну а, требований  к системе не будет, это будет сайт в нэте. Спасибо.

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