3 ms·

If I actually don't know what data I want to put into my DB before I write to it, is a Mongo-esque solution appropriate?

Someone 14y ago
I guess that, at the time you have the data in hand, you do know what kind of data you have and also have a rough idea about what variations will exist. If you don't, apparently, the NoSQL databases will work fine, but so would SQL databases that you tell "here's a binary blob". AFAIK, neither would support querying those binary blobs, though.
neya 14y ago
The other commenter is right - When you know what data you want to store, I'm pretty sure you can work out the storage options. For example, most apps that require a typical user registration and login can be done with a basic MySQL box or a PgSQL box. You can use (and should use) a NoSQL database when you have data that benefits from being non-relational and storing it in a relational db will actually cause you trouble. For example, let's assume this function: f(x){ return someHeavyComputationThatRequiresALotOfTime(x); } Let's say your specific use case requires that for well-defined inputs of the function f(x), you want the outputs immediately and processing this function for each request will cost you a LOT of resources (think CPU, RAM, etc.). So, in such cases, if and only if it makes business sense, you can store the inputs ranging from 0 to x and corresponding computed outputs in a NoSQL database and access it when needed, instead of actually computing it everytime. so, your data would look something like: {"input": 0, "output": 143532.3434} {"input": 1, "output": 22342424.0934} {"input": 2, "output": 33242423.2423} {"input": 3, "output": 346324634.4546} {"input": 4, "output": 321144563.2457} {"input": 5, "output": 536573462.5646} and so on.. Actually my example is bad because you can store the same thing on SQL db's too, but unless there is a very specific advantage[1] that these NoSQL db's have (multitudes faster read speed, lower memory consumption, etc.) you want to stay away from them. If you are evaluating a good NoSQL db for your project, then I suggest you check out Voldemort DB[2] by LinkedIn, which is actually pretty good and has some positive feedback from people running it at scale[3] without much of the marketing layer that Mongo has. [1] http://www.slideshare.net/nurkiewicz/projekt-voldemort-when-relation-database-is-not-enough-too-much http://www.slideshare.net/nurkiewicz/projekt-voldemort-when-... [2] http://www.project-voldemort.com/voldemort/ http://www.project-voldemort.com/voldemort/ [3] http://engineering.linkedin.com/voldemort/voldemort-collections-iterating-over-key-value-store http://engineering.linkedin.com/voldemort/voldemort-collecti...

Someone 14y ago

I guess that, at the time you have the data in hand, you do know what kind of data you have and also have a rough idea about what variations will exist. If you don't, apparently, the NoSQL databases will work fine, but so would SQL databases that you tell "here's a binary blob". AFAIK, neither would support querying those binary blobs, though.

neya 14y ago

The other commenter is right - When you know what data you want to store, I'm pretty sure you can work out the storage options. For example, most apps that require a typical user registration and login can be done with a basic MySQL box or a PgSQL box. You can use (and should use) a NoSQL database when you have data that benefits from being non-relational and storing it in a relational db will actually cause you trouble. For example, let's assume this function: f(x){ return someHeavyComputationThatRequiresALotOfTime(x); } Let's say your specific use case requires that for well-defined inputs of the function f(x), you want the outputs immediately and processing this function for each request will cost you a LOT of resources (think CPU, RAM, etc.). So, in such cases, if and only if it makes business sense, you can store the inputs ranging from 0 to x and corresponding computed outputs in a NoSQL database and access it when needed, instead of actually computing it everytime. so, your data would look something like: {"input": 0, "output": 143532.3434} {"input": 1, "output": 22342424.0934} {"input": 2, "output": 33242423.2423} {"input": 3, "output": 346324634.4546} {"input": 4, "output": 321144563.2457} {"input": 5, "output": 536573462.5646} and so on.. Actually my example is bad because you can store the same thing on SQL db's too, but unless there is a very specific advantage[1] that these NoSQL db's have (multitudes faster read speed, lower memory consumption, etc.) you want to stay away from them. If you are evaluating a good NoSQL db for your project, then I suggest you check out Voldemort DB[2] by LinkedIn, which is actually pretty good and has some positive feedback from people running it at scale[3] without much of the marketing layer that Mongo has. [1] http://www.slideshare.net/nurkiewicz/projekt-voldemort-when-relation-database-is-not-enough-too-much http://www.slideshare.net/nurkiewicz/projekt-voldemort-when-... [2] http://www.project-voldemort.com/voldemort/ http://www.project-voldemort.com/voldemort/ [3] http://engineering.linkedin.com/voldemort/voldemort-collections-iterating-over-key-value-store http://engineering.linkedin.com/voldemort/voldemort-collecti...