In my experience, if you foresee needing to do a lot of updates where a "master" record would need to propagate its changes to other records, then in general a non-sql based data store may be the wrong fit for your data.
If you have a lot of data that doesn't really change or is not linked in some way to other rows (in Cassandra's case). Then a non-sql based data store could be a great fit. Yes, you can do some fancy stuff to force things like Cassandra to behave like an RDBMS, but it's at the cost of application complexity; more code, more bugs. I often end up mixing the data stores sql/non-sql to play to their respective strengths. If I start seeing a lot of "related" data, relational databases are really good at solving that problem. On Sunday, January 27, 2013, Fredrik Stigbäck wrote: > I don't have a current use-case. I was just curious how applications > handle and how to think when modelling, since I guess denormalization > might increase the complexity of the application. > > Fredrik > > 2013/1/27 Hiller, Dean <dean.hil...@nrel.gov <javascript:;>>: > > There is a really a mix of denormalization and normalization. It really > > depends on specific use-cases. To get better help on the email list, a > > more specific use case may be appropriate. > > > > Dean > > > > On 1/27/13 2:03 PM, "Fredrik Stigbäck" > > <fredrik.l.stigb...@sitevision.se<javascript:;> > > > > wrote: > > > >>Hi. > >>Since denormalized data is first-class citizen in Cassandra, how to > >>handle updating denormalized data. > >>E.g. If we have a USER cf with name, email etc. and denormalize user > >>data into many other CF:s and then > >>update the information about a user (name, email...). What is the best > >>way to handle updating those user data properties > >>which might be spread out over many cf:s and many rows? > >> > >>Regards > >>/Fredrik > > > > > > -- > Fredrik Larsson Stigbäck > SiteVision AB Vasagatan 10, 107 10 Örebro > 019-17 30 30 >
