im no amature, i assure you. i am simply wanting to make sure i have the right ideas for optimal performance.

in reply to fodder:

the thing here is, one item may need like 6 materials and 4 skills to create it.

[edited by - Shumani on July 30, 2003 12:12:03 AM]

That''s different.

But ONLY in terms of logical representation, not the ds or algorithms.

What you have to do have a material-item table. Which will have a item-id and material-id and possibly quantity of that material.

Now, in this table, item-id and material-id are foreign keys -- not originally from this table. Not only that both of them together form a composite key. A key/id which is formed by the composition of two datum.

So spin off this table. Additionally, you spin off a similar table with item-id and skill-id and whatever skill is required. here item-id and skill-id form a composite key. The previous table of skill, item and material is now decomposed into this table.

So if you need to know what material an item takes to build, you simple do a search for the relevant item-id in the item/material table. If you want to know the skill well then skill/item.

The composite key thing isn''t a big deal here, you''ll end up doing item-id (item key) based searches anyways. *shrug*

That resolve all issues?

BTW, I often switch between *ids and keys. Keys are data which uniquely identifies a tuple (row in the table). In the case of this problem, there are many times where the *-ids are keys -- this is not always the place.

I''ve noticed a lot of "tell me how to design my ***" threads recently.

Here''s what you need to do:

Go learn how to program databases.

It''s that simple.

Database design and programming isn''t some simple "*poof* here''s how you do it" thing, it''s rather complex and if you come in here trying to glean it from us, you''re gonna make a REAL crappy database and give 2-3 database engineers nightmares as they try going back over what you''ve done and try to fix it.

Go buy the books, spend a crapload of time building preliminary databases, look them over, have someone who knows what they''re doing look over it and after you think you''ve got it and the guy you''re having look over your stuff thinks you''ve got it, THEN build your database. You''ll know a lot more and make a lot fewer mistakes than I''m thinking you''re going to make on your current path.