Kao prvo, ako ste u mogućnosti, koristite radije Oracle, nego MySQL. Pošto pretpostavljam da niste u takvoj mogućnosti, da vidimo onda šta se da uraditi sa MySQL-om.
1. Opcija pod a) mi se čini neprihvatljivom, jer se krši sa svim pravilima optimizacije. Što bi više tabela rasla, smanjivale bi se performanse.
2. Ni opcija b) nije baš najidealnije rješenje (ako sam te dobro shvatio), jer bi onda imao previše tabela. Kako bi vršio operacije sa tim tabelama? Morao bi negdje čuvati nazive tih tabela ili ih raditi po nekom univerzalnom ključu, npr. tabela_user1, tabela_user2 ili slično. To je malo nezgrapno za izvesti, a i ne bi dalo željene rezultate.
3. Ne znam kako si zamislio insert i update podataka pri velikom opterećenju baze, ali vrlo lako je moguće da dođe do asinhronizacije prilikom istovremenog pristupa određenim tabelama. Naravno, moguće je to uraditi i osigurati se od toga koliko toliko (sa LOCK-ovanjem npr.), ali tada dolazi do pada performansi. Ne znam detaljnu speficikaciju vašeg projekta i zahtjeve pod kojim uslovima bi čitava aplikacija trebala raditi, ali morate dobro paziti sad na početku da dobro isplanirate strukturu baze, da njen model bude fleksibilan i da normalizacija bude minimalno na trećem nivou.
Za početak, ja bih razdvojio podatke o userima i podatke o plaćanjima u odvojene tabele:
tabela_users - useri: podaci o userima, stavite neki primary key kao index, npr. user_id
tabela_placanja - plaćanja: podaci o plaćanjima pojedinih usera, takođe stavite neki primary key kao index, npr. placanja_id
tabela_lookup_users_placanja - lookup kombinacija sa user_id i placanja_id
Toliko od mene.
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA