2 ms·

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,

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.

moe 17y ago
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.