Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 106 Roadmap
- 358 Game & application design
- 315 Plugins
- 70 User experience
- 74 Marketplace
- 290 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 660 Bugs and issues
- 195 Introduce yourself
- 236 Announcements
- 105 Forum talk
- 403 Relax cafe
In this Discussion
SQLite Lua interface
totebo
Member
Hi,
I've tried the SQLite implementation and it works great. Being a little rusty on the SQL syntax, and general DB thinking, has anyone created a more abstracted way of using a SQLite, to avoid hacking SQL commands? Of course this may be tricky because of varying database structures, but I'm looking to use it instead of a JSON textfile, which means the most basic implementation would be enough.
If not, I am going to attempt this myself, so may be back with more SQL related questions!
Cheers,
Niclas
I've tried the SQLite implementation and it works great. Being a little rusty on the SQL syntax, and general DB thinking, has anyone created a more abstracted way of using a SQLite, to avoid hacking SQL commands? Of course this may be tricky because of varying database structures, but I'm looking to use it instead of a JSON textfile, which means the most basic implementation would be enough.
If not, I am going to attempt this myself, so may be back with more SQL related questions!
Cheers,
Niclas
My Gideros games: www.totebo.com
Comments
that kind of really kills the purpose of having SQL, data you should store should be splitted in normal form, etc. And it is hard to abstract it much then, except from ORM, where you populate class with queried data, as in you match your underlaying schema with an class structure, but again that might be an overkill for what you need.
So what was the reason for using SQL in the first place?
I want to use a database rather than a text file to avoid saving mostly redundant data which consumes processing power. In my game I want to store new x and y coordinates for each tap. The text file could eventually grow to 1MB or more.
If I use a text file I have to:
1. Read the entire text file into memory (for each tap)
2. Add the x and y coordinates
3. Save the entire text file
If I used a database I would instead:
1. Load the database (once per session)
2. Insert a row of new x and y coordinates (for each tap)
If I used a database it would mean a consistent time for saving coordinates, and if I used a text file the save time would grow for each tap. The overhead of regularly saving a text file that could exceed 1MB seems to me like a Bad Idea (tm), but then again, I haven't actually tested this.
Feel free to slap my fingers for using SQL as a means to do something that it wasn't actually meant to do.
Niclas
Store it in table, then put all new taps into table and on app exit event save it in the file.
It would make it even more efficient than sql (no writing on each tap).
About overhead, that might be true, as SQL probably use binary data, it will consume less.
And sql to insert and select x,y coordinates is not that hard.
but if you are concerned about file size, you could also split a normal file let's say by days, creating new file, or by game session, depending on your logic and when you need it.
So you must chose what seems to be more fit for you
Keen to try the SQL option for those reasons, so I think I'll give that a bash.
https://deluxepixel.com
Sinister: You mean keep a "passive" backup of the textfile, and revert if needed? That's clever.