http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Opss, I didn't know about this kind of DB, shame on me. They are exactly what I was looking for. If you add this functionality to RavenDB then it will be just brilliant, looking forward to it. Thanks a lot http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment11http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment11Thu, 29 Apr 2010 13:11:53 GMTMarco, You are thinking about graph databases. I will probably add some support for Raven to do so, but that is in the future. http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment10http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment10Thu, 29 Apr 2010 11:17:11 GMTI know that thinking "relational" is not the best approach here, but I'm wondering how can you handle an N to N relation between 2 documents type which are indipendent (they are indipendent entity) but they can be linked, and when they are linked then someone can put one or more comments explaining why they are linked together...is it something that RavenDB can solve or I should stick with the rational DB? Maybe a mix of the two could be the best in my opinion, model the documents with RavenDB but handle the relations using a "relation document" used to express the relation and which contain the comments... It sounds like an interesting idea ;) http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment9http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment9Thu, 29 Apr 2010 08:35:35 GMTI prefer fembots to shemales, tbh. Yes, that looked pretty ugle at times. Let's see what comes next. http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment8http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment8Tue, 20 Apr 2010 21:46:19 GMTTyler, The right way certainly include no shemales. http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment7http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment7Tue, 20 Apr 2010 20:37:03 GMTHa. I mistook one sentence for "Oh, we may gain some small benefit by being *shemales*". Can't wait to see the "right" way post. http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment6http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment6Tue, 20 Apr 2010 20:22:37 GMT@Ayende I see you've articulated it being the 'wrong' way to try to replace a RDBMS solution but my conclusion I've drawn from the wording of your original post is that blog posts do not belong in a NoSQL database but are rather best left in an RDBMS, not that a more ideal solution was already written and in your future post queue (which I still don't understand how people can blog so much that they have a future post-queue, as once a month takes enough time out of me :). >> it is like saying getting punched in the gut it better than being shot, I would rather avoid both I assume by this that you have a more appropriate solution forthcoming, I would still be doing bi-directional referencing in NoSQL databases but am looking forward to your proposed solution as well. http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment5http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment5Tue, 20 Apr 2010 15:09:33 GMTEdin, Of course you can, in fact, look at the future posts queue http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment4http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment4Tue, 20 Apr 2010 13:39:56 GMTDemis, You did notice all the warning about this being the WRONG way about it, right? Yes, I am using Raven's querying ability to sort of make it work, but I don't really like the solution. There is no need to do a bidirectional association here with tag/posts, by the way, I outline how to do this in tomorrow's post. I talk a lot about setting up the indexes based on your needs then. And I don't want to talk about advantages based on this model, it is like saying that getting punched in the gut it better than being shot, I would rather avoid both http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment3http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment3Tue, 20 Apr 2010 13:39:31 GMTI guess, we can expect another post explaining how to actually do correct design. If a DocDb is used the way you described above, I really don't see any benefit of it. OK, maybe speed. I think that Demis kind of showed some directions by saying that posts could be stored in sorted set and ordered by date. Also, I like the idea of 2-way link between tags and posts. http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment2http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment2Tue, 20 Apr 2010 12:44:11 GMTI think your solution is very much tied to RavenDB because your trying to use querying abilities built into the api. In other NoSql db's that support rich data constructs (e.g. Redis, MongoDb etc), the way I'd achieve the same result is by storing posts in a sorted set ordered by date. For anywhere I require a reference, I would create a 2-way link (i.e. bi-directional reference) storing the tag with the post and at the same time a list of posts with each tag the post has. That way you can query both indexes for the tags a particular post has as well as all posts matching a particular tag. This just goes back to the general NoSQL mindset you should have where you need to know what querying functionality you require up front so at the time you're storing data you can update the 'query indexes' accordingly. Other benefits you've missed is the speed increase which depending on your situation allows you to dispense of any caching logic or real-time/accuracy of the data your displaying. Antirez (the author of Redis) has an interesting post on his VM solution in which he talks about the Redis Virtual Machine implementation where Redis is like a 'Reversed Mysql+Memcached solution'. Where the data you frequently access is kept in memory and the Least Recently Used items are swapped out to disk: [antirez.com/post/redis-virtual-memory-story.html](http://antirez.com/post/redis-virtual-memory-story.html) http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment1http://ayende.com/4465/that-no-sql-thing-the-relational-modeling-anti-pattern-in-document-databases#comment1Tue, 20 Apr 2010 11:41:50 GMT