If you're really a DBA, you'll know that making THAT work will be much MUCH harder to do than just use default unique keys. I really doubt that it was ever the case in EU databases.
We are getting a little bit off track here but one way do do it would be to be along the long the lines of
Avatar table unique key avatar_id (could be name).
attributes such as skills, body characteristics, ped card balance.
avatar_owned table, unique key key, avatarid + avatar_owned_id (you could choose to have a surrogate key if you are not a fan of segmented keys).
attributes such as
Item_name_id, quantity, tier rates, current tier level, current_TT, location (carried, equipped, storage, shop id. box id, AH, etc) plus no doubt others.
we can see if you check your items on the web page that each line has an id associated with it that is only unique to your avatar.
Item table containing details of each type of item in the game. eg cap20d, output amp component, etc
Unique key, Item_name_id
Attributes
item_name (also is unique)
relevant properties of the item, eg max tt, max dam, range, etc
An auction table that links to avatar_Owned key and has attributes governing the auction in progress.
and we also need to track stuff in the EU worlds. one way this could be done is by a table very similar to the avatar_owned, including an attribute for location.
Then all you need to do is have methods that modifies a row or removes a row from one table and adds an equivalent row to another table. All that provides for p2p trades, drop and pick up, putting stuff in auction, TTing gear.
We also know from the impact of server crashes, that some game situations are tracked in server state rather than in the database. For example a mob positions and state (alive/dead), gear in the repair console, uncommitted sales and TT ops.
Now I am not saying this is the best way but I am saying its not difficult. And there can be good (and bad) reasons for
- running with a db that is not fully normalised
- not setting up unique keys on some tables
- choosing to run instantiated objects that are not stored as entities but instead as attributes of another entity.
Performance is one such reason, coding effort is another, poor understanding of good coding practice is another.
And of course there good reasons to do things "properly". If we are to believe the duping stories, EU has already suffered from the impact of not following good practice.
I repeat, I don't know what MA did or didn't do. But it would work, it would conform with what we have seen and it wouldn't necessarily be any more effort than best practice. In fact one of the reasons best practice is not followed is because it is easier not to. No one has claimed that MA are programming gurus or strong on forethought and thinking things through.
Regards,
KikkiJIkki
