Okay im not sure the best way to structure this i have a table called campaigns, which basically is a higher level for a list of products now i have products tables called games, wallpaper, screensaver, each of those tables is a different structure but they are all considered products. whats the best way to define this? like if i need to see all products in a campaign how can a create the database to be more effective then hardcoding the sql statement to say "select * from games, wallpaper, screensaver". so the tables i have are like this
Campaign
-id
-name
-launchdate

Games
-id
-campaign_id
-name
-platform

Wallpaper
-id
-campaign_id
-name
-colordepth

and so on...Im just looking for a better way to relate these

My first idea is:
Campaign:
-campaign_id
-campaign_name
-campaign_launchdate
Product:
-product_id
-product_price
-product_name
etc
Game:
-product_id
-game_platform
Wallpaper:
-product_id
-wallpaper_colordepth

And product_in_campaign:
-campaign_id
-product_id

With such design you'd need also to play with indexes to make things faster, but it shouldn't be a big problem.
Why I made 'products'. I think that in most cases when you need products of many kinds together, their 'product' (not specific ones) will be important, things like name or price.
Also, keeping campaign_id in all specific tables makes it hard to have one product in more than one campaign. I don't know if you need it, but it's good to be flexible.

Okay but then how do i look up all products in a campaign? in the product_in_campaign table how does product_id know which product type it refers to?

It depends. If you just want their names ('product' atributes):
select * from product natural join product_in_campaign where campagn_d=1;
If you want all products with their special attributes. BTW, I don't see an easy way to print all this in one table or any other form when different types have different number and meaning of attributes. But if you really want it, you can't do it using one simple command, you'd rather need to select from all special tables (probably join them with 'products'), sort (SQL 'order') and make in your program a kind of merge sort.
If different types of products can be shown separately, you can repeat something like this for all special types:
select * from product natural join game natural_join product_in_campaign where campaign_id=1
Note that in this case indexes can really speed things up.

Quote:

in the product_in_campaign table how does product_id know which product type it refers to?

It does not. It's a trade-off. If you need to know which type is it, you can add 'type' field in 'product' table.

OKay ive come up with a unique but i think effective way of handling this problem.
ive created a total of four tables
product - which is just the product name and type
product_types - which is just an id and a product type name
product_headers - which is an id a product_type id and a header name
product_data - is a product header id and a product id and the data for the header

this way all the different tables are linked and when i wanna create a new product type i dont have to create a new table, plus it makes it alot easier to use in an application i can pull product types from the product types table sort by headers and stuff. this makes the whole database really flexible. What do you think?

You're getting close to name-value type of design.
Probably your mathod is OK for your data, even if you'd need to keep all data as strings. I don't know how you plan to keep header structure and data. If you plan to have something like
1 1 name price color
in product_headers and something like
1 1 some_name 12.5 blue
in product_data, you can have 2 problems: product_data will have a fixed number of columns. If you need to add a new type with more attributes, you'd need to modify the table. On the other hand, you'd have many NULLs when a type has less atributes.

If you'd like to have a very flexible configuration, use something like:
product: product_id, product_type
product_type: type_id, attribute_id, attribute_name (string) (one type described by many rows)
product_description: product_id, attribute_id, attribute_value (product described by many rows)

Ok, it's not a perfect impelmentation of this design, but you should get the idea.

no the headers are like columns and the data is data for a products column so

we have a product table like
---------------------------------------------
| id | type | name | descriptiont |
---------------------------------------------
| 1 | 1 | a_name| blahblabh |
---------------------------------------------

product_type
------------------
| id | name |
------------------
| 1 | game |
------------------

product_header
----------------------------
| id | type_id | name |
----------------------------
| 1 | 1 | Size |
----------------------------
| 2 | 1 | Codec|
-----------------------------

product_data
------------------------------------------------------------
| id | product_id | header_id | header_data |
-------------------------------------------------------------
| 1 | 1 | 1 | 56k |
------------------------------------------------------------
| 2 | 1 | 2 | swf |
---------------------------------------------------------------

Ah...so it looks quite good. Good luck!