{{
`${userDetail.user.displayName}${userDetail.user.cachedBungieGlobalDisplayNameCode ? `#${standardizeBungieGlobalCode(userDetail.user.cachedBungieGlobalDisplayNameCode)}` : ""}`}}
{{getUserClans()}}
originally posted in:BungieNetPlatform
View Entire Topic
11/1/2015 6:23:08 AM
1
What kind of database to use for storing PostGameCarnageReport data for use in analysis?
Hi, I am working on some code that will retrieve the carnage reports for my matches that I will then analyze. Some examples of stats I want to compute are: ratio of primary weapon kills over non-primary over some period, most used weapon in a specific game mode, graph of combat rating/kdr/ or whatever over some period, etc. I'll also try to see if I can find out how combat rating is computed and what kind of affect it has on how teams are formed. Basically I'm just playing around with the data to find any interesting info/trends.
My question is what kind of database would be best to store the data so I don't have to retrieve it from bungie all the time? I was thinking something nosql like mongodb. Would a relational database be better? I was thinking about the schema and it seems like a pain as I'm not experienced with database design. If relational db is the way to go then what would a good schema look like for the given data?
Does anyone know how bungie stores and computes game stats?
Thanks in advance.
-
Hi, I'll start by saying that this is more a "HOW TO CODE" question than an "API QUESTION", so i would tell you that a better place for this is stackoverflow, or any other code forum. But, i can also tell you that depends on what information you need or what you want to do with your data what DB to use. I personally i'm using SQLite cause that's what's built into mobile devices and web browsers. And the manifest that we can download from bungie is using Json like data, kind of CouchDB. My recommendation would be, take a piece of paper, write down everything you need, find the relationship between that data, and then mock it up, and do some paper testing and see if it would work like that, and if not, rinse and repeat, once you have a "working" prototype, then go ahead and code that :)
