23.04.2012, 17:21
This is just plain horrible. Your mistake should be easy to fix as you have an unnecessary '%s' before the '%d/%d/%d' field in the INSERT query.
But we should also probably go over optimizing your MySQL table and by that, decreasing the size and execution speed of queries.
I will go over your field syntax one by one:
password VARCHAR(400) - Whirlpool (AFAIK) gives a 128-character hash. So decrease this size to 129 (leaving room for the null character)
killss INT(20) - Why is this field named KILLSS, when the proper version would be KILLS, anyways? A INT field allows you to store values from -2147483647 to 2147483647. And GOD will I kill myself if a player once reaches 2147483647 kills or has a negative kills value! Change this to unsigned smallint (or mediumint in case a player has chances of getting more than 65535 kills).
The same goes for the deaths field.
I don't know the highest score value possible in SA-MP, but I still suppose a MEDIUMINT would be more appropriate.
adminlevel INT(5) is just horrible again. I very much doubt that you have an admin level with the value of 2147483647. And actually, I am pretty sure that your admin levels do not go past 127 (signed TINYINT) or 255 (unsigned TINYINT). Now if you change it to TINYINT, it will take 3 bytes less space to store this information. In a database with tons of entries, this will actually make quite a difference.
hoursplayed INT(20) is an interesting sight! I doubt we'll see a player who is online for 245000 years, so feel free to decrease this value to something smaller. Also, this raises a question for me: what would be the best method to increment this value? What if a player joins, is online for 10 minutes and then leaves, comes back and repeats the situation at least 6 times? No chance that the online time will increase.
ratio VARCHAR(5)... Why do you have this as a string? Use a FLOAT instead.
And another 2 suggestions:
1. Create DEFALUT values for the fields, so you don't have to specify the values in the INSERT query itself.
2. Add INDEX(es) to the table.
I hope you find this piece of writing at least a bit useful and can, in the future, design your fields with a better touch!
But we should also probably go over optimizing your MySQL table and by that, decreasing the size and execution speed of queries.
I will go over your field syntax one by one:
password VARCHAR(400) - Whirlpool (AFAIK) gives a 128-character hash. So decrease this size to 129 (leaving room for the null character)
killss INT(20) - Why is this field named KILLSS, when the proper version would be KILLS, anyways? A INT field allows you to store values from -2147483647 to 2147483647. And GOD will I kill myself if a player once reaches 2147483647 kills or has a negative kills value! Change this to unsigned smallint (or mediumint in case a player has chances of getting more than 65535 kills).
The same goes for the deaths field.
I don't know the highest score value possible in SA-MP, but I still suppose a MEDIUMINT would be more appropriate.
adminlevel INT(5) is just horrible again. I very much doubt that you have an admin level with the value of 2147483647. And actually, I am pretty sure that your admin levels do not go past 127 (signed TINYINT) or 255 (unsigned TINYINT). Now if you change it to TINYINT, it will take 3 bytes less space to store this information. In a database with tons of entries, this will actually make quite a difference.
hoursplayed INT(20) is an interesting sight! I doubt we'll see a player who is online for 245000 years, so feel free to decrease this value to something smaller. Also, this raises a question for me: what would be the best method to increment this value? What if a player joins, is online for 10 minutes and then leaves, comes back and repeats the situation at least 6 times? No chance that the online time will increase.
ratio VARCHAR(5)... Why do you have this as a string? Use a FLOAT instead.
And another 2 suggestions:
1. Create DEFALUT values for the fields, so you don't have to specify the values in the INSERT query itself.
2. Add INDEX(es) to the table.
I hope you find this piece of writing at least a bit useful and can, in the future, design your fields with a better touch!