Page 1 of 1

A terrible idea that involves SQL.

Posted: 31 Dec 2017, 08:36
by NoQ
I looked at #4688 and had a terrible idea. The code could have been refactored with the help of sql.js: put all stats into an in-memory per-AI SQL database at the beginning of the game, update those when various research is done, query whenever you are trying to pick the best weapon or whatever. Well, just wanted to share the aforementioned idea. Never mind, really.

Re: A terrible idea that involves SQL.

Posted: 31 Dec 2017, 13:32
by Per
Why SQL? If you want raw access to stats, could just give direct access to the source JSONs.

Re: A terrible idea that involves SQL.

Posted: 31 Dec 2017, 14:13
by Darkling
It would be nice to be able to simply call up current stats for a weapon taking into account completed damage and rof research. It would give an easy way to rank weapons based on current damage output. Within a given weapon family later is usually better, but current expected damage would be a nice way to weight selections between weapon families.

Re: A terrible idea that involves SQL.

Posted: 31 Dec 2017, 18:30
by NoQ
Per wrote:Why SQL? If you want raw access to stats, could just give direct access to the source JSONs.
Because i'm executing a complicated query with an ugly system of spaghetti functions that loop through JSON stats. So i thougth that SQL makes more sense for that. I didn't *actually* try to write down the queries it boils down to, but it feels like that.

Re: A terrible idea that involves SQL.

Posted: 01 Jan 2018, 05:32
by Per
Ah. There are json-specific query languages that might be more appropriate in this case, which we could possibly support natively from the scripting API, like jq (through libjq) or jsoniq. Although I've never used any of them (except mongodb, which I would not recommend).

Re: A terrible idea that involves SQL.

Posted: 21 Mar 2018, 12:29
by samuraicrow
Per wrote:Ah. There are json-specific query languages that might be more appropriate in this case, which we could possibly support natively from the scripting API, like jq (through libjq) or jsoniq. Although I've never used any of them (except mongodb, which I would not recommend).
I agree. MongoDB is quite heavy for a single-user skirmish as is SQL.