On Fri, Nov 15, 2013 at 5:49 AM, Filippo Fadda <filippo.fa...@programmazione.it> wrote: > On Nov 15, 2013, at 2:13 AM, Alexander Shorin wrote: >> Need some example. > > A simple one. Reddit, votes per post.
Vote as document is ok. >> 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. It's always possible to imagine situation when some tool will be useless and some other handy and good (: CouchApp is no more, but group of design functions as single logical application, that CouchDB easily hosts and able to execute by users request. To interact with other system or remote services you may use external handlers. To run custom background services os_daemons helps much. All these are CouchDB features that could be used to solve specific problem. Not sure why you're trying to avoid them all. > 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. :-) While votes are ok, but having article hit as document isn't wise approach: to note why share your app url on /. , /r, hn or other resource which could generate a lot of hits - you'll quite soon realise that some front-end proxy required to buffer updates and forward them to CouchDB as bulk update. >> 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. But this open doors for you also to rich php library set which may be quite useful, right? -- ,,,^..^,,,
