Item System Storage
 

My task is to create an item system. I was just wondering what everybody's opinions are on the storage of data. I'm not too worried about your caching opinions but if you want to make them known, I'm more than happy to take advise.

For me, both files and SQL works since I load them into a DBNPC. Both ways work since it's a one off read. SQL seemed pretty slow when dealing with alot of requests for me (which was really weird) so I wouldn't recommend storing and reading items out of it constantly.... works really well for logs though =D

For ease of use (and the fact I don't use the files live) I recommend file based

I guess that could work pretty well :)

Truth be told, could just skip the loading part and code it straight into the dbnpc >_<

That's what I used to do when I only needed to create and manipulate items. I'm thinking loading from text-files into a DBNPC cache would make things easier when people want to manipulate items in the event I'm not around.

Though, it'd still be nice to hear what other people have to say on the matter.

I have to say files. Easier to manage and work with if you are offline (You can write up items and all that stuff when you're missing an internet connection. Just upload them when you get internet back.)
I usually just store all the information in files, and then cache them for faster access.

It's just so much easier doing object.loadvars(filepath), instead of having to hazzle with requests and such with SQL..

It's personal preference to a certain degree though.

Thanks for your input :)

Files + DB Cache for Base Arc Data, and SQLite for storing player's item info (quantity, custom modifiers, etc.).

It's so much easier to do trades with SQLite, since you can just make the updates in one transaction, then have them both reload their items. Plus it makes the backing up of player data a simple one file backup.

SQLite is by far the easiest and most powerful way of doing it.

Could you elaborate on that?

Not too much to elaborate on. SQLite database is a huge total filesize decrease comparing to plain files, it's faster loading/altering of data, it's *A LOT* easier to find specific data across the entire table then searching through all files. And the biggest pro of them all: save one, that's right - ONE, file on your computer and your entire servers database is backed up.

I could most probably list a lot more reasons why SQLite is superior, but the above ones are the ones that convinced me.

So you would store all information that is important or used by all of your systems in one SQL database?

Do you only use SQL or some combo as Jerret described in his post?

Edit; What if you have a player that had it's player data glitched, and you need to restore their old values from the old SQL backup, what would you do then? Install a third party software to view the table wanted and then manually query a change in the current SQL DB with the old backup data? (Seeing as requestsql2() isn't working as far as I've seen)

For some reason, SQLite seems to have a high cpu usage on a few queries with graal though :/

I so far store items, items owned by players, skills, quests, spells and recipes in my SQLite database. So yes, I guess you could say I store all important information in it.

Care to show examples? Only time I've experienced that is when I used SQLite queries in a very bad way (I've learned how to properly work with it since) or excessive use of VACUUM (which obviously gives high CPU usage).

It would be really handy if you could provide tips and examples on how to properly work with it, since all I know is the basic syntax.

Just simple queries, inserting, selecting etc.. - and I know how to use proper queries such as JOIN etc although i'm unsure if sqlite supports all of that like mysql does.

I'm not convinced that the CPU usage for SQL queries is entirely accurate.

I find files to be much easier than SQL, especially ini files.

From experiencing both, I think I'd have to go with Jerrets suggestion though, I'd use ini files for item data, and SQL for individual player data.

I personally think SQL is being way over estimated by everyone lately. It surely is very useful, especially with nice tools like Chris Vimes SQL Explorer, but it's not the perfect, beat all solution.

I'd actually say it is.

On Era Dev we're using files for storing item data (items/weapons/guns/ak47.txt, for example), and then using SQL to store individual player data, e.g. the items the player has and the quantity of the item they have. If you index it properly, it's pretty fast.

It seems to be working quite well, though we hope to find out just how well with the iPhone server.

EDIT: I should mention that we're caching the items into a DB NPC to prevent tons of file I/O and slowdowns.

And why are you sending this to me..?

Hmm...

I'm thinking the same thing. I did say I knew the syntax but what I was asking for was tips on optimization from scripters who know how to use it properly. :whatever:

Well I see why he was sending me it, so I retract my statement :p.

I get the feeling he was trying to be a smart arse.

Possibly.

No, he would have been if he send you this:
http://lmgtfy.com/?q=sqlite

Aha, that's awesome.

I've been looking for that link for a while :)
thanks.

rep+