Tag Info

Hot answers tagged

6

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.. ...


5

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. ...


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.


4

get rid of the document-based DB, its a horrible system for the kind of query you'll be doing. Go back to boring old RDBMS and you'll be a lot happier. If you do this, you can not only make reservations individually (which also help when someone adds a service to their reservation) but you can query all services assigned with a single reservation id. Simply ...


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

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


3

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 ...


2

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

As noted by John F. Miller on another question at SO (http://stackoverflow.com/a/5373969/1793074), MongoDB is great at nesting data, but not so grat to search this nested data. Another great resource on this matter comes from the same answer: http://seanhess.github.io/2012/02/01/mongodb_relational.html Basically, you relinquish control when you work with ...


1

I'm not familiar with Mongoose but we have started pushing configuration out of xml files and into the DB using ravendb. Our approach is to: We create a configuration object or object graph with sensible defaults. We write a configuration manager class that provides: automatic creation of the object if it does not exist singleton access to the class ...


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