Timeline for Alternatives to storing all my entities in an SQL database
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 1, 2014 at 7:20 | answer | added | Naros | timeline score: 1 | |
| Dec 12, 2013 at 19:31 | comment | added | nialna2 | Oh. I failed my markdown, didn't notice the link wasn't there. It is now. | |
| Dec 12, 2013 at 19:31 | history | edited | nialna2 | CC BY-SA 3.0 |
added 7 characters in body
|
| Dec 12, 2013 at 18:04 | comment | added | user1430 | (Also, your question refers to "this post series" but doesn't have a link -- could you add that? I'd be interested in reading it.) | |
| Dec 12, 2013 at 18:03 | comment | added | user1430 | Yes but this approach is not how modern MMOs make use of SQL. It's an academically interesting idea but in practice, not an ideal choice. There have been other discussions of this topic here before, if you are interested. See: gamedev.stackexchange.com/questions/40212/… and gamedev.stackexchange.com/questions/16122/… and gamedev.stackexchange.com/questions/40215/… for example. | |
| Dec 12, 2013 at 14:01 | comment | added | nialna2 | Yes, but I didn't know that SQL was waiting for the hard drive to run queries, so I thought maybe I could get fast answers. That's why now I need an alternative to SQL | |
| Dec 12, 2013 at 12:19 | history | edited | Anko | CC BY-SA 3.0 |
Lots of general clarity. Grammar and spelling.
|
| Dec 12, 2013 at 9:04 | answer | added | Philipp | timeline score: 6 | |
| Dec 12, 2013 at 6:55 | history | tweeted | twitter.com/#!/StackGameDev/status/411026589057835008 | ||
| Dec 12, 2013 at 5:49 | comment | added | Pieter Geerkens | Let's assume our disk drive platters spins at 6000RPM, which is to say 100 times per second, or once every 10 ms. Does that explain yet why your queries seem to average about 10ms to run? | |
| Dec 12, 2013 at 3:34 | comment | added | nialna2 | From a practical view it is. sql has many advantages for storing entities and components. Without the speed issue it would be great | |
| Dec 12, 2013 at 3:11 | comment | added | user1430 | Just because something is possible (and this is) doesn't mean it's a good idea though. | |
| Dec 12, 2013 at 2:21 | comment | added | nialna2 | That's linked to the idea of storing everything in db. It allows for consistent SQL data access, easy client/server communication, and constant persistance of data. The problem being it is just unrealistic because too slow. But the post I initially read suggested it was possible so I tried it. | |
| Dec 12, 2013 at 2:19 | comment | added | Seth Battin | Queries should be able to run faster than that. Off the top of my head, lack of indexes, running remotely, poor aggregation, and inner sub-queries could all be culprits. But really, is there really a need to query every frame? That in itself suggests you're doing something wrong. After you query once, why does the data go straight to the garbage collector? There's no point putting the whole db into ram when you could just park the data in game's memory. | |
| Dec 12, 2013 at 2:15 | history | edited | nialna2 | CC BY-SA 3.0 |
added 184 characters in body
|
| Dec 12, 2013 at 2:14 | comment | added | nialna2 | Yes. The idea of this entity system is that everything is stored in SQL. That means that running physics on objects implies getting physics components in SQL and then updating them to the DB. I thought storing the DB in memory could be powerful enough, but it seems not. | |
| Dec 12, 2013 at 2:12 | comment | added | RoughPlace | maybe worth explaining your infrastructure a little more, are you trying to write to a db on each tick of your game? | |
| Dec 12, 2013 at 2:06 | history | asked | nialna2 | CC BY-SA 3.0 |