Podcast: Play in new window | Download (Duration: 56:41 — 77.8MB)
Panelists
- Aaron Patterson (@tenderlove)
- Charles Max Wood (@cmaxw)
- Fernand Galiana (@kitesurfer)
- James Edward Gray II (@JEG2)
- Peter Cooper (@peterc)
Items discussed in today’s episode
- amalgalite
- Queue Classic
- mysql
- postgresql
- sqlite
- mongodb
- redis
- tokyo cabinet
- oracle
- Aaron’s RailsConf Keynote
- GPL License
- MIT License
- key-value stores
- document stores
- memcached
- homebrew
- rabbitmq
- amqp
- beanstalk
- resque
- delayed job
- cassandra
- amazon simpledb
- hadoop
- couchdb
Panel Picks
- mongodump (Peter)
- mailcatcher (Peter)
- inliner (Peter)
- scheme (Aaron)
- chickenscheme (Aaron)
- mailplane (James)
- fluid (James)
- vimgolf (Charles)
- Contemporary VA (Charles)
- lastpass (Charles)
- jQuery.template (Fernand)
- bulk_api (Fernand)
- getaround.com (Fernand)
{ 9 comments… read them below or add one }
Hey guys,
The link to Mailcatcher seems to be broken
Cheers
Fixed. Thanks for the headsup.
FYI. Here is the correct link to Queue Classic => https://github.com/ryandotsmith/queue_classic
Fixed it. Thanks for the headsup.
I really enjoyed the podcast. What song is playing at the end?
Great podcast guys!
I’ve always thought that common practice is to use NoSQL solutions for caching or denormalizing already existing transactional (ACID) data. MongoDB is pretty solid, but not ACID compliant so there is still potential for data loss that I wouldn’t risk on Mongo.
I liked the discussion on MySQL and PostgreSQL. I’ve been looking at Postgres for a while and using it a little recently, but I didn’t know it had Pub/Sub capabilities.
Keep it comin’ guys!
Actually I’ve been using MongoDB as the primary application database for my last Rails 3 project (http://streamio.com which has been out in production since Rails 3 final came out, we started out early with the beta).
It’s been a good ride mostly although we have had to put in quite a lot of time bug reporting / patching Mongoid (which was in beta for most of the development time as well). With the ruby Mongo driver or Mongo itself we didn’t have problems though.
It wasnt until last week when I started doing this ActiveRecord thing however that I realized just how much Mongo had changed my expectations for development. The lack of built in support for nested hashes and arrays etc felt absolutely absurd. And dealing with migrations even more so. Your ruby objects fit into Mongo documents so much nicer than they do SQL tables. And after you get used to the new modeling concepts of Mongo you end up developing more freely and rapidly than before.
I dare anyone to try Mongo out for an actual project and see if they would want to return to SQL based alternatives after the experience.
“SQL or NoSQL?” Has a sillier question ever been asked? The answer is “yes”. One is not a replacement for the other unless you’re building toy applications. If you’re building complex business software “entities” go in a RDBMS and your software may be simplified by considering “value objects” be stored in a NoSQL database (or as serialized objects on the same RDBMS row as the aggregate root’s entity).
What’s worse was that none of the panelists asked “what the heck do you mean by SQL or NoSQL?!”
{ 1 trackback }