RVZ

As I told in the last post, in this article I will talk about the solution that we are using and why we take apart some alternatives.

The data model

The first thing we treat was how to model the reality that we have. We think, initially, in a model like the next one:

The first thing that we try to model was the calculations. The calculations shoudl have a magnitude to meassure, the units of this magnitude and the calculated value. We can also have one or many input values or  initial conditions. We also have a source to identify  where the calculation was generated.

The next thing that we try to reprresent was the input values or initial conditions, we wan't a  really dinamyc system so we model the initial conditions as a magnitude, associated to a unit and a value. It let us use complex input values, but we have to create false units for some input values that don't have units, like electronic configuration.

The next thing modelled were the units. Every unit would have a symbol, and a value that holds a detailled description of the unit.

Finally we model the magnitudes that will have a value with the description of the magnitude, and the sources with a  description of the origin as value.

Implementation

To implement the model described we decided to use CouchDB, as we told before, because it let to translate easilly the dinamic model that we explain before.

We thought use views to generate all the searches over the differents parameters, but we reallized that the way that views use to filter and make searchs was too weak for our needs. So finally we choose to use CouchDB-Lucene to generate the index of the documents. That let us make more complex searchs.

The next problem was where to put the application. Our first idea was use CouchDB advantages and try to put the application inside CouchDB, so our application will migrate throught our network as the data does. But That solution was not good, because we wan't to have a REST interface and if we put the application like a document in CouchDB we have to call every time with a GET http command. The alternative way was have a web server that receive the REST petition and generate CouchDB petitions. With this solution we will have a REST interface, we can define a nearest to our problem API, and we get HTTP authentification too. We can also make our application in the language that we want and we will not tied to use JavaScript. Finally we dediced to use this option, making the application in Ruby with Sinatra (still in developtment), but we don't forget the idea  to make the application travels arround the net.

Calculus Architecture

In the next post I will talk about the details of the development, how we make the index in CouchDB-Lucene, how we use Sinatra and so on. I promise that the next post will be more technicals than the previous one.