Dropping out all FKs from my write tables

I have some very heavy write intensive tables (user tracking tables) which will be writing nonstop. Problem is on a fully normalized schema I will have 16 foreign keys. Some keys are purely for lookup references, some are imp like linking user ID, user session ID, activity ID, etc.

With this many FK on a write intensive table performance is an issue. (I have a user content website which needs near to re开发者_开发技巧al time updates). So I am planning to drop all FKs for these write intensive tables but before that I want to know how else can i link data? When people say in the code, what exactly are we doing at the code level to keep data linked together as i assume in the application we cannot have relationships?

Secondly, if I dont use FKs I assume data will still be consistent as long as the the corect ID is written? Not like if member ID is 2000 it will write 3000 instead if no FK is used for whatever reason?

Lastly, this will not effect joins right? While i hope to avoid joins I may need some. But i assume FKs or not joins can still be done as is?

Secondly, if I dont use FKs I assume data will still be consistent
as long as the the corect ID is written?

Yes.

Lastly, this will not effect joins right?

right.

When people say in the code, what exactly are we doing at the 
code level to keep data linked together

This is the real question. Actually, the really real two questions are:

1) How confident are you that the incoming values are all valid and do not need to be checked.

2) How big are the lookup tables being referenced?

If the answers are "not very confident" and "really small" then you can enforce in code by caching the answers in the app layer and just doing lookups using these super-fast in-memory tables before inserting. however, consider this, the database will also cache those small tables, so it might still be simpler to keep the fks.

If the answers are "not very confident" and "really huge" then you have a choice. You can drop the FK constraints, knowingly insert bad values and do some post-job cleanup, or you can keep those fks in the database because otherwise you've got all of that bad data.

For this combination it is not practical to cache the tables in the app, and if you drop thee fks and do lookups from the app it is even slower than having fk's in the database.

If the answers are "100% confident" then the 2nd question does not matter. Drop the fk's and insert the data with speed and confidence.