4 ms·

It's best to understand your problem domain and use the tools that are most appropriate. Sure. The big problem though is that the problem domain of RDBMS's is

It's best to understand your problem domain and use the tools that are most appropriate. Sure. The big problem though is that the problem domain of RDBMS's is ad hoc reporting which is pretty universal. rom my experience, you should be leaning towards NoSQL systems (of which there are many, each suited to different use cases) when you have very large scaling needs (in terms of dataset and qps), heavily polymorphic data, or data that has ambiguous structure. On the other hand, you should choose an RDBMS if you are pretty sure reporting needs will change or you will need to accommodate new metrics on a frequent basis. The problem is there is a huge overlap between those two. NoSQL means telling your customers "no, we can't do that new report you'd like right now." That's a huge tradeoff for any customer-facing app. After all the basic tradeoff is between flexible input and flexible output.

stickfigure 14y ago
Even for ad-hoc reporting, the relational model has limits. For some requirements specialized structures are a better choice; thus we have mdolap. RDBMSes were designed for an era of spinning platters, data volumes in the megabytes-to-gigabytes, and small volumes of long-running ad-hoc queries. It's remarkable how far we've been able to push a general-purpose design but it's starting to burst the seams. Do you want to design for easy reporting or easy scaling? There is no universal right answer because it's different for every app. There are times when I really wish I could run a SQL query. On the other hand, I spend zero time maintaining my (appengine) datastore and it automatically scales to any data or traffic volume. And I have a heavily polymorphic system which would be a nightmare in SQL. I don't think that overlap is as big as you do.
- einhverfr 14y ago
  Even for ad-hoc reporting, the relational model has limits. For some requirements specialized structures are a better choice; thus we have mdolap. But mdolap is far easier to work with if your feed is from a relational model. Otherwise you are left with a lot of effort getting the data transformed into an appropriate model. Relational math + fixed schemas means flexible output. I don't think that overlap is as big as you do. Any line of business app had better start with a relational model then, as would any case where you are selling business intelligence. The other data stores work best as adjuncts to, rather than replacements for, a relational store. Edit: Also it occurs to me that MDOLAP is only partly ad hoc. You have to set up your cubes ahead of time and that means deciding on what you are going to report. I imagine that adding a new reporting dimension to a large data set would be painful.

stickfigure 14y ago

Even for ad-hoc reporting, the relational model has limits. For some requirements specialized structures are a better choice; thus we have mdolap. RDBMSes were designed for an era of spinning platters, data volumes in the megabytes-to-gigabytes, and small volumes of long-running ad-hoc queries. It's remarkable how far we've been able to push a general-purpose design but it's starting to burst the seams. Do you want to design for easy reporting or easy scaling? There is no universal right answer because it's different for every app. There are times when I really wish I could run a SQL query. On the other hand, I spend zero time maintaining my (appengine) datastore and it automatically scales to any data or traffic volume. And I have a heavily polymorphic system which would be a nightmare in SQL. I don't think that overlap is as big as you do.

einhverfr 14y ago
Even for ad-hoc reporting, the relational model has limits. For some requirements specialized structures are a better choice; thus we have mdolap. But mdolap is far easier to work with if your feed is from a relational model. Otherwise you are left with a lot of effort getting the data transformed into an appropriate model. Relational math + fixed schemas means flexible output. I don't think that overlap is as big as you do. Any line of business app had better start with a relational model then, as would any case where you are selling business intelligence. The other data stores work best as adjuncts to, rather than replacements for, a relational store. Edit: Also it occurs to me that MDOLAP is only partly ad hoc. You have to set up your cubes ahead of time and that means deciding on what you are going to report. I imagine that adding a new reporting dimension to a large data set would be painful.