On Sun, Feb 13, 2011 at 1:19 PM, Anand Balachandran Pillai <abpil...@gmail.com> wrote: [...] > So an approximate rule of thumb would be, > > 1. If your data is highly structured and you have complex queries > and your clients expect consistent results, stick to RDBMs. > 2. If your data is more like a simple key-value store and you > are more worried about query/response times rather than the > consistency of the data, perhaps a Document storage (no > sql) design is the correct one. > > To me both these worlds are complimentary to each other. > I don't believe in the so-called 'sql' vs 'nosql' wars. That is > simply a media hype. [...]
The above are good rules of thumb. One can even mix-and- match, e.g., dynamic data like session IDs, and articles read by users in current session can go into a noSQL key-value store, with more permanent data and relational data coming from databases. The noSQL term now covers a whole range of technologies, some of which have no easy parallel in the RDBMS world. One such example is graph databases, one useful application of which is as an RDF store for ontologies, such as those used in bio-informatics, and the semantic web. Finally, as Ramdas mentioned search needs, one could look at Apache Solr, and/or the underlying layer of Lucene. This uses a flat index to store data, and is blazingly fast. There are reasons why normal database search cannot match these speeds. So much so, that we also use it as a store for much data that would otherwise come from databases. Regards, Gora _______________________________________________ BangPypers mailing list BangPypers@python.org http://mail.python.org/mailman/listinfo/bangpypers
