incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: show/list
Date Fri, 15 Nov 2013 01:13:41 GMT
On Fri, Nov 15, 2013 at 4:50 AM, Filippo Fadda
<> wrote:
> On Nov 15, 2013, at 12:36 AM, Alexander Shorin wrote:
>> Yes, you can!(: Since we hadn't define any task to solve with these tools.
> This is not an argument Alexander. :-)
>> Certainly, they couldn't be compared since CouchDB explicitly strict
>> you within single document or view result namespace. Sometimes this
>> only leads to more clear design since you're not able to make cross
>> references between different logical objects. This is how
>> document-databases design works and I'm sure that if you need joins on
>> server side probably you have wrong data design.
> Not true. Sometimes you need joins to avoid conflicts.

Need some example.

>> Certainly, with plain ruby and rails you can do much more things that
>> with only CouchDB design functions. But again, if your task could be
>> implemented as couchapp - what's the reason to setup additional
>> application tier in front of CouchDB?
> The reason is pretty simple. Your CouchApp may fit the initial functional requirements,
but your client (or your users) is gonna ask you new features and new features are translated
in other functional requirements. At this point you find that your CouchApp can't satisfy
them, because the limitation we all know. What do you do? You are gonna rewrite all or you
start with something that can deal with a new degree of complexity?

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.

>> Btw, if you share interesting idea of the app that you think isn't
>> possible to be done as couchapp I'll make tutorial for docs based the
>> solution (:
>> Currently this is going to be issue tracker, interesting enough?
> You don't need to start the tutorial, because I'm sure I can add some requirements to
your app, that you can't satisfy. I just give you an example.
> In the application I'm writing I have to keep trace of the impressions (views) of each
article. To avoid conflicts I can't update the 'article' document every time a user read it,
so, the simple solution that comes to my mind is to store a document per impression. Now,
I want a view that show the article and I want also show the impressions count. But since
the impressions count can be just obtained querying a view (using _count as reduce func),
you can't do it in a show, so you can't do it in a CouchApp, ouch!

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.

> But I tell you more. You should now there are two types of requirements: functional and
non-functionals. Non-functional requirements can be divided in many other subtypes, for example
the so called Capacity Requirements. One of my Capacity Requirements says that my database
size can't grow too much in a period (let's say one year), because, let's suppose, I have
a budget and I can't afford a bigger and more expensive hosting plan. Since storing impressions
take a lot of space because I have over 100.000 articles and about 5.000 per article, this
solution can be used. Wow, we just found that CouchDB doesn't fit my needs, because it doesn't
satisfy the Capacity Requirements. So, to store the impression count I'm gonna use Redis.

See above. CouchDB isn't good for high rate updates since it fsync
every changes on disk without keeping things in memory. That's why
you're sure that all your data is actually stored. The opposite side
is mongo, where you can have high update rates, but since memory
storage you may loose data with easy.

>> Postgresql has all of this (ok, replication is master-slave, but still
>> it fault tolerant enough) and it's blindly fast, even faster than
>> mongo for JSON data, but much more stable. Why do I have slow HTTP
>> requests to database on my backend? Nonsense. Everything else could be
>> easily done on rails side, as you pointed above.
> In fact PostgreSQL is much better than CouchDB (in term of functionalities) and Oracle
is much better than PostgreSQL. I think it's normal since they have a long story and evolution.
But I don't want use an ORM, I don't want write SQL and I want the flexibility of a schemaless
database, even with his own limits. And I like CouchDB, let me use it, please. :-)

Ok (:

>> Well, and how they different from show/list/update functions and
>> commonjs modules? Not in implementation details, but in spirit of the
>> task they aimed to solve.
> They are powerful, you can't imagine how much powerful they are. They can do everything
on data, any type of manipulation, they can be extended. In Oracle you can also use Java to
write your stored procedure, not only the native PL/SQL.

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!


View raw message