Tag Info

Hot answers tagged

5

You can do the same thing as in RMDBs, you reference by identifiers. I use MongoDB, so we can talk about this from that point. Tag: { _id: ObjectId('tag id'), tag_name: "nosql", tag_description: "blahblah' } Then in the Post { _id: ObjectId('post id'), tags: [ ObjectId('tag1 id'), ObjectId('tag2 id') ], title: "title", // etc.. ...


4

Easy; they don't. If you want join abilities, you have to implement them in your client code. Some of these APIs do it a little easier by defining a 'Key' type that makes it easy to store and use references, but you have to do a second fetch to get the referenced entity.


3

It's both: internally manages relationships like GraphDB but can work in schema-less mode like DocumentDB. So both.


3

This might be worse, or equal to your current situation: flatten the structure by splitting out confidence values into a second mirrored structure. It's flatter, but wider. assessment->values->teams->second name = "Hakan" assessment->confidence->teams->second name = 0.80 assessment: { values: { game : "Super Street Fighter 4: Arcade ...


3

Your question could be the topic of a semester-long college course. You need to break it down into manageable chunks. As such, I will just throw out some partial answers. One of the first things to look at in deciding which kind of database to use is what kind of queries you will run and whether you will know them all in advance of creating the database. ...


2

Check out the accepted answer on this question: http://stackoverflow.com/questions/4745911/nosql-databases My take on having worked with both types of databases is that the real advantages of NoSQL lie in their scalability. They are well suited for ever-growing blobs of stuff that needs to exist on many nodes. After all, these are the applications that they ...


2

I would store each guess as a separate document in a user guesses collection. The structure of each document would be as follows: Guess - userId - selectedImageId - correctImageId You may also store more information about the corresponding quick, such as the shown images and played audio. To generate statistics, you will need to run Map/Reduce over this ...


2

I think the fact that you're asking about a document database is likely reason enough to use it. Generally the most important aspect to think about in choices like this is whether the team has skill/experience with a technology. If you're open to trying a document database, that might be enough. But, from a more technological aspect, document databases ...


1

There are no visible holes in it as your requirements list is pretty short :-). Basically the longer the requirements list the bigger the chances to find holes in writing your own. In my opinion, using a NoSQL database for this scenario would fit: if the requirements are not for a full featured queue if the app will not have to move from the pull model to ...


1

I agree with MrFox. You need to consider that if you have several threads updating the same data in the queue, your database must support true ACID transaction or you will risk the same item in the queue to be processed more than once, besides getting duplicates of the same item in the queue. If the total data that you post to the queue is not in big data ...


1

You are confusing a few concepts here. Basically CMS is an Application that USES a Data store. The CMS its self will store file in either the File system or in a DB. These are not mutually exclusive. A CMS may use document oriented database but I don’t know of any that does. Your best bet (if not using an off the shelf CMS) is to use a standard DB, Store ...



Only top voted, non community-wiki answers of a minimum length are eligible