C# Asp.net Should I use XML or SQL

[dragonboy144]

 

So I am currently writing an Asp.net website to track your inventory for an RPG, so I need to read the values for the items, now im wondering what would be the better format to store the items in. I have an class Item consistiong of multiple strings, ints and string[]s this file/table would not be written to by the user the program just needs to filter it to find the right item. 

[shadow_ray]

I would use an ORM. EF Core is pretty good.

[mariushm]

I'd use either a SQLite database or MS SQL database (if you have to)  or I'd use a JSON files. XML files are too complex, json files can be easily parsed by scripts to do search and replaces and whatever, from various languages, it's an easier format that xml.

There's also potential to re-use the json files with Javascript directly on the page, instead of doing everything server side with ASP.

 

SQLite is standalone, no need for complex MS SQL server, and runs well for  small databases and small users accessing the data.

[straight_stewie]

How large do you expect the site to get once you go live? 
Are you planning any advertising?
What is the popularity of the game?

 

[Eigenvektor]

That really depends on how much data you're planning on storing and how often you're going to query it. A database is much faster for large datasets than parsing an XML file. It can run on a separate server from your application so it can scale up in terms of performance once you start talking about hundreds of gigabytes of database size. On top of that you get tons of tools in terms of backup solutions, data consistency etc. etc. Depending on the size of the game, number of players etc. this is maybe not what you need. If you're talking something like WoW, with millions of players, you are definitely talking about a database, most likely running on a database cluster.

[Franck]

Problem with XML straight up will be concurrency. You would need another application that is the only one accessing this file and manipulate it. SQL is fine if you have it for sure. 

 

There is a third option...2nd gen database. Something like MongoDB it is meant for storing what's called document. It is extremely fast and can be set as a node in order to create a farm out of many server which can also work if you are self hosted. So far (as i use it myself) it hold better than SQL in stability when comparing throughput of data (only that aspec). SQL i start having issues with around 2.8 to 3 terabytes per day of changes while on Mongo i have so far reached a max of 17 tb of data changes in a single day and it didn't break a sweat. All my server are VM spec'd exactly the same. But don't get me wrong, Mongo is not a cure for all, SQL is still much more powerful and faster in every aspect but mongo is best at what it is specially built to do.

 

For text files vs database performance it depends. I used to admin a old Ragnarok Online server farm a long time ago (at least 15 years ago) and you could either run MySQL or Textfile database and textfile was much faster and could run more user per instance than the MySQL one. They did use a ton of folders / sub folder system but it worked very smoothly. Could be because MySQL was very clunky running on a RAID at the time vs simple textfile but technically there is not much difference. in SQL it will need to query to figure out the location of the data, then go there, retreive it, and send it back to you while a FileDatabase you skip all the finding of the data as the object has the path baked in and the data is not any bigger than what's in the database. Only drawback is the textfile system is a total mess to go through, update or even backup. Backuping over millions of files is not funny while doing a single database is done in a snap.