3

I've done some research on HTML5 local storage, and it seems plausible that I could mirror a MySQL database's structure for use in an application that needs a lot of data for only one person.

Why would I do this? In my spare time, I'm a web game developer: PHP, MySQL, and all the technologies to dress it up. So far I've built databases that support many players, but my games are intended to be "single-player with multi capabilities". And for games that are only intended to be played single-player, there's no point in even having a DB connection unless they're saving to a web server!

I want to achieve a single-player mode that will never touch my database, and will be available offline. However, the code behind all of this is still going to be making SQL queries. Ideally I imagine that I could set up a sort of abstraction layer of local storage that would respond to queries.

And in short, I'm wondering what's out there. Searching local storage and HTML5 will give you endless posts about the technologies, but I'm not certain that my idea here will work well, or should even be attempted. Likewise there could be frameworks out there already that handle this with ease. I've found nothing yet.

update: The deprecation of web SQL database worries me. It looked very appealing for my situation; as it uses SQL, modifying my queries shouldn't be so difficult. Now with a push toward IndexedDB, I'm not certain it will be as easy.

Vael Victus
  • 3,966
  • 7
  • 34
  • 55

1 Answers1

1

I've read your question a few times now and continue to wonder 'Why would you do this' ;-) The question brings up more questions for me, so...

What do you mean by 'a lot of data'? Ultimately speaking, is the sql metaphor appropriate in this case? Abstraction layer that can respond to 'sql-like' queries is interesting in and of itself, but sounds extremely complex. Could a simpler solution do the job, like a JSON object? What about persisting the data in cases when users clean cache, history, re-install the browser, etc? Even complex javascript literal or JSON object could provide very straight forward means of occasional persistance/backup and recovery. (It's interesting that just released PostgreSql 9.2 includes JSON as datatype. Could it be that SQL and NoSql will gravitate toward some common ground?) Sorry if this comes off as more of a commentary than an answer, your question comes off as being on a higher plane.

EDIT

googling 'javascript sql interpreter' turns up some interesting stuff:

http://www.terminally-incoherent.com/blog/2009/05/19/sql-emulation-tool-in-javascript-part-2/#comments

https://github.com/forward/sql-parser#readme

Generating a JavaScript SQL parser for SQLite3 (with Lemon? ANTLR3?)

http://jsdb.sourceforge.net/demo.html

Community
  • 1
  • 1
vector
  • 7,334
  • 8
  • 52
  • 80
  • 1
    For sake of example of 'a lot of data': 20 tables, 15 columns each. SQL is appropriate, I believe, as my goal is to build for the actual database first, and then have a simple way of exporting that data to a local version of it. (structure and all) JSON Object is a very good question! Truly just stuff all the data (all 20 tables, everything) into a massive object? I'm not sure, do you think it could really be that simple? Persisting data would go no farther than saving a copy of the player's stats into the DB with a 'save' button. I appreciate your effort on this one. – Vael Victus Sep 17 '12 at 18:38
  • ... then how many rows? After all, one way to look at JSON is as one big *ss string. I can't imagine that being more complicated than a whole sql-like persistence layer. First I'd try to go with the simpler solution. Then look at how and what could/would break it. Even if you replicate sql abstraction, you'll have a heap of JS and still will have to deal with a model plain JS model that can be fed to the DOM. – vector Sep 17 '12 at 20:26
  • 1
    D'oh! I wasn't even thinking of the rows, which could range from 1 to quite a few rows. For example, the inventory of the player. In a game with 100 items of a player's inventory, many rows to track the relationship of characters, and whatever else could be added, the JSON string may get too complex... wouldn't it? Would it not? I'm all for the simple route. And would this still hold to database queries? I don't want to have to change any code in order to get it working. Thus the virtualized/abstraction layer database bit. – Vael Victus Sep 17 '12 at 20:53
  • I guess the string would look pretty complex as a string, as a JSON object - maybe not so. So you're looking at a DSL that needs to talk to some data representation. You might very well be looking at rolling something rather unique :-) Congrats! What do you mean by " And would this still hold to database queries?" – vector Sep 17 '12 at 21:06
  • If if it has to be sql, how about a Java applet with an embedded sqlite db? You could talk to the applet via javascript with ease and you would have something to real sql on the other side? Applet could even write the stuff to disc (if user agrees to it). Just thinking out loud here. – vector Sep 17 '12 at 21:15
  • The java applet would be a little much for only this. What I mean by holding to database queries is that I know, for sure, I'll have multiplayer games in that I'm always building for a connection to a server. I then want to say, oh, not online? Okay, save to their local storage instead. It really sucks that Web SQL DB isn't being supported by FF, because it seems that I could mirror some functionality pretty easily. Regardless, I think it's sad to say that right now, I might just have to wait for HTML5 storage to mature a bit more before I can see my ideal situation realized. – Vael Victus Sep 18 '12 at 12:17