

InfoWorld: Things Never To Do With A Relational Database   - osintegrators
http://osintegrators.com/opensoftwareintegrators%7C10thingsnevertodowitharelationaldatabase

======
macavity23
Meh, maybe at scale. I'd say you'd be better off bunging everything in your db
at first, and then extracting bits into more specialised data stores _based on
testing and real-world performance data_.

To take one example from there - storing images in your db - this might
actually be fine if you have a cache in front of your app servers, since your
db only takes the hit once and then nginx/varnish serves the request after
that.

Doing replication, versioning and backup for postgresql across a bunch of app
servers is fairly straightforward. If all of a sudden you're doing it for
postgresql AND mongodb AND lucene - and keeping all those backups in sync with
each other - it gets a lot harder, at least without downtime.

Nosql, lucene etc are great tools, but often they're premature optimization.
Make it work first using the simplest tools you have, then add complexity to
improve performance only where and when required.

~~~
acoliver
First off, if you're writing granny's addressbook it doesn't matter what you
use. RDBMS, NoSQL, filesystem, it will work, who cares. I assume that this is
at scale. It is a perspective of bill rates I guess :-) Not many grannies hire
me to write addressbook apps :-)

Secondly, prototyping your straight JQuery/HTML to MongoDB or Couchbase 2.0 is
SIMPLER than to the RDBMS where you must do XML transform first.

Search in RDBMS with ORs and LIKEs is hard and not a good idea for the RDBMS
or your middle tier or your user (reduced capabilities with more complexity).

Storing images in the DB vs say a clustered FS makes everything from
replication to performance to scalability. Get a few TB of BLOBs and tell me
this is a good idea.

------
bjhoops1
Very nice. I laughed to myself over "Search", remembering an absurdly
complicated query I once wrote to do a search against an Oracle table.

Ending up with a dynamically generated query which got really long depending
on how many spaces you entered... smh

