3 ms·
I've had a pretty good run at cleaning up after botched database jobs, so caveat emptor... Two things: 1. Most day-to-day problems involve relationships among
by ibejoeb 16y ago
I've had a pretty good run at cleaning up after botched database jobs, so caveat emptor...
Two things:
1. Most day-to-day problems involve relationships among entities. It's not stodgy or wrong to use a good RDBMS when that's the problem you're dealing with.
2. Many NoSQL adopters wind up building a relational database on top of something else. That's a fun job, but not everyone can afford to ditch 40 years of R&D and pretend they've invented something. I think a lot of the allure in implementing these solutions comes the hype, promise of a silver bullet-like solution, and the opportunity to dabble the intricacies of creating a database.
- yrb 16y agoYou could also arge that adopters 'sql style RDBMS' end up building a NoSQL datastore. If you find you are using a lot of EAV, polymorphic associations, multicolumn attributes, trees, graphs it might be a better option to go down one the on of the many NoSQL routes. Key/Value, Column Stores, Document and Graph databases. Sometimes you can make huge gains in design simplicity because you persistance and/or queries map far more cleanly. An interesting example of "NoSQL" on top of an "RDBMS" is Salesforce [1]. A huge upside to RDBMS in my view is that they are 'well understood' in production, and operations know how to deal with them. It is a big design space out there, and you can make a lot of tradeoffs :) [1] http://www.infoq.com/presentations/SalesForce-Multi-Tenant-Architecture-Craig-Weissman http://www.infoq.com/presentations/SalesForce-Multi-Tenant-A...