cs-demo-manager
cs-demo-manager copied to clipboard
[Suggestion] Use a proper database for storing the stats
Hi,
I don't know exactly how you store the stats currently, but I think using a proper database (like MySQL/MariaDB, PostgrSQL, ...) would be very beneficial for the performance of the application.
I'm storing my demos on a network share on a NAS and displaying anything really takes it's time. If there was a database behind, that stores all the stats and details about the demos it would be a lot faster, I think. Sure, for some things we'll still need the file, but the path where it is being stored could be saved in an additional column in the DB and retrieved when needed.
Just an idea, because I have a few DBs running at home and it's a shame that I cannot mine the CSGO data with one of them.
Chris
Export to Excel and then moving that data to Access is my current solution for this.
Export to Excel isn't possible anymore. After about 400-450 demos the Excel export only yields an error. Probably the old 65535 rows limit reached. I know the new format supports about a million rows, but when using the Excel COM object, you'll encounter the old limit quite frequently.
Whatever limit is reached, it doesn't matter. If you have too many demos the export will stop working.
I have Excel exports that are over 80k rows, that's not it. See #199 for details about the crash.
I also commented on the referenced issue; I'm aware of it. ;-)
Since lugging around a database (ie. MySQL/MariaDB/Postgres) is hard to maintain, rather just provide the option to export to one that the user points to.
Alternatively use CSV exports so we have a simple format that is ingestible into a database later on.
Personally if it was really topic of running data science on the Demo Data you could just as well provide CSVs and provide some Jupyter notebooks. (This is something I want to explore myself too)
Otherwise, .NET should have SQLite bindings right? Accessing that should work just as well.
The bigger problem though is the fact that having a real relational database means having to take care of a database schema and having it migrated on a release to release bases if something actually changes.
A new major version has been released, closing the issue 🧹