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

[Edmond Begumisa]

Java's James Gosling seems to share your views...

"... I've never got it when it comes to SQL databases. It's like, why?  
Just give me a hash table and a sh*tload of RAM and I'm happy. And then  
you do something to deal with failures. And you look at the way things  
like the NoSQL movement is. It's various flavors of large scale  
distributed hash tables and trying to deal with massive scale and massive  
replication, and you can't back up the database because no tape farm is  
big enough. And you find scale and reliability can fit together at the  
same time..."

http://www.basementcoders.com/transcripts/James_Gosling_Transcript.html

Funny, never thought two co-inventors of two different languages would  
actually agree on something :)

The main reason I've switched to NoSQL (CouchDB) after many years of using  
SQL-RDBMSs is for modeling hierarchical data. RDBMSs force you to do this  
with relationships across different tables even when the data belongs to  
the same domain/object -- this feels unnatural and results in the DB  
equivalent of spaghetti code with hours staring at relationship diagrams.

Take the simple example of orders that have items. In a typical SQL-RDBMS,  
this would normally be modeled using two tables related to each other in  
1:many orders->items. A kv-store like Couch allows me to store this in a  
more sane manner, just a bunch of orders, each with items embedded inside  
them. But where kv-stores really shine is when your data has uneven levels  
of hierarchy within the same types of objects. I've always struggled with  
this in RDBMSs.

I think a big reason kv-stores are winning over a lot of us long-time  
RDBMSs users is they allow us to model things-that-have-things-inside-them  
in the database much closer to how they are modeled in our applications.  
Orders/receipts/invoices with their items, users with their permissions,  
all these map nicely in kv-stores from db to application. This allows us  
to model relationships only when WE REALLY WANT RELATIONSHIPS (this  
receipt belongs to that invoice). That fact alone won me over and I've  
never looked back.


- Edmond -

On Fri, 05 Nov 2010 09:01:30 +1100, Joe Armstrong <erlang@REDACTED> wrote:

> On Tue, Nov 2, 2010 at 9:14 PM, Silas Silva <silasdb@REDACTED> wrote:
>> This is a message I sent to the nosql-discussion@REDACTED
>> discussion group.  I thought it might be interesting to send it
>> erlang-questions, so here we go...
>>
>>
>> Hi all!
>>
>> I have used SQL RDBMSs for some time.  I've never used any very advanced
>> feature, but I know enough of it to make database applications.
>>
>> Nowadays, I decided it would be interesting to learn some NoSQL
>> databases concepts.  So I decided to pick up some Erlang and Mnesia, its
>> native key-value database.  More than scalability itself, the most
>> valuable feature for me is the possibility of replication and
>> synchronization between nodes.
>>
>> But all pros have cons as companion.  The lack of a relationship model
>> is difficult for who is used to RDBMSs.  So, my question is:
>>
>> * Is there any guide, tutorial, book, whatever, that tries to introduce
>>  NoSQL databases to SQL users?
>>
>> * Key-value databases are surprising simple.  I know you solve
>>  relationship by denormalizing data.  What data should be normalized?
>>  What shouldn't?  How do you update denormalized data?
>
> I'm no database expert so don't quote me here ...
>
> As far as I am concerned traditional databases like SQL suffer
> from the fact that the data stored in an individual column is incredible
> simple - I can store an integer/string/... in a column but these are
> incredibly simple data structures. I want to store and retrieve  
> incredibly
> complicated things - how do I store an XML parse tree in a single cell
> of a database? - How do I store a database in a database ...
>
> In a decent K-V database the value of the key can be *anything* - an
> entire database for example, a compiler, ... no worries
>
> Then when I analyse my problem I start thinking "I can store and  
> retrieve any
> complex object that keys do I need to solve my problem?"
>
> I'm not thinking in terms of joins and normalizing things - the thought  
> process
> is different - so far I haven't met any problems that don't map onto  
> key-values
> queries.
>
> It seems to my that SQL provides you with the ability do to complex
> queries on simple things. K-V dbs can do simple queries on complex
> things.
>
> /Joe
>
>
>
>>
>> Sorry for such simple and general questions.  Things were simple up to
>> the moment that I realized that it would be easily solved with a JOIN
>> SQL statement.  :-)
>>
>> Thank you very much!
>>
>> --
>> Silas Silva
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>


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