Alright I have a question.
I was looking at the appearances table today since I have a CSV of all the appearances and was thinking of updating my appearances table. I noticed that there are actually 3 fields in the appearances table though: id, appearance_id, and name.
My question is this- Isn't that rather redundant? appearance_ids are unique, so why do we need the id field? Do we really need two ways to reference these appearances? In my experience this table as a whole is rather useless since I can call ids that aren't in the table with the /race command anyways, but if we insist on keeping the table as reference, then I think we should at least remove the id field and just let the appearance_id serve as the key field for the table.
It only makes sense...

PK's (most of the times named `id`) are usually for indexing and reference. It's standard practice to build a table with at least one PK/Index column, then add your particular usage columns after.
Sure, appearance_id may be unique throughout the entire data table - but should there ever be a reason why one needs to be duplicated for _any_ inconceivable, unforseeable reason, you would then be forced to insert an autoincrementing ID field anyway - so why not just do it at design time?
Are you thinking this takes up unneeded data space? Because believe me, there are places where "unneeded data" dominates our tables - and maybe someday down the road, we can address this and the 100 other issues we have relating to database design.
(btw, I didn't build the initial structures ~giggle~)

ZexisStryfe wrote:In my experience this table as a whole is rather useless since I can call ids that aren't in the table with the /race command anyways, but if we insist on keeping the table as reference, then I think we should at least remove the id field and just let the appearance_id serve as the key field for the table.
It only makes sense...

Sure you can get rid of it. That is unless of course you want the emu to correctly create your character. The emu uses the table extensively during character creation to convert the text the client uses to the IDs. Getting rid of it would result in your character having values of 0 in the following fields: soga_wing_type, soga_chest_type, soga_legs_type, soga_hair_type, soga_race_type, legs_type, chest_type, wing_type, hair_type, and race_type.

Ah, gotcha LE. I knew there had to be some purpose for it.
Then my next question is, If this table helps convert the SOGA hair type, etc, etc, what is actually preventing that information from being saved? When you create a SOGA character, you loose all of your hair choices along with facial customization.

The information is probably being saved, the structs are most likely off and need fixing.

Aye, I remember talking abotu SOGA a while back, and getting that sorted out just wasn't a priority until (possibly) after the beta phase - when the incidentals are perfected.
So aside from my "best practices" excuse for having a seemingly redundant indexing, there is something far greater; LE said so.