[erlang-questions] Re: Conceptual questions on key-value databases for RDBMs users

[Edmond Begumisa]

Sorry, I missed this bit...

On Wed, 10 Nov 2010 01:36:46 +1100,  wrote:

> In the distant past we wrote all the items on a single piece of paper  
> called an order. It was all on one physical page. The page contained all  
> the information.

I'm not advocating for moving towards data models that are more physical.  
I just want data models that are closer to my application's world-view. It  
just so happens that in this case, the model that make sense to my  
application is also close to the physical. Someone else with a different  
coding style might write the very same application completely differently.  
He should then have more freedom than SQL-RDBMSs typically gives for  
adapting the database to speak his language.

> For the same reason it is difficult to query pieces of paper (you need  
> to either index them or summarise them in another way), in the same way  
> it is difficult to query data with implied relations stored in a single  
> "thing" (blob/object/values).
>

I really don't see the difference. Whether you query line items that are  
inside the document or outside the document the human work is the same.  
The data still has to be pulled out (when it's inside the document you do  
this later when you need it, when it's outside you do this before-hand  
EVEN THOUGH YOU MIGHT NOT NEED IT). Either way you have to write that bit  
only once. And either way it probalby needs to be indexed.

My experience has been this: when I'm given the option of implied  
relations as you put them (I call these containers), I find my database  
design greatly simplified firstly because a good chunk of relationships  
devoted to containers are erased, and secondly because this is a concept I  
find I use a lot within my applications.

Using the order example, from *my application view*, it pulls the document  
 from the db and displays an order on the screen, lines items are  
added/edited are edited. The save button is pressed, I then write this to  
the db in one big doc as you describe it to the db. This happens to fit  
very nicely in the way the app is designed. I want it that way in the db  
*by design*

With the SQL-RDBMS two-table solution to this, I'd have to force my code  
to think of this in two steps (when the address is edited thats one table,  
when a line is added thats another table, grrrrr!) I've gotten around this  
in the past using various techniques, hierarchical data modeling being the  
most advanced -- a structure that is aware that lines belong to the order  
and can have various levels of depth but that has always been a lot of  
work.

The second stage, querying. My user wants all orders for the X-Box 360  
before July 30. No problem, I'd have a couch view for this sort of thing.  
Yes, sure the view essentially goes through all the orders but...

1) this is exactly what the my app needs (it is what the user has asked  
for)
2) Couch is smart about how it caches this
3) a SQL-RDBMS would essentially do the same thing (it would just walk  
though several tables instead and cache/index)
4) Couch would give me more control over the indexing

But here's the thing. You *don't* have to do it that way. That's just the  
way I usually approach it. I might be a terrible way. But it's *my*  
terrible way -- DB design constraints haven't forced things on me. With  
SQL-RDBMSs I always felt I was being nudged -- being told what was good  
for me. I never felt complete freedom.

And I might change my mind when I find orders contain thousands of lines  
and do it some other way, maybe the equivalent to the two-table RDBMS  
solution. I just find the NoSQL/kv-db more flexible in allowing the  
application developer to choose how he/she wants to do things. If I want  
to hang myself give me rope. That's my business. You're just the db. Don't  
be too smart.

- Edmond -

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/