rmdb's are a ridiculous way to run a chat application, other databases like mnesia (used heavily for ejabberd) work pretty well.
storage and querying are pretty typical functional requirements, I dont know how much more suited couchdb would be for chat than mysql, but you cant dismiss it because of the same preconceptions you have with other "databases"
hit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database
if querying history is a functional requirement then your data has to be stored somewhere, filesystem is an easy win, but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"?
My point wasnt even that couch would be particularly great at these, it was just that most of this "common wisdom" applies towards traditional rbdms, databases can be built with exactly realtime messaging in mind
hit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database
Disk. And it means your data is being written to the disk.
if querying history is a functional requirement then your data has to be stored somewhere
The stated functional requirement was "real-time chat". If you want to record all messages ever exchanged then you are not talking about a chat system anymore but rather about an archival system. For the latter a database can indeed make sense but the two should not be mixed together due to the fundamentally different requirements.
but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"?
By hitting the disk for each message.
databases can be built with exactly realtime messaging in mind
And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh.
"The stated functional requirement was "real-time chat".
I didnt see anyone list a functional requirement specification, I at least, was talking hypothetically. ITs worth noting that chat applications are almost(always?) never real time, they are soft realtime.
" two should not be mixed together due to the fundamentally different requirements."
Message routing and persistence are not mutually exclusive, they have competing requirements but that does not mean they cannot and do not exist. see twitter, banking, telecoms, campfire, ejabberd.
"By hitting the disk for each message."
If not hitting this disk is a a functional requirement then fair enough, I have never heard of this being a requirement outside of embedded systems.
"And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh."
I wouldnt mind knowing exactly what makes "messages" seperate from data. a database is just an abstraction layer over a set data that can provide several completely different benefits for storing and accessing that data, it isnt even required that a database "hits the disk" in the slightest, and there is no part of the definition of "database" that prevents it from being absolutely perfect for messaging systems, it just so happens that all the examples you can think of arent.
Ever wondered why those routers at your ISP don't have harddisks in them?
Anyways, you lost me the moment you mentioned twitter in a line with banking and telco systems. That's like bringing up the bobbycar in a discussion about jet engines.
*(sorry the reply button wasnt under your comment before)
just because they dont have harddisks doesnt mean they dont run a database, remember when I said databases dont need to touch the disk.
mnesia for example was built with exactly high throughput in mind, it can sit in memory only, I do believe mnesia is used inside various routers and switches, is it not a database?
and wow, twitter isnt cool so I guess my argument sucks, the point was different people have wildly varying requirements, and while we are talking about apples vs orange, a web chat vs a router, really?
"x isnt fast enough", "y isnt scalable enough" are inane statements, there isnt enough information to possibly make that distinction, as I said in my first post, if a database gives me extra functionality while satisfying every other of my constraints, its by definition "not doing it wrong"
repeating myself again, but we were arguing a hypothetical specification and the general statement "but using a DB for chat is a really bad idea."
that aside, the authors requirements for the application were pretty obviously to build something kinda fun using couchdb, he satisfied those requirement, and is obviously not "doing it wrong"
but next time you get into a discussion / argument like this, its usually a good idea to look at all points that have contradicted what you have just said, and say why they are wrong, or admit you were wrong.
saying twitter is not cool, some guys 100 lines of code isnt replacing irc tomorrow, or that routers arent using mysql are not arguments.
You were arguing for the sake of the argument, that's why I ignored most of your bullets as unrelated. You broadened the scope to "but what if his chat system needs to record all messages, brew coffee and babysit my dog, too"? Well in that case, yes, you'll need a database and lots of other things, too.
But as long as you're looking at a chat system with functionality like the one the original submitter presented, then there are good reasons for datastores (aka databases) and message brokers to remain separate entities.
I can only repeat: Twitter is not cool (it's an anti-pattern), people who don't understand IRC will keep reinventing it poorly, and a messaging system that hits the disk for each individual message needlessly (i.e. without being held to strong delivery guarantee requirements, which would be quite uncommon for a chat-system) is a waste of ressources.
We can't stop people from peeling their eyes out with forks, but we should at least refrain from defending such idiocy.
storage and querying are pretty typical functional requirements, I dont know how much more suited couchdb would be for chat than mysql, but you cant dismiss it because of the same preconceptions you have with other "databases"