couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filippo Fadda <>
Subject Re: show/list
Date Fri, 15 Nov 2013 00:50:48 GMT

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.

> 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?

> 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!
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.

> 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. :-)

> 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.

View raw message