aa_character:
the two min_* fields should not be there, as they are not character specific.
Further, they are already be specified in altadv_vars.
Understood. The idea of this diagram was to replace whats currently in altadv_vars, aa_levels and aa_action to make it more customizable. Setting the min fields in the root of the db tree structure was to give the option to customize. Im getting the feeling that that isnt going to fly tho. Im assuming there is somthing im not understanding from a development standpoint on changing the current structure?
The remaining fields from aa_character would belong in the character table,
but there are more fields from the player profile which would be needed to make
their removal from the blob complete... and it should really be an all or nothing thing.
Ok, gotcha. Is there somwhere where what information is contained within the player profile? I would take a stab at trying to give you the fields you want if i had an idea of what was hidden inside there =). Just need to get a dummy profile if possiable.
aa_info:
table should be normalized:
(character_id, aa_skill_id)
and thats it.
OK. The idea behind the info table was to allow for custom ranks. I didnt wanna use the current structure cos i was concerned i that we would get stuck using preset ranks. But again, im getting the feeling that this is too much change and not what you really need. You need somthing that will enhance the current structure, not change it.
aa_data:
this table is a mess, it contains components from several different concepts:
Its only purpose should be to tell eqemu what to do with this AA.
this is what aa_actions is for, so what your really proposing is a mod to aa_actions.
No, i was proposing to replace it. Again, prolly a bad idea. Like you said, its purpose is to tell the code what to do with this AA. So if an AA ability did anything, it would be available in this table. This was to insure that a custom rank could have custom abilities.
the key should be aa_skill_id (aa_actions was aaid,rank but needs changing too since soe changed it)
aa_name, aa_class,aa_cost,aa_type,level, restriction... are already in altadv_vars
im not sure I see the usefuless of the other fields which are not in aa_actions either.
Ok, here is somthing I didnt understand. we are following a table naming set based on the code that we get from SOE? Now that i think about that it makes sense. My changes are prolly pretty far out then. I was under the impression that you were looking for somthing to replace the current aa db structure. But i think Im way way off from what your looking for.
Ill make the suggested changes and see what we end up with hehe.
|