The Nitty Gritty

Nitty Gritty

This page is to outline some underlying design decisions that you may be curious about.

Balance Transaction Removed

In the old TNE, anytime a player's balance was checked, it was recorded as a transaction. This is no longer the case because it overwhelmed the transaction records with useless transaction logs.

Datable Interface

In TNE, any object that is capable of being stored in the Storage Engine utilizes the Datable Interface. This was done in an effort to allow for the future module system to quickly and efficiently add new objects to the Storage Engine without having to reinvent the database system. This will allow module authors the ability to skip having to write storage handling classes and let TNE's internal system handle database connections.

Storing UUIDs as BINARY(16) in SQL

This decision was made to improve efficiency at the database level, not only for space purposes but also for index reliability issues.

For example, let's take the basics of storing a UUID as a VARCHAR(36). We would require, at minimum, before charset, etc., 37 bytes. This is because there is a byte reserved to outline the data's length and then the 36 bytes for our characters in the UUID. However, as binary, it's simply 16 bytes. TNE's data structure has 14 different UUID-based columns between every core table, which equates to 518 bytes of storage used for just one row in each table. Compare this to the 224 bytes utilized for the same number of rows using the BINARY type instead of VARCHAR.

Considering this in the longer term of operating a server economy with only 300 accounts, the UUID columns alone will account for 66.6 Kilobytes versus 28.8 Kilobytes using the BINARY type.