Jump to content

[Best Practices] XML or MYSQL, and for what job?


Recommended Posts

First of all, hi everyone! :)

So today i come up with a new question : When should i pick mysql or xml, and for what type of job?

I have in mind, speed of execution, but also i'm trying not to use a cannon to catch a fly.

For now, I try not to use mysql for "lesser" jobs like storing static coordinates values i need to create markers.

Then i use setElementData for storing what i load from MYSQL directly "in" the object.

Of course i could be totally wrong in this method, as i might not be aware of performance issues caused by any of mysql/xml/setElementData methods.

Could someone post how they're managing their data persistance?

PS: This is, of course, not a thread about "omg mysql is better than xml", no. I'm just asking what method fits certain jobs the best.

Thanks a bunch :)

Oscuro

Link to comment

Element data should be used for simple things like if you're using your own account system, you can use element data on player pointer and use like: element data - "alreadyLogged" Value - true/false.

MySQL is for big things like saving player informations, resources infos...

Do you understand?

I don't know if this is what do you wanna know, so, if it's not, sorry :/

Link to comment

Yep, that's the idea. Tho I recently found out that if i want to use ID's when using xml files, i have to do a lot of manipulations on the file.

For example, I store a lot of statically set coordinates in an XML file. Removing an entry in the middle of the file would create a hole in it, and, if un-managed, might also come to having duplicate ID's in the xml table.

But at the same time, and as you said, MYSQL would be a bit big to just store static coordinates, but it has ID management. (kind of :P)

It also concerns me to use mysql too often, because in my mind it's a lot of extra overhead for the server.

What you made me understand though is to limit the use of setElementData to only basic stuff, and not to store what's loaded from mysql, in a setElementData field.

Oh and to make it clear, the initial question is basically "when to use, mysql, xml and setElementData". We answered two items there already. What about XML? When to use it?

Link to comment

You shouldn't use XML at all, it's memory consuming, and it's not practical. You should only use it for configurations, like making an XML file with upgrades Id and name. Something static that won't be changed during the run of the resource, will only be loaded and obtained data from it.

I recommend SQLite, it's not as fast as MySQL, but you won't have to setup a database or anything.

MTA has new db* functions that works with SQLite, and MySQL.

dbConnect 
dbQuery 
dbExec 
dbPoll 
dbFree 

Link to comment
You shouldn't use XML at all, it's memory consuming, and it's not practical. You should only use it for configurations, like making an XML file with upgrades Id and name. Something static that won't be changed during the run of the resource, will only be loaded and obtained data from it.

I recommend SQLite, it's not as fast as MySQL, but you won't have to setup a database or anything.

MTA has new db* functions that works with SQLite, and MySQL.

dbConnect 
dbQuery 
dbExec 
dbPoll 
dbFree 

Correct. I am using XML in my gamemode because people will have to suffer from not being able to learn scripting. I have a second version of my gamemode which is only MySQL so... they will have to edit it themselves if they want to have a smoother gamemode :)

Link to comment

Thanks to both of you who just pointed something important I was missing.

Indeed, I personally thought that Mysql was actually more memory consuming than XML.

But I see your point, especially when i see the function "xmlUnloadFile" (something like that), which means everything I do in XML is temporarily written in RAM memory... I should have noticed that earlier hehe..

So I guess i'm gonna go for mysql, as setting up a mysql database is easy as eating as sandwich.

Thanks for the precisions! :)

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...