Rick wrote:
> I'm very, very new to mysql and I've been toying with it the last
> couple weeks. I've hit upon a theoretical question that I would like to
> run by more experienced users.
>
> One of the things I've been doing to teach myself is creating databases
> and tables that might be similar to databases powering big, popular
> sites like Flickr or Digg. For example, I created a user table (id
> [primary key], name, nickname, email, location, birthday, profile,
> etc.) and then played around with querying it in various ways.
>
> One of the things I did to learn how to use "join" was to create a
> separate table for blocked users. Sites like Flickr and Digg often give
> users the ability to block other users. The way I implemented this was
> to create a table with the blocker's id and the "blockee's" id. Using
> that, I can query the blocked users table and cross-reference it to the
> user list and come up with the list of blocked users for any specified
> user. Pretty cool.
>
> So I wonder. On a big site with a million+ users, would having to query
> a separate table for a list of blocked users like that bog down the
> site or would it be preferable (in terms of speed and efficiency) to
> add a field to the user table that lists the id numbers of that user's
> blocked users, sort of a pseudo-array that I collapse and expand when
> needed (e.g., a blocked user array-like list might look like
> "150|11516|61878|9091|41064" etc.
>
> Any thoughts? Or am I still so new at this that this scenario doesn't
> make sense?
>
> --Rick
>

First of all, you should check into database normalization. It helps
understand how to design databases.

Additionally, it is much more efficient to let the database do the
searches rather than try to explode a field yourself, especially when
you get into a lot of id's.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================