[erlang-questions] Re: Conceptual questions on key-value databases for RDBMs users
Tue Nov 9 22:15:02 CET 2010
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
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
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
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/
More information about the erlang-questions