On Nov 15, 2013, at 2:13 AM, Alexander Shorin wrote: > Need some example.
A simple one. Reddit, votes per post. > Certainty, your users may ask to add missiles control panel for their > blogs, but sometimes you need to say "no" for features, that goes > beyond of your project idea. If they still are within it and you got > some design issues: may be something wrong with it. You can't even know what a client is gonna ask you or where the business is gonna drive you. You can just make speculations. > If you aware, document updates for CouchDB have high cost (time and > disk space), so this is the last thing how you'll use CouchDB. To > count article views you need setup external handler that will act as > HTTP proxy to redis and trigger it on every article load by browser. I'm aware, but this is not the point. I'm trying to demonstrate there are cases where CouchDB doesn't fit the requirements and others (more often) a couch app doesn't. Put Redis aside CouchDB is easy, using a framework aside a couch app is not a viable solution. You can replace impressions with votes. To avoid conflicts you save each vote as a separate document, to get the score you need to assemble the article and a _sum result. :-) > Same as for design functions: make them in > python/php/ruby/java/clojure and use all power of these languages. > Even for additional querying CouchDB on your risk since this is wrong > way to go! Of course, I can modify my query server to use ElephantOnCouch, but like you said, it is not the right way to go and I don't see a use case for it. If I have some heavy elaboration task, I can use a daemon, I can use Gearman and execute a PHP job inside it. -Filippo
