I'm sorry this isn't a question about programming, but i didn't where else to put it, you need to know this up front: i suck at databases, my true love is programming.
ok, so i am about to ask a really noob question:
what goes first?
- create tables, relationships and then insert data? or
- create tables, insert data and then create relationships?

see? the questions sound stupid even to me

anyway i hope you guys can help me. and yeah i will try to get better in databases design and all that.

No 1 is clearly better.

Consider an analogy to the builder of the house.

If relationships are like doors that properly connect rooms (tables), then it is clear that a builder (or architect) should have thought about and built the relationships before building the house. In the absence of such pre-planned relationships, there is the real danger of missing vital relationships and providing unwanted relationships which will only restrict the flow.

Overall, a plan for the realisation stage of the data base (before actual programming) should include relationships.

CERTAINLY BEFORE DATA INSERTION, THE RELATIONSHIPS SHOULD BE IN PLACE.

Some implementors will tell you that building relationships will slow down the one time data insertion but this stems from lack of clarity.

It isn't too difficult.

Sure, nobody is 100% perfect. You can certainly add or change the relationships. But there must be a serious effort to make a plan with relationships before embarking on the insertion process.

OK

IF you're just trying to collect the data atm, with no hard rules about how it should relate & be consistent, then you'd get away with doing tables -> data -> relationships.
But you'll probably quite easily create something un-normalised with plenty of redundancy, and why use a RDBMS at this stage if you don't have the relations, use another storage system/format/medium.

If you have any existing ideas about how things will be used, what constrains should exist (uniqueness, nulls, foreign keys, value limits, etc), then you're almost certainly better off thinking through the relationships, ensuring all the queries you'll want to run can be created (perhaps also checking efficiency, with test data), before you put your real data into the DBMS rather than having to version/take many backups while you massage it to accept new constraints or table reconstruction without relation mistakes or data loss/distortion.