Making usages dynamic?

[cmd]

I've been contemplating this for awhile now therefore I've turned to you guys for some suggestion's I was just wondering whether making usages (energy, will, brave, money, crystals) dynamic would be a good idea?

The reason why I'm thinking it is because I want to make it easier for myself to control energy from the staff panel? for example, perhaps I want to change the name of energy to something else quickly?

I dont know, I just want some of your opinions guys.

If making the usages dynamic is a good idea could you please give a brief explanation of how to do such DB designs?

Thanks :)

[IllegalPigeon]

Personally, I don't think changing the name of commonly used stats is a good idea. You create a game where people can use "energy" but then you change it half way through? Sounds like a good way to confuse people!

However, there is equally nothing wrong with storing these settings in the database if you did want to change them later. You could even store them in a configuration file, if you really wanted. Just define the names of said items, If you want to use a database, I'd do something like this;

CREATE TABLE `settings` (
 `key_name` varchar(50) DEFAULT NULL,
 `key_value` mediumtext,
 UNIQUE KEY `key_name` (`key_name`)
) ENGINE=InnoDB

This method will be a lot easier than storing in files, especially if you want to add more configurable settings later.

[Coly010]

Personally, I don't think changing the name of commonly used stats is a good idea. You create a game where people can use "energy" but then you change it half way through? Sounds like a good way to confuse people!

However, there is equally nothing wrong with storing these settings in the database if you did want to change them later. You could even store them in a configuration file, if you really wanted. Just define the names of said items, If you want to use a database, I'd do something like this;

 

CREATE TABLE `settings` (
 `key_name` varchar(50) DEFAULT NULL,
 `key_value` mediumtext,
 UNIQUE KEY `key_name` (`key_name`)
) ENGINE=InnoDB

 

This method will be a lot easier than storing in files, especially if you want to add more configurable settings later.

Yep :)

[MENTION=71474]cmd[/MENTION] , if you are using mccodes i believe there is already a settings table, with conf_name and conf_value, rather than key_name and key_value, so the table is already set up.

Just add the records to this table :)

[cmd]

Yep :)

[MENTION=71474]cmd[/MENTION] , if you are using mccodes i believe there is already a settings table, with conf_name and conf_value, rather than key_name and key_value, so the table is already set up.

Just add the records to this table :)

You see i'm making my own script, so just struggling with ideas.. so you think I should just store the key_name (energy) and key_value(100) ? What if I wanted to store the maximum value it can be for a user? some users may have 150 energy, 100 energy and so on, what approach does McCodes take for this?

[IllegalPigeon]

You see i'm making my own script, so just struggling with ideas.. so you think I should just store the key_name (energy) and key_value(100) ? What if I wanted to store the maximum value it can be for a user? some users may have 150 energy, 100 energy and so on, what approach does McCodes take for this?

I thought the idea of this was to have the ability to change the name of "energy"?

E.g you have

key_name | key_value

stat1 | energy

I'd store the users "energy" and "max_energy" in a user stats table, that is related to a user table.

For example;

Table users:

id | username | password

Table user_stats

user_id (foreign key references users) | stat1| max_stat1| money

Then, if you created a model implementation to fetch the data from the related tables, you could have something like:

echo 'You have ' . $user->stat1. ' out of ' . $user->max_stat1. ' ' . config('stat1'); 

Which would translate roughly to: "You have 50 out of 150 energy".

See what I mean?

Obviously, my above code is assuming you have some sort of model to fetch related data and, a function named "config" that would fetch config variables. You can do it however you want, though!

[cmd]

I thought the idea of this was to have the ability to change the name of "energy"?

E.g you have

key_name | key_value

stat1 | energy

I'd store the users "energy" and "max_energy" in a user stats table, that is related to a user table.

For example;

Table users:

id | username | password

Table user_stats

user_id (foreign key references users) | stat1| max_stat1| money

Then, if you created a model implementation to fetch the data from the related tables, you could have something like:

 

echo 'You have ' . $user->stat1. ' out of ' . $user->max_stat1. ' ' . config('stat1'); 

 

Which would translate roughly to: "You have 50 out of 150 energy".

See what I mean?

Obviously, my above code is assuming you have some sort of model to fetch related data and, a function named "config" that would fetch config variables. You can do it however you want, though!

I understand, but I kind of want to make the website full dynamic.. that way I can have a table for all main usages, energy, will and brave and in that table I can have a column with the userID and obviously the current and max energy, will and brave.. then have another table lets for example call it spend, within that table just have userID and money, crystals etc..

I just want to know the benefits of having these usages dynamic?

[Coly010]

I understand, but I kind of want to make the website full dynamic.. that way I can have a table for all main usages, energy, will and brave and in that table I can have a column with the userID and obviously the current and max energy, will and brave.. then have another table lets for example call it spend, within that table just have userID and money, crystals etc..

I just want to know the benefits of having these usages dynamic?

Well if you split them up like that, then one benefit I can see (@IllegalPigeon correct me if I'm wrong) as there are less columns in the tables, if you only need to access the money, then querying a table that has 4 columns rather than 24 will be faster?

[KyleMassacre]

[MENTION=65371]sniko[/MENTION] does something similar for his panther engine as seen here:

https://github.com/harrydenley/PantherSkeleton/blob/master/Skeleton%200.6/mods/userclass.php

so feel free to look at this and get some ideas. Basically it's the same thing you are thinking about doing

[IllegalPigeon]

Well if you split them up like that, then one benefit I can see (@IllegalPigeon correct me if I'm wrong) as there are less columns in the tables, if you only need to access the money, then querying a table that has 4 columns rather than 24 will be faster?

The process behind splitting up tables is called normalization. It's not necessarily faster OR slower, it is extremely unlikely you'll ever be handling enough data to ever see a JOIN become a hindrance. Plus, with correct indexing and query performance, you won't run in to the issues either. Normalising also reduces data redundancy.

But, by far the BIGGEST and best thing about normalization is the maintenance. It's so much cleaner and easy to maintain.

Also, no one is going to look at your normalised tables and say "that's inefficient and going to slow your site down" (unless you've split one table into something ridiculous like 15, of course). Relational Models are standard and encouraged. You don't need to split every table, but, things like separating user account info from user stats and user items is a good call!

Edited August 25, 2015 by IllegalPigeon