creature_addon and creature_template_addon

Is there any compelling reason for these two tables to exist? I write code to generate sql and these optional records that complement the creature and creature_template tables are a real pain because I have to know beforehand whether an existing *add_on record already exists (to do an INSERT or UPDATE).

I am planning on updating my repo to fold these tables back into their parent tables and would be willing to provide a patch to TC if it’s wanted for origin.

They will not be removed, they are used to store auras that creatures possess since their spawn.

Why can’t this be done on the creature table?

adding 4-5 columns to creature table is highly un-efective way.

Because it would mean duplicated data?

Maybe in 1998. The db is tiny and having to do joins or additional sql calls to save space seems crazy and unnecessarily complicates code.

How would there be duplicated data if you dropped the add_on tables?

probably because it uses references so creatures who have the same auras don’t need their own entry.

oh. So you are saying at a creature with guid X might use a creature_addon entry with guid Y?

No, there aren’t references AFAIK but why would we put data in the creature table, means duplicated data for X spawns of A whereas creature_template_addon is one data row for all the spawns.

I’m not suggesting that at all. The data in creature_template_addon should be moved to creature_template, where it belongs

Here’s what I think:

creature_template_addon can be merged with creature_template because all creature templates should have those addon stuff (especially bytes2)

creature_addon cannot be merged with creature because a lot of spawns need no special info from _addon

merging these two tables would denormalize a lot (if it can be calculated) and increase redundancy, but we never used foreign keys so it doesn’t really matter.

Not counting the guid key, creature has 19 fields and creature_addon has 6 fields. There is no redundancy in these tables. They have the same key, so merging the tables would normalize things, not denormalize them.

The risk you run is that you have a lot of fields in the creature table with default values whereas before they would have not existed. My thought is that the db is so tiny by today’s standards that this is not a concern.

But the gain is that you no longer have to join the creature & creature_addon tables and you don’t have to make additional calls or write code to decide to INSERT or UPDATE the creature_addon table. This cleans up the code.

I still don’t like that idea.

If you merge c_t_a into c_t and c_a into creature then that means that you have to have the addon data from creature be overwriting data from the template, which may not be what you want. Those may sound like extreme cases, also remember that most of time the core will assign default values to bytes and bytes2, meaning that having that column part of “creature(_template)” will be redundant for a lot of creatures.

I totally get that but that’s handled by having designated null values in the c_a fields to signify when you would want to override from c_t. That’s much less effort than the overhead of maintaining 4 tables instead of 2, and the special code to know when to insert rather than update. It also complicates sql updates for the same reason.

Anyway, it’s annoying the hell out of me having to work around this so I’ll fix it on my repo and see if I encounter any problems.

Thanks everyone for your input!

i’m with baric for this cause this will save of lot of time if we have to reguid all the database or when making a patch with autoincrement instead of using Specified GUID .

The creature table will be more longer to load but for the time we will save to make patch i think thats a good sacrifice.

And with that logic the next is merge SmartAI into creature table…

What? They’re not even the same key and it’s a 1->N relationship.

If you want to create some strawman argument to knock down, try to make one a little more believable.

I’d very surprised if the load time was significantly different. In fact, it might be a little faster since the creature_addon table would no longer be loaded.

I dont know why the dev core doesnt understand this but when we work always in sql we know what we’re talking about . Creature_addon is not similar to Smart_AI (7 rows compared to 27 rows) . Trying to ridiculous me is not an argument. The best thing to do is to try it and test and after this you make a good judgement .

I don’t actually understand how adding rows to creature_addon[_template] is “hard”, don’t want to check if the row already exists? TC’s standard is to DELETE and INSERT again regardless if the row already exists or not, to make a commit non-dependant on others.