CODEWITHSUNDEEP
jsondatabasenosql
Andrew
Andrew

Reputation: 169

Would a NoSQL be appropriate for storing user data?

I'm looking to offer users the ability to store their settings for the service on the server side, to allow them to synchronise data between devices.

I have not used NoSQL before so I am unsure if it is appropriate, however from the research I have conducted it seems to be a reasonable option.

So for example, if I were to store a user's settings in a JSON formatted string, and used a NoSQL database with their user ID as the identifier, the database would look something like this:

ID    | Data  
------|------  
1     | { "Example1":"foo", "Example2":"bar"}
2     | { "Example1":"bar", "Example2":"foo"}

Is that appropriate? One of the assumptions about the data is that it will not be particularly regular, as users will change a range of different settings to suit them and so whether a given option is enabled will vary greatly based on the user. This irregularity is what lead me to the belief that a NoSQL database may be more appropriate here for the sake of performance.
Instead of having to return long data sets with multiple different values, the client device will be passed back the JSON with their preferences, and this will be parsed as appropriate.

Upvotes: 2

Views: 3394

Answers (1)

stdunbar
stdunbar

Reputation: 17485

Based on the data you're showing, no, a NoSQL doesn't buy you anything. It doesn't hurt anything either but a relational would work just as well.

However, if you didn't convert the "Data" column to a string and, rather, stored it as an object:

ID    | Example1  |  Example2  | Example3 
------|-----------|------------|---------  
1     | foo       | bar        |
2     | bar       | foo        |
3     | blah      | baz        | qux

then you're starting to take advantage of NoSQL. Maybe user 3 is using a different system that has an additional parameter. With NoSQL it doesn't matter - add a new column anytime you'd like and the database will store it without any additional work.

Of course, the reading side may need to understand what data is stored in each column. It may have to introspect the data to see if "Example3" exists or it may not care.

In general the big thing you're getting is that you can store any set of data. Indeed there may be rows that are totally different from each other (though it tends to be easier if there is some similarities between the data). Additionally, depending on the system, you may find it easier to search for "Example3=qux". This is a bit provider dependent and may still require the use of indexes to provide a fast read.

Upvotes: 1

Related Questions