Valentina Database White Paper

Introduction to Valentina Advantage

Valentina is a cross-platform, object-relational SQL/API database system designed to provide a generational step in database superlatives: exceptional performance, modern database model and a complete set of integrated tools for the development and management of database-enabled applications. This document gives a brief description of Valentina benefits.

Extremely High Performance

The primary contributions to Valentina performance are following:

Columnar Storage

Valentina organizes data on disk in columns. (so called vertical format)

Values of a table field are stored as columns (arrays), in contrast with storing table fields as rows. When a query needs to access only a few columns of a table, only those columns needed are read from the disk. In contrast, in a row-oriented database, all values in a table are usually read from the disk.

Vertical storage formatting is completely transparent to users. A Valentina user works with a standards-compliant SQL interface or optionally using the API of a supported programming language. Migration of existing relational databases to Valentina requires no changes to most standard SQL queries or to the database schema. To gain even better performance, however, developers will want to take advantage of Valentina unique features.

Powerful Indexes

Valentina uses several types of indexes to get the best results: smaller size on the disk and faster work. Valentina does not use B-tree indexes like most databases available. Valentina itself is able to choose the best type of index.

You can create indexes based on calculated fields; you can even create indexes by using any valid Valentina SQL expression on a single field or combination of fields to get the best results.

Get more information about Valentina Database Indexes.

Bitset Calculations

Valentina was originally developed and optimized to use bitsets for resolving queries.

Many Algorithm Branches

There are many possible combinations of algorithms for solving any one database task. There is usually a general algorithm that works for most common database tasks; there are others that are more specialized for performing specific tasks, which are optimized for performance, unlike the general one.

A part of the Valentina specification is to provide as many variations as possible for achieving the greatest performance gain.

Advanced Cache

Valentina has very advanced, highly optimized cache. One of its advantages is optimization to reduce disk I/O overhead.

Advanced SQL Optimizer

Valentina has advanced SQL optimizer, which chooses the best way to resolve SQL queries.

Pool of Queries

Valentina utilizes pools of queries to significantly improve performance of cached queries. This feature works transparently.

If you send to Valentina a query that is byte-to-byte the same as some other query stored in the pool, Valentina extracts from the pool the compiled form of a query and execute it immediately.

Advanced Client/Server Protocol

Valentina Server utilize a packet-based protocol, while many popular DBMS use stream-based protocol. Packets allow to solve many tasks in effective way. In particular, we can compress packets itself, what is not possible with data streams. This can reduce the network traffic in 7-10 times, increasing performance.

Stored Procedures

Valentina offers you stored procedures by syntax close to SQL92 standard. Using stored procedures you can develop business logic, which will be executed on server side, dramatically reducing network overhead.

Valentina Database Model

Although we emphasize again and again the incredible speed of Valentina, Valentina initially was engineered to introduce a new paradigm of database development and management.

The first step in database design is to design the logical model of the database structure. Some database developers use an ER model, other use UML. In each case, you define objects with attributes and Links between the objects. For example Object Person and Object Phone linked as Many to Many by the link with “Has”.

When you finish the logical design you then need to implement it in the physical model of a database system. If you are implementing this in a relational database, you then translate your logical model as tables - and not much else except tables.

In other words: do you have links in your logical model? Sorry. Convert them into Tables. Do you have properties of objects? Sorry. Convert them into Tables. Do you have collections of objects? Sorry. Convert them into Tables.

Database developers actually try to mirror the real world - and the real world contains objects with properties, relationships (links) between objects, state of objects, processes in time, and so on. This is why, we believe that the next generation DBMS should be armed with a model that easily and effectively mirrors objects and links of the real world (as well as other entities).

Another important paradigm in Valentina is evolution. C++ compilers are able also to compile older programs written in C; so in the Valentina database model, you should be able to use existing relational databases. This is why Valentina database is referred to as an Object-Relational (OR) database.

Beyond the support for relational models, the new Valentina paradigm also provides:

  • RecID field

Every Valentina table has this field. Each record when created gets its own RecID, which is never changed. RecID takes up no disk space, in contrast with regular PK on ULONG field. A table with a million records in other databases need:

DATA : million * 4 bytes     =  4MB
INDEX: million * (4+4) * 1.5 = 12MB 
TOTAL:                       = 16MB 

This feature lets you avoid the creation and overhead of artificial Primary Keys in tables - reducing disk space, improving speed, and reducing development time.

  • OID Field

All Valentina tables have OID fields, with the exception of RecID fields. This field contains an 8 bytes LLONG value, which is unique in the scope of the whole database. This field was inspired by the pure OODBMS model. The huge advantage of Valentina solution is that this OID field again consumes no disk space. Compare to million table for other dbs, which need:

DATA : million * 8 bytes     = 8MB 
INDEX: million * (8+4) * 1.5 = 18MB 
TOTAL:                       = 26MB 

  • a new abstraction “Link”.

Valentina currently supports three types of links:

  • Foreign Key Link.
  • ObjectPtr Link.
  • Binary Link - supports not only 1:M but M:M.

The big advantage of supporting different link types is that developer can work with them using the same API interface I_Link, I_Link2 or SQL commands.

  • Foreign Key Link

RDBMS use a Foreign Key as a constraint. These are applied to the values of some field (FK) of a child table, with a set of actions that the RDBMS should execute ON UPDATE or ON DELETE of parent record. As a result, RDBMS is able to provide consistency of values in FK and Primary Key fields.

Valentina Database Model presents the Foreign Key as a Link of 1:M type between two tables. The name of constraint now plays also the role of the link name.

This is not just another variation on FK. Valentina implements this as a kind of Link; it is used in all portions of the database engine that works with any kind of link, such as Join builder.

TIP: you can think about this extension similar to new point of view on C language struct as a class with always public scope.

  • ObjectPtr Link/Field

ObjectPtr is a special kind of Field, which is also a 1:M type link. It is similar to Foreign Key in usage, but simpler and more effective. It points not at a primary key of the parent table, but at its RecID field. Joins on ObjectPtr links can be 4 times faster than Foreign Key-based joins, because, as described above, RecID fields has ZERO disk-weight.

  • Binary Link

Binary Link is a unique feature of Valentina engine that provides a special structure to store links between two tables of M:M type.

This kind of link uses at least 1.5 times less disk space compared to a third table which should be used to establish link M:M between two tables. Binary Links are able to build joins of two tables which is 8 times faster than the third-table way because there are fewer indexes to touch.

  • Link Refactoring

Provides easy way to convert one link type to another using single SQL command.

For example, you can convert into Valentina some relational database, later decide to start using the binary link between the tables T1 and T2 instead of third table T12. Valentina gives you single SQL command way to do this task.

  • Properties of Schema Objects

You can define your own persistent properties of Tables, Fields, Links and other objects of the database schema. For example, you may want to assign a COLOR to each table in your application.

With a relational model, this task also can be solved of course, but you will have to define additional table(s) for this information which results in unnecessary bloat. Also, you should write special code that will support this logic. Now the knowledge that tables of this database have colors exists in the developer's head and in the code of this single application. It is just implemented in an odd way with help of “special” table.

It is important to note, that any other application based on the same RDBMS engine when opening this database will NOT see colors. It will see only N tables.

Now let's look at the Valentina model. You just define a new PROPERTY of TABLE COLOR. This property now works the same way as other properties of Tables. You can see it, for example, in the SHOW PROPERTIES command. And any Valentina based application will know automatically that COLOR is a PROPERTY OF TABLE, and nothing else.

Smarter SQL

Since Valentina knows much more info about the objects and links stored in a database schema, Valentina is able to do much more smart job resolving SQL queries. In particular, you can write shorter SQL commands, and Valentina will be still able to resolve them correctly.

For example, compare these SQL commands

RDBMS:

SELECT Person.*
FROM Person JOIN PersonPhone ON Person.id = PersonPhone.person_ptr
            JOIN Phone       ON PersonPhone.phone_ptr = Phone.phone_id
WHERE Number LIKE '99%'

Valentina:

SELECT Person.*
FROM Person, Phone
WHERE Number LIKE '99%'

As you can see Valentina does not require from you to type each time like a monkey how to link tables Person and Phone. Indeed, Valentina already knows links between these two tables and is smart enough to find the default way itself.

Valentina Database Architecture

Most commercial databases provide only one of the following:
a) embedded engine for work with local disk files
b) client/server.

In contrast, Valentina can work with local and remote databases using the same sources. To resolve this task, we have design Valentina engine using C++ interfaces (similar to COM or CORBA technologies):

  • public interfaces define API to work with the engine.
  • implementation of these interfaces to work with LOCAL database.
  • implementation of these interfaces to work with REMOTE database.

As a result, we have come to three main DLLs: VSHARED.DLL, VKERNEL.DLL and VCLIENT.dll.

  • VSHARED.DLL - contains public interfaces and sets of common classes such as Array, String, ZIP, JPG, Files and more.
  • VKERNEL.DLL - contains the heart of Valentina engine: classes and algorithms which do work with local database files.
  • VCLIENT.DLL - contains implementations of public interfaces in the form of stub-classes which talk to proxy classes in Valentina Server.

Thanks to such a design, you can develop applications being:

  • LOCAL only (uses VSHARED + VKERNEL DLLs).
  • CLIENT ONLY (uses VSHARED + VCLIENT DLLs).
  • LOCAL and CLIENT at the same time (uses all DLLs).

Valentina Tools

The Valentina product line includes integrated tools to develop database-enabled applications.

  • Valentina ADK - Application Development Kit.

ADKs plug Valentina DB into the most modern, popular programming languages and platforms: C++, .NET, Objective C, COM, VB, REALbasic, Director, PHP, Ruby, Revolution, …

These are provided as a 4th DLL linked to VSHARED, and weak linked to VKERNEL and VCLIENT. ADKs expose public Valentina APIs to programming languages as sets of classes or methods.

  • Valentina SERVER

Valentina Server is available on Windows/Linux/MAC OS X. This provides multi-user access to Valentina databases. Valentina Server is licensed in three ways:

  • Valentina Server. - a single deployment license version licensed for commercial usage
  • Valentina Embedded Server - a license to deploy Valentina Server with your applications and other solutions, royalty free, for ISVs and solution providers
  • Valentina Server Free - a free for academic use, and evaluation version for other purposes

  • Valentina STUDIO

Valentina Studio is a GUI application which allows you to manage local and remote Valentina databases. You can modify database structure. You can analyze your structure in trees, columns, and diagrams. You can add/update/delete records, do searches using SQL and non-SQL methods. There are numerous other useful features to manage your databases and servers.

  • Valentina REPORTS

Valentina Reporting Services are available in different products. Valentina Studio Pro offers you a professional Report Editor where you can design layout of reports and test them. All your reports can optionally be stored in a single Valentina Project file (*.vsp).

After designing a report, a developer can use them directly in an application via Valentina ADK API or upload them under Valentina Server; application(s) will get reports produced on the server side using the same ADK API.

TEAM WORK - Because the Valentina Project format is supported under Valentina Server, several developers/users can connect to it from VStudio PRO or from applications in order to work on the same project.

Who Should Use Valentina?

Use Valentina if you need one of this or combination of this:

  • extreme speed to manage your big databases
  • more advanced database model than relational
  • a cross-platform database for desktop, CD/DVD or web applications
  • a cross-API database that can be used from many APIs and IDEs
  • SQL database and/or non-SQL database
  • DISK-based database and/or RAM-based database
  • Unicode-save database
  • Not expensive database with royalty-free models as for ADKs so for Client/Server solutions

Where to Read More?

  • After this brief description of Valentina database advantages, you may want to read a complete list of features of Valentina products: Valentina Products Features