Using foreign keys in a social network design - good/bad?

In my schema I have normalized my DB and have FKs all over the place because there are so many linked relationships in a social network esp linking users to everything.

Now obviously in social networks performance will make or break it. This means "Read" times are more important then "Write" times. My DB is MySQL with InnoDB for all tables. So the question is:

1) I assume my assumption of better Read than write is what social netorks need?

2) having many FKs (i would estimate almost 30% of the columns in each table have FKs), would this effect Read performance or write performance or both or none?

3) It is better to have 2 sets of tables for each table - one for Selects (Reads) and one for inserts (writes) with different schema so they can be designed accordingly for better performance?

4) Any harm if i make say 80% of my colunms as fks? (keep in mind this is a social network which may or may not have lots of traffic later)

1) I assume my assumption of better Read than write is what social netorks need?

Generally content is read more often than it s written. But it sounds like you're doing a lot of premature optimization.

2) having many FKs (i would estimate almost 30% of the columns in each table have FKs), would this effect Read performance or write performance or both or none?

Declaring foreign keys has very little to do with performance.

Either your database is normalized o its not. Don't try to break the normalizaton until you know you've got a performance problem.

3) It is better to have 2 sets of tables for each table - one for Selects (Reads) and one for inserts (writes) with different schema so they can be designed accordingly for better performance?

Are you talking about implementing materialized views here? Sounds like premature optimization - if you think it might be then use a view to access the data as it is currently, then wait until you know you've got a performance problem before replacing the underlying entity witha materialized view.

4) Any harm if i make say 80% of my colunms as fks? (keep in mind this is a social network which may or may not have lots of traffic later)

No - same asnwers as above - normalise your data. Declare your FKs, wait until you've got a performance problem before you try to fix it.

1) Probably. But use caching, this beats db read performance.

2) Both. FK's imply indexes, and indexes usually affect read performance positively, but increase the time needed for writing.

3) No, and I don't exactly see how to do that. At some point, the data would have to be written into the select table... Again, use caching.

4) No harm if that's how your information is structured.

If you worry about database performance, think about caching the data from your database and not letting your cached data get stale.

Also, do you plan to scale over multiple database servers? Then you need to think about how to synchronize databases, how to propagate changes.

You could use a MASTERS/SLAVE construction.

Setup a MASTER sql-database for writing, and one (or multiple when you would really like to scale) slaves for reading.

That way you your middleware needs to know that SELECTS are done from the SLAVES and basically the rest is done on the MASTER. But this depends on what your using for the back-end.