[Discussion] What should a database contain?

Alright, so I've got a massive database of INI files.
These files contain TOO much information, and I could use some help, figuring out what should be in my database and what shouldn't.
First of all, I am using MsSQL (LINQ to SQL if anyone may wonder) and this is my first problem. Should all 'external' data I load be in this database? Or should I use some separate 'flat files' e.g. some INI files containing data.

An example would be the 'attribute points' for people from a certain class.
[Only registered and activated users can see links. Click Here To Register...]
It would cost me no effort to convert and save this in my 'MsSQL database' but should I? Or should I simply load this as an INI file everytime I put my server on?

My second problem is monsters. What data should I have in my database? And should I load this as INI files, or SQL files?
[Only registered and activated users can see links. Click Here To Register...]
What parameters should I load? And should I load this from my 'MsSQL database' or something different?

I could go on like this about a lot of tables, e.g. Portals, Npc Spawns, Monsters Info, Monster Spawns, Guilds, Item Info, Item Ownage (who owns what item etc), and even Lottery items, Item drops and so on!

Feel free to post what you think, oh and posting additional hints, info, statistics etc would be appreciated!

~Bas.

IMO, You should load everything from MsSQL since its (usually) much faster than INI files.

I would also load every value and really work with it. There is not one value at the mob table wich is not needed if you wanna make it as TQ like as possible.

But yeah, everyone should think about what HE needs for HIS use. I cant tell how you want your server to be.

I lack knowledge of how database management works, and how it should be used for the best performance.
So do you think adding a lot of values won't decrease performance? 'Cause I won't be using all of them at the beginning.

i cbf seeing what the ini file contains, but if its any sort of data you only need once upon the server to store it in memory then leave it in ini files. store player data in sql

Quote:

Originally Posted by ChingChong23 i cbf seeing what the ini file contains, but if its any sort of data you only need once upon the server to store it in memory then leave it in ini files. store player data in sql

I believe only the player data will be loaded more than once, so only that should be stored in SQL? Why do you think so? (Just asking)

If you want to use a flat-file database, it's better to store the data in memory.

If you want to use a MySQL database, it depends on the interval between the request. If each 15 sec you use the database, it may be better to store the data one time in memory.

For the database contains, just put the data that you use.
Ex. For the monster, maybe you use the drop value, maybe not.

Quote:

Originally Posted by Basser I lack knowledge of how database management works, and how it should be used for the best performance. So do you think adding a lot of values won't decrease performance? 'Cause I won't be using all of them at the beginning.

It will use slightly more RAM, nothing else should decrease the performance.

There are ways on MySQL to store the DB in Memory so its faster to access / read / write but unsafe eg. power loss would also mean a loss of the latest data.

Im not aware if MsSQL supports this type.

If I were you, which is what I take it your asking for (suggestions), I'd put everything you can in the database. Why you ask? Because then you can access it via the website, or change things via a web based admin panel, and if done right, you can modify things while the server is live and update it without taking it down way easier than if it was all INI. Just because it's a database doesn't mean you can't store it all in memory the way you would do with INI too :P Just run the query on startup or when you need the data refreshed on the server due to a change and store it after that.

I think I'll use MsSQL for everything apart from the dynamic maps.