Re: advance dynamic inventory database set up
Posted: Wed Aug 15, 2012 7:39 pm
If you are wanting to make dynamic database that could have many, many different column names, there are a couple of options. The most simple database setup would have your columns looking like this:
ID | A | ValForA | B | ValForB | ......
Where you would store whatever you wanted in A, such as "inc_mp", "fireDmg", or whatever, and then add the numerical value in the "ValFor%" field. Then probably the best thing to do would be to make another table that is filled with the strings you are going to store in A, B, C, and so on so that you can simply put a numerical ID in them instead of putting actual strings of text (since doing that is very error-prone and would require a lot of outside note-keeping and checking to ensure you don't slowly change things as you go).
Another major downside to this is that you have lost named columns. So if you want to find out if the player has a "plus_intel" effect, you have to iterate through everything with a FOR loop to try to find it, and then read the corresponding Val field with its value. This is going to be a major pain.
A more difficult setup with a steep learning curve first, and then easier usage later would be the Entity-Attribute-Value model. With some extra setup, it can handle dynamic tables pretty well.
But then for a game, probably the best thing to do is make a hard-coded, long list of all possible values, and simply make them all column names. Since most of it will involve stats, there really isn't an infinite number of things it could be. Even if you end up with 60 or 70 columns, you can just group them and split them among a couple of different tables. Truly dynamic tables in SQL involve a lot of work!
ID | A | ValForA | B | ValForB | ......
Where you would store whatever you wanted in A, such as "inc_mp", "fireDmg", or whatever, and then add the numerical value in the "ValFor%" field. Then probably the best thing to do would be to make another table that is filled with the strings you are going to store in A, B, C, and so on so that you can simply put a numerical ID in them instead of putting actual strings of text (since doing that is very error-prone and would require a lot of outside note-keeping and checking to ensure you don't slowly change things as you go).
Another major downside to this is that you have lost named columns. So if you want to find out if the player has a "plus_intel" effect, you have to iterate through everything with a FOR loop to try to find it, and then read the corresponding Val field with its value. This is going to be a major pain.
A more difficult setup with a steep learning curve first, and then easier usage later would be the Entity-Attribute-Value model. With some extra setup, it can handle dynamic tables pretty well.
But then for a game, probably the best thing to do is make a hard-coded, long list of all possible values, and simply make them all column names. Since most of it will involve stats, there really isn't an infinite number of things it could be. Even if you end up with 60 or 70 columns, you can just group them and split them among a couple of different tables. Truly dynamic tables in SQL involve a lot of work!