Hacker News Reader

Comment by TheCoreh | Hacker News Reader

I'm going to be using JSON to represent data on pretty much all the parts of my App. (Since both the client and server are JavaScript, that's an obvious choice) I didn't want to copy all fields of my objects to a lot of enormous queries or something like that.

Also, my app will deal with a lot of tree-like structures, and representing them on a Relational DB would suck, unless I stored JSON on a text field. That seems like an ugly hack to me.

View on HN

Hey

Sorry but I don't understand this answer. I too like to hear reasons for decisions to stay away from non-relational databases.

Your first point, that you'll be using JSON, feels strange. When I build stuff, the data storage and the usage of the data are very separate areas. The web part using the JSON doesn't know or give a damn if the data is stored in MySQL or MongoDB or written in sand and translated to computer-speak by monkeys.

Second - Maybe I'm misunderstanding you, but isn't this tree structure a number of entities that have relationships with other entities (as parent / child / sibling / whatever). How is that not applicable to a relational database?

Since many NoSQL DBs use JSON to store the data, it seems you could save complicated conversion code between JSON and the db format by sticking to JSON throughout. That would be my line of thinking (I'm not the OP).

I think dbslayer would be perfect for this. Mysql is super easy to set up on a vps (there are lots of scripts to set up the whole server on sites like lowendbox or vpsbible) and then with dbslayer you get json and clustering if you want it so you can scale smoothly. It works great with node and there's already a module for it on Github @:

https://github.com/Guille/node.dbslayer.js/

Reply on news.ycombinator.com