tradeskillrecipe table

[Muuss]

Great news

Waiting for Krich and Lurker_005's post then )

[krich]

Well, you successfully identified where my SQL knowledge is lacking. You lost me on the first query. It all sounds good to me though! :P
(You can count that I'll be studying your response to try to understand it though)

Of course, its more time consuming than the queries on the previous table, but tradeskill combines arent that frequent...

Actually, the current tradeskill queries are god awful ugly (but there is no other way) and I think they don't quite work perfectly.

Regards,

krich

[Muuss]

You can count that I'll be studying your response to try to understand it though

Well, i m sure you will !
btw, if i wrote something idiotic or just wrong, don't hesitate to insult me

[Muuss]

I was thinking to the tables.... if that format is maintained, it could be a good idea to add a key on reciped_id/item_id on the second table, to limit the possibilities to have 2 times the same item listed in the recipe. It would facilitates the table exploitation if there's no need to check that an item could be use 2 times in the same recipe

[Lurker_005]

My gut tells me there ought to be a better way to make this so that the lookup is easier... but since I can't think of it what you propose looks pretty good, and it adds some needed functionality to tradeskills.

If this turns out to be slow or problematic, then we can always fall back to the flat DB table with added fields.

[Muuss]

Yeah, the lookup might be a problem.
A solution to accelerate it would be to add a numeric field to the main table containing the number of components needed for the recipe. This would seriously reduce the amount of recipes that could match a combine. In counterpart, the field has to be filled by the world builder, or automatically by the tool that edits the recipes.

[Muuss]

About the 'flat' table, what causes me a trouble is that there's no limit to the amount of items returned by a recipe, successfull or not,

So basically, we have 10 fields only for the components, with a flag saying if the item is returned on failure/success (typically, for the tools). (say 10 more fields, or even 20) : 20 or 30 fields for the components.

then we have the products, lets start with a maximum of 5 returned products, a field for the item_id : 5, a field saying how many items are returned on success, another field for the failures : 5+5 fields, for a total of 15.

Added : other skills, trivial,skill,id,neededskill.... again a few fields : ~10

we're yet at around 45/55 fields, and are limited to 5 returned items.

To this, we still have to implement the race/class/god/town limits, as we won't have any lookup troubles with this, the table i suggested still works in the case of a flat table.

All this is why i didnt suggested a flat table. My opinion is that we should avoid to implement stuff if yet when we do it, we see where the limits could be. This will prolly allow to create all the live recipes but limit custom ones.

[Muuss]

Trumpcard, would you post or PM the definitive mysql structure of the table(s) when possible plz, so i can start to work on an editor and eventually to a convertor, thankees)