Consider changing storage of a user's rank

[Bryantdl7]

Currently, you have the addon set so that they store a user in the following manner:

function MSync.modules.MRSync.init( transaction )
    transaction:addQuery( MSync.DBServer:query([[
        CREATE TABLE IF NOT EXISTS `tbl_mrsync` (
            `p_id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
            `user_id` INT UNSIGNED NOT NULL,
            `rank` VARCHAR(15) NOT NULL,
            `server_group` INT UNSIGNED NOT NULL,
            FOREIGN KEY (server_group) REFERENCES tbl_server_grp(p_group_id),
            FOREIGN KEY (user_id) REFERENCES tbl_users(p_user_id),
            UNIQUE INDEX `user_UNIQUE` (`user_id`, `server_group`)
        );
    ]] ))

This is a great way to handle it from an initial standard of functionality, however, giving the user a unique number completely separate from STEAMID64 or the traditional STEAMID can cause for issues down the road.

I understand that you have the p_id as the common identifier to prevent user name changing from messing this up, but this is also an inefficient storage of the database, and the overall need for an extra table carrying redundant columns.

A more efficient approach, would be to combine tables tbl_users & tbl_mrsync, in a format like so:

Obviously disregard the commas in the steamid64 - my spreadsheet is helping a little too much today

This will allow for the following:

1. More efficient MySQL structure
2. Less database space overhead
3. Higher fault tolerance, should a single ID be modified

[ApertureDevelopment]

We are not doing that for a few reasons.

Reason number 1 is that the user table is supposed to be used by multible modules to offer a easy and effective way of loading and saving user data.

Reason number 2 is that the database would actually be more inefficent due to redundant data storage, meaning each module had to store the steamid, steamid64 and nickname. The approach we choose is the more efficent one.