Hacker News Reader

Comment by cmircea | Hacker News Reader

Seems RethinkDB is still relational. Meh.

If you're using C#, I'd recommend RavenDB.

RethinkDB sounds like it's document oriented from their site: "RethinkDB is built to store JSON documents, and scale to multiple machines with very little effort. It has a pleasant query language that supports really useful queries like table joins and group by, and is easy to setup and learn."

Also not sure why relational == Meh.

RthinkDB does sound promising though not ready for primetime. The following (critical) features are still in the development pipeline: Secondary indices, a db backup tool.

Definitely, we're leaving the production-ready tag off until we've built in some of these features.

Secondary index support is ready to go, we'll be releasing v1.5 with it in a few days.

I read your site and your system sounds very promising as I said in my previous post. It seems like you've identified some of the key problems with earlier noSQL implementations and that you're trying to solve them. Schema free was always a feature I could understand but "no joins" always sounded like an anti-feature to me. The promise of consistency and automatic sharding / replication is very nice but I'll remain skeptical until I hear about some production implementations.

My apologies, I thought RethinkDB was a relational database; the mention of joins gave me the thought, as I don't know of any other non-relational database that directly supports joins.

What do you mean by the term relational? Do you just mean 'Doesn't use JSON'?

http://en.wikipedia.org/wiki/Relational_database

Mike @ RethinkDB here-- the document model is similar to MongoDB in that you store JSON documents, and there are no schemas, so it's not a relational database.

Our query language (ReQL) does support a lot of SQL-like queries, such as group-by and JOINs, but there are no relations defined.

It's also worth noting that a great team has sprung up to build a C# / .NET driver for RethinkDB (https://github.com/mfenniak/rethinkdb-net).

Hi Mike!

That's good to know, I'd like to give it a try, but only OS X and Linux seems to be supported.

That's right-- an enterprising soul is working on porting us to FreeBSD (https://github.com/rethinkdb/rethinkdb/pull/688), but we are notably missing Windows support-- we hope to get to it after adding some more core features (secondary indexes, etc.)

Interesting will have to have a look.

I built a tool to track rankings for part of Reed Elsevier and I used mogodb but in a hybrid form using mysql db for the fixed stuff and mongodb for the representation of the first 120 results for a given language,engine,locale tripple

1. RethinkDB is a document orientated database, you store data very similarly to how you would in MongoDB / CouchDB.

2. Relational == Meh? Please elaborate, we're all waiting.

The relational model is not suitable for what most people are using relational databases for.

That's why there's a whole bunch of ORMs, with varying degrees of magic. It's also the reason some people were crazy enough to use relational DBs for key-value storage (eg. Reddit).

"is not suitable" is no more a concrete answer than "meh".

Please try and give reasons rather than restating the assertion.

http://ayende.com/blog/153026/embracing-ravendb

The points in the blog post apply to most non-relational databases.

That blog post is based on some pretty flawed understandings. The reason for normalisation (which I assume is what it's referring to) is not simply to improve write performance - indeed, it can make that slower too. It's because normalisation makes maintaining data integrity vastly easier. It can also improve performance, in as much as it improves the cacheability of your data by reducing its size. Further, when it comes to more complex data types, that's not a fundamental limitation of relational DBs - Postgres, for example, supports some quite rich datatypes.

I have no doubt that document stores save you a bit of time in the early stages of a system. Not sure if I'd trust them to be reliable in the long run as your application-stored schema changes over time, though.

>> If you're using C#, I'd recommend RavenDB

I would give anything to get back the time I spent developing my app using Raven and develop it with SQLServer instead. Ironically I feel so trapped by the schemalessness now that there is a not insignificant amount of data to port if I do need to make a significant schema change.

DO NOT FEAR THE JOINS!

What did you not like about raven?

What makes you recommend RavenDB for C#? Just the .NET API? Honestly curious.

Reply on news.ycombinator.com