In the mailing list, we got asked about an issue with code that looked like this:

1:publicabstractclass Parameter

2: {

3:public String Name { get; set; }

4: }

5:

6:publicclass IntArrayParameter : Parameter

7: {

8:public Int32[,] Value { get; set; }

9: }

I fixed the bug, but that was a strange thing to do, I thought. Happily, the person asking that question was actually taking part of a RavenDB course and I could sit with him and understand the whole question.

It appears that in their system, they have a lot of things like that:

IntParameter

StringParameter

BoolParameter

LongParameter

And along with that, they also have a coordinating class:

1:publicclass ListOfParams

2: {

3:public List<Param> Values {get;set;}

4: }

The question was, could they keep using the same approach using RavenDB? They were quite anxious about this, since they had a need for the capabilities of this in their software.

This is why I hate Hello World questions. I could answer just the question that was asked, and that was it. But the problem is quite different.

You might have recognized it by now, what they have here is Entity Attribute Value system. A well known anti pattern for the relational database world and one of the few ways to actually get a dynamic schema in that world.

In RavenDB, you don’t need all of those things. You can just get things done. Here is the code that we wrote to replace the above monstrosity:

It's funny that with few simple (uh, not for everyone) additions a RDBMS can become much more flexible. First is multi-valued fields (array fields), and the second one is a dictionary column (key-value container without a schema). PostgreSQL has them both (hstore and array columns) with querying and indexing capabilities in SQL. I hadn't had a chance to try it yet but it looks like a nice workaround for these limited by flat schema rigidity. And as a cherry on top of that theres the 'GIN' index for full text searching... are these guys trying to compete with NoSQL or what?