Prototyping with UniVerse

Whenever I write about UniVerse - or MultiValue in general - I always refer to it as a business engine, which encapsulates the difference between this and the mainstream relational database model in practice. I have blogged before about the advantages of keeping the data definitions and business logic in the same space when it comes to speed of development and consistency of access.

All the same, in my day job I'm frequently working with SQL Server (it's practically impossible to make a living as an independent MultiValue consultant in the UK). So it's good when the opportunity arises to use both technologies together and to bring their respective strengths to the fore.

If the relational model is predicated on structure and rigourous design, the MultiValue model is founded on agility and the ease of managing complex data. And so in situations where change is the top of the agenda, and given the facility with which it can read and write SQL Server data, UniVerse can become a powerful tool for solving problems in SQL Server.

Two projects over the last few months have allowed me to do just that.

The first was a data cleansing exercise, pulling data that had orginated in different applications from different vendors and patching up differences and errors. Here the key piece is the granularity offered by the low level UniVerse read and write operations, especially when hunting down data that might be in one of several different places. True, it can be done in SQL Server by using temporary tables and lots of updates through potential joins, but UniVerse does it more neatly and with lower overheads.

The second has been more interesting. I've been asked to develop a new risk calculation engine that will eventually be written in C# for SQL Server. But before getting to that point, the calculations themselves must be modelled; different methods assessed; data checked for consistency; missing data provided; results scrutinized and business processes adapted. All of which argued for prototyping the financial calculations first.

Here, once again, is a job for UniVerse. The fact that UniVerse is metadata driven makes it very adaptable - just what you need in a prototype, especially when that prototype involves modelling different alternate operations to see which one fits the business needs best. You can change a file structure in seconds by adding or amending dictionaries, and calculations can be embedded into virtual field descriptors: more lightweight and powerful than using SQL views or stored procedures. Again, where data is difficult to come by, or needs to be split or merged in more complex ways, it may be synthesized or extracted using UniVerse Basic. So, despite the fact that the final delivery will be pure SQL Server, to model and remodel the prototype has been pure UniVerse.

One thing that has helped, is that over time I have put together a good series of dictionary-driven commands that allow me to script file and dictionary creation, importing from remote data source using BCI, exporting in various formats, pivoting and amending data. These are slower than the equivalent Basic routines, of course, but are more quickly adapted and easier to document as the prototype develops.

Over the coming months I will be adding these to the website, so watch the blog for details and instructions.