For example, to model user's favorite food, in normal sense, using a
relationship table would be the answer, e.g. <UserId, FoodId>

The bad thing is: the table might grown very quickly if you have a lot
of users, e.g. consider 100K Users, each user love 100 foods on
average, so there will be 10M rows already. In long term, I am not
sure if the MySQL table reach certain limit then the performance start
to degrade,

in MySQL way, it said:

http://dev.mysql.com/doc/refman/5.0/en/features.html
Handles large databases. We use MySQL Server with databases that
contain 50 million records. ..

So 10M is quite close to 50M in fact, I am not sure if there is a
better method to represent m2m relationship in DB/MySQL.

howa wrote:
> So 10M is quite close to 50M in fact
No it's not.

1 is quite close to 5, only 4 away
10 is fairly close to 50, only 40 away

10M is however 40M away from 50M. Not close at all IMO.

On Nov 5, 9:09 am, howa <howac...@gmail.com> wrote:
> For example, to model user's favorite food, in normal sense, using a
> relationship table would be the answer, e.g. <UserId, FoodId>
>
> The bad thing is: the table might grown very quickly if you have a lot
> of users, e.g. consider 100K Users, each user love 100 foods on
> average, so there will be 10M rows already. In long term, I am not
> sure if the MySQL table reach certain limit then the performance start
> to degrade,
>
> in MySQL way, it said:
>
> http://dev.mysql.com/doc/refman/5.0/en/features.html
> Handles large databases. We use MySQL Server with databases that
> contain 50 million records. ..
>
> So 10M is quite close to 50M in fact, I am not sure if there is a
> better method to represent m2m relationship in DB/MySQL.

There really isn't an alternative for representing a many-to-many
relationship.